APIGateway（APIGW/API網關），顧名思義，是出現在系統(tǒng)邊界上的一個面向API的、串行集中式的強管控服務，這里的邊界是企業(yè)IT系統(tǒng)的邊界，主要起到隔離外部訪問與內部系統(tǒng)的作用。在微服務概念的流行之前，API網關的實體就已經誕生了，例如銀行、證券等領域常見的前置機系統(tǒng)，它也是解決訪問認證、報文轉換、訪問統(tǒng)計等問題的。
API網關的流行，源于近幾年來，移動應用與企業(yè)間互聯需求的興起。移動應用、企業(yè)互聯，使得后臺服務支持的對象，從以前單一的Web應用，擴展到多種使用場景，且每種使用場景對后臺服務的要求都不盡相同。這不僅增加了后臺服務的響應量，還增加了后臺服務的復雜性。隨著微服務架構概念的提出，API網關成為了微服務架構的一個標配組件。
一：網關的幾種使用場景
1、面向WebApp
這類場景，在物理形態(tài)上類似前后端分離，此時的WebApp已經不是全功能的WebApp，而是根據場景定制、場景化的App。
2、面向MobileApp
這類場景，移動App是后端Service的使用者，此時的APIGW還需要承擔一部分MDM（此處是指移動設備管理，不是主數據管理）的職能。
3、面向PartnerOpenAPI
這類場景，主要為了滿足業(yè)務形態(tài)對外開放，與企業(yè)外部合作伙伴建立生態(tài)圈，此時的APIGW需要增加配額、流控、令牌等一系列安全管控功能。
4、面向PartnerExternalAPI
這類場景，業(yè)界提的比較少，很多時候系統(tǒng)的建設，都是為了滿足企業(yè)自身業(yè)務的需要，實現對企業(yè)自有業(yè)務的映射。當互聯網形態(tài)逐漸影響傳統(tǒng)企業(yè)時，很多系統(tǒng)都會為了導入流量或者內容，依賴外部合作伙伴的能力，一些典型的例子就是使用「合作方賬號登錄」、「使用第三方支付平臺支付」等等，這些對于企業(yè)內部來說，都是一些外部能力。此時的APIGW就需要在邊界上，為企業(yè)內部Service統(tǒng)一調用外部的API做統(tǒng)一的認證、（多租戶形式的）授權、以及訪問控制。
在我們講的微服務架構下的API網關，一般指的是前三類使用場景。即，主要是把企業(yè)內部的API能力，暴露給其他應用或合作伙伴使用。網關層作為客戶端與服務端的一層擋板，主要起到了三大類作用：
- 第一類作用是隔離作用，作為企業(yè)系統(tǒng)邊界，隔離外網系統(tǒng)與內網系統(tǒng)。
- 第二類作用是解耦作用，通過解耦，使得微服務系統(tǒng)的各方能夠獨立、自由、高效、靈活地調整，而不用擔心給其他方面帶來影響。
- 第三類作用是腳手架作用，提供了一個地點，方便通過擴展機制對請求進行一系列加工和處理。
二：網關的好處
（1）網關層對外部和內部進行了隔離，保障了后臺服務的安全性。
（2）對外訪問控制由網絡層面轉換成了運維層面，減少變更的流程和錯誤成本
（3）減少客戶端與服務的耦合，服務可以獨立發(fā)展。通過網關層來做映射。
（4）通過網關層聚合，減少外部訪問的頻次，提升訪問效率。
（5）節(jié)約后端服務開發(fā)成本，減少上線風險。
（6）為服務熔斷，灰度發(fā)布，線上測試提供簡單方案。
（7）便于擴展。
三：API網關需要考慮的因素
1、安全性問題
企業(yè)在把服務暴露給外部使用時，首先要確保服務使用的安全，防止外部的惡意訪問對公司業(yè)務的影響，特別是涉及交易方面的服務，更是要全面考慮安全性。為確保安全，需要考慮在通訊鏈路的建立、通訊數據的加密、數據的完整性、不可抵賴性等方面。
2、性能問題
作為企業(yè)API的入口，所有的請求都會經過API網關進行轉發(fā)，可想而知，對API網關的訪問壓力是巨大的，有的網站甚至達到每分鐘上千萬的訪問量。特別是在一些互聯網企業(yè)，海量的移動終端每時每刻都需要與后端的服務進行交互，如果不能保證網關的高性能，企業(yè)在網關層需要投入大量的設備和成本。曾在一家互聯網公司發(fā)生過，由于網關性能問題，網關的機器數量，需要與后臺服務器的數量保持同步增長。這種情況顯然是企業(yè)服務忍受的。
3、高可用問題
API網關作為邏輯上的單點，一旦發(fā)生問題，將造成企業(yè)服務的不可用，對企業(yè)來說可能造成的致命的影響。計算短時間的不可用，也會給企業(yè)帶來直接的經濟損失。所以，如何保證API網關的7*24小時的穩(wěn)定運行，網關的自動伸縮、API的熱更新等問題，都是企業(yè)級的網關需要考慮的。
4、擴展性問題
前面說到，企業(yè)網關提供了一個腳手架，一些非功能性的問題，例如日志、安全、負載均衡策略、鑒權等。這些插件會隨著企業(yè)業(yè)務規(guī)模等的變化進行不斷的強化與調整。這就需要網關層提供這樣一種機制，使得可以靈活地進行這些調整和變化，而不用頻繁對網關層進行改動，確保網關層的穩(wěn)定性。
5、API高效運維的問題
API在上線、發(fā)布過程中，都需要涉及到網關層的配合，例如，需要網關層知道API發(fā)布的地址，API的接口形式、報文格式，也需要網關層對后臺API進行封裝。在API調整后，需要作出相應的修改。所以，API網關設計時，需要明確網關層與服務層的職責切分與協(xié)作模式，使得API的管理、發(fā)布更加高效。
6、API全生命周期的管理
API服務的全生命周期，包括服務的開發(fā)、測試、上線發(fā)布；服務使用的申請、開通；服務分類分級別的管理、服務使用情況的監(jiān)控、計費等等。
一個企業(yè)可能會暴露成百上千個API，日常也會經常進行API的發(fā)布、升級、改造、下架等操作。對不同的服務，不同的訪問者，需要提供不同的服務訪問策略。有的商業(yè)API公司，還需要對API的使用進行付費。所以，與API網關配套的，需要一套完善的自助系統(tǒng)，提供給服務的提供者、管理者、使用者，來對服務的發(fā)布、使用、和運營。
四：業(yè)界常用的API網關方案
1：Nginx+Lua
基本功能：
（1）靜態(tài)web資源服務器，能夠緩存打開的文件描述符
（2）支持http/imap/pop3/smtp的反向代理；支持緩存、負載均衡
（3）支持fastcgi(fpm)
（4）模塊化，非DSO機制，支持過濾器zip壓縮，SSI以及圖像大小調整
（5）支持SSL
Nginx的擴展功能：
（1）基于名稱和IP的虛擬主機
（2）支持keepalive的保持機制
（3）支持平滑升級
（4）定制訪問日志，支持使用日志緩存區(qū)提高日志存儲性能
（5）支持urlrewrite
（6）支持路徑別名（root或alias指定）
（7）支持基于IP以及用戶的訪問控制
（8）支持傳輸速率限制，并發(fā)限制
性能和高可用性上：
Nginx性能極高，Nginx先天的事件驅動型設計、全異步的網絡I/O處理機制、極少的進程間切換以及許多優(yōu)化設計，都使得Nginx天生善于處理高并發(fā)壓力下的互聯網請求。Nginx的穩(wěn)定性也在各大網站得到驗證。官方提供的常用模塊都非常穩(wěn)定，每個worker進程相對獨立，master進程在1個worker進程出錯時可以快速“拉起”新的worker子進程提供服務。支持熱部署，可以不停機更新配置文件、更新日志文件、更新服務器程序版本。
擴展性上：
Nginx的設計極具擴展性，它完全是由多個不同功能、不同層次、不同類型且耦合度極低的模塊組成。因此，當對某一個模塊修復Bug或進行升級時，可以專注于模塊自身，無須在意其他
易用性上：
Nginx使用最自由的BSD許可協(xié)議，允許用戶在自己的項目中直接使用或修改Nginx源碼，有大量的插件可以利用。但是，Nginx模塊需要用C開發(fā)，而且必須符合一系列復雜的規(guī)則。雖然通過第三方模塊，可以支持Nginx與Perl、Lua等腳本語言集成工作，但對使用者的要求還是很高。
2：SpringCloudZuul
基本功能
- 驗證與安全保障:識別面向各類資源的驗證要求并拒絕那些與要求不符的請求。
- 審查與監(jiān)控:在邊緣位置追蹤有意義數據及統(tǒng)計結果，從而為我們帶來準確的生產狀態(tài)結論。
- 動態(tài)路由:以動態(tài)方式根據需要將請求路由至不同后端集群處。
- 壓力測試:逐漸增加指向集群的負載流量，從而計算性能水平。
- 負載分配:為每一種負載類型分配對應容量，并棄用超出限定值的請求。
- 靜態(tài)響應處理:在邊緣位置直接建立部分響應，從而避免其流入內部集群。
- Netflix公司還利用Zuul的功能通過金絲雀版本實現精確路由與壓力測試。
雖然提供的功能還算豐富，但都比較弱，很難滿足高要求的場景。
性能和高可用性:
Zuul處理每個請求的方式是針對每個請求是用一個線程來處理。通常情況下，為了提高性能，所有請求會被放到處理隊列中，從線程池中選取空閑線程來處理該請求。2016年底，Netflix將它們的網關服務Zuul進行了升級，全新的Zuul2將HTTP請求的處理方式從同步變成了異步，以提升其處理性能。除了Netflix公司，目前Zuul在企業(yè)中用的還比較少，性能和穩(wěn)定性方面還有待進一步觀察。
擴展性上
從Zuul的架構圖上可以看出，Zuul更像是一個過濾器框架，其自身的路由、日志、反向代理、ddos預防等功能都是通過過濾器實現的。提供了PRE、ROUTING、POST和ERROR四個擴展點，可以很容易的添加自定義的過濾器。
易用性上
Zuul的搭建非常簡便，使用和配置也很簡單。Zuul的開源社區(qū)比較活躍，一直在更新狀態(tài)，但版本不算太穩(wěn)定，在使用的過程中，還有一些坑要踩。例如重定向問題、異常處理問題，還沒有解決的很好，需要自己重寫一些filter。
3.MashapeKong
Kong的一個非常誘人的地方就是提供了大量的插件來擴展應用，通過設置不同的插件可以為服務提供各種增強的功能。Kong默認插件插件包括：
- 身份認證：Kong提供了BasicAuthentication、Keyauthentication、OAuth2.0authentication、HMACauthentication、JWT、LDAPauthentication認證實現。
- 安全：ACL（訪問控制）、CORS（跨域資源共享）、動態(tài)SSL、IP限制、爬蟲檢測實現。
- 流量控制：請求限流（基于請求計數限流）、上游響應限流（根據upstream響應計數限流）、請求大小限制。限流支持本地、Redis和集群限流模式。
- 分析監(jiān)控：Galileo（記錄請求和響應數據，實現API分析）、Datadog（記錄APIMetric如請求次數、請求大小、響應狀態(tài)和延遲，可視化APIMetric）、Runscope（記錄請求和響應數據，實現API性能測試和監(jiān)控）。
- 轉換：請求轉換、響應轉換
Kong本身也是基于Nginx的，所以在性能和穩(wěn)定性上都沒有問題。Kong作為一款商業(yè)軟件，在Nginx上做了很擴展工作，而且還有很多付費的商業(yè)插件。Kong本身也有付費的企業(yè)版，其中包括技術支持、使用培訓服務以及API分析插件。
從對上面三種方案的比較中可以看到，SpringCloudZuul非常適合創(chuàng)業(yè)初期的團隊，快速搭建一個“基本可用”的API網關。Nginx適合有較強研發(fā)團隊，自主開發(fā)企業(yè)自己的API網關。Kong適合于沒有自身研發(fā)團隊，但需要擁有企業(yè)級API網關能力的公司。
五：如何設計一個好的企業(yè)級API網關產品
1：功能需求
- API生命周期管理功能：
覆蓋API的定義、測試、發(fā)布的整個生命周期管理，便捷的日常管理、版本管理，支持熱升級和快速回滾 - 開發(fā)和使用支持功能：
提供頁面調試工具，自動生成API文檔和SDK，大大降低人力成本。 - 安全防護功能：
API請求到達網關需要經過嚴格的身份認證、權限認證，才能到達后端服務。支持算法簽名，支持SSL加密。 - 流量控制功能：
可控制單位時間內API允許被調用次數。用來保護企業(yè)的后端服務，實現業(yè)務分級和用戶分級。支持對API流控，您可以根據API的重要程度來配置不同流控，從而保障重要業(yè)務的穩(wěn)定運行；支持用戶、應用和例外流控，您可以根據用戶的重要性來配置不同流控，從而可以保證大用戶的權益；流控粒度：分鐘、小時、天。 - 請求管理功能：
可根據配置進行參數類型、參數值（范圍、枚舉、正則、JsonSchema）的校驗，減少后端對非法請求、無效請求的資源消耗和處理成本。可以在API網關定義參數映射規(guī)則，網關通過映射規(guī)則將后端服務通過映射翻譯成任何形式，以滿足不同用戶的不同需求，從而避免功能重復開發(fā)。 - 監(jiān)控告警功能：
提供實時、可視化的API監(jiān)控，包括：調用量、調用方式、響應時間、錯誤率，讓您能夠清楚的了解API的運行狀況和用戶的行為習慣。
支持自定義報警規(guī)則，來針對異常情況進行報警，降低故障處理時間。
提供可訂閱的數據分析報表和智能分析。
2：高性能設計
傳統(tǒng)的基于線程的并發(fā)模型（Thread-basedconcurrency），為每一個請求分配一個線程或進程。這種模型編程簡單，可以將處理一個完整請求的代碼編寫在一個代碼路徑中。這種模型的弊端是，隨著線程(進程)數的上升，操作系統(tǒng)在這些線程(進程)之間的頻繁切換，將急劇降低系統(tǒng)的性能。
3：高可用設計
- 無狀態(tài)設計原則。
網關層為保證高可以，易于伸縮，快速啟動，需要設計成無狀態(tài)的。用戶的狀態(tài)數據我們通常使用session對象來封裝，網關層要設計成無狀態(tài)的，也就是說，不能由網關來負責session的維護。那由誰來維護session相關的信息呢？我們是采用cookie+session服務器的方式;- a)用戶在登錄頁完成登錄操作后，服務器會生成一個登錄session信息，保存起來，設置個失效時間，并設置到用戶的cookie里
- b)用戶后續(xù)的每次請求里會帶著這個cookie信息，服務端會對這個cookie信息進行校驗，通過了就認為是合法用戶，執(zhí)行請求操作
- 優(yōu)雅下線原則
當需要撤掉一臺網關服務的時候，不是直接結束網關進程，而是先關閉監(jiān)聽套接字，但是繼續(xù)為當前連接的客戶提供服務，所有客戶端的服務完成后，在把進程關閉。 - Slowstart特性
當網關監(jiān)聽到有一臺新的服務注冊上來時，考慮到有些服務啟動后，剛開始會有許多初始化的工作，此時服務對請求的響應速度是比較慢的。如果一開始就給這臺服務分配太多的壓力，有可能導致服務瞬間被壓垮。為了避免這種情況，網關層需要考慮支持SlowStart特性。即，經過一段時間，逐漸把壓力增加到預設的值。 - 擴展性設計
我們知道，網關對請求的處理，可以分為三個階段：接受請求、路由并轉發(fā)請求、接受服務的返回數據并返回給請求者，除此之外，還有一種情況是處理錯誤。所以我們也可以在這四個地方添加擴展點。- （1）接受到請求后
- （2）定位到一個服務，并準備轉發(fā)之前
- （3）接受到服務的返回數據，返回給客戶端之前
- （4）當服務調用失敗后
攔截器的處理順序，可以分為兩大類：一類為網關平臺自帶的攔截器，例如安全校驗、日志記錄等；一類為網關層邏輯開發(fā)的，例如格式轉換等。一般來說，網關先執(zhí)行網關平臺自帶的攔截器，再執(zhí)行為了業(yè)務邏輯編寫的攔截器。當然，網關也需要提供一種機制，可以較容易地調整攔截器的執(zhí)行順序。最簡單的一種方法，就是給每個攔截器定義一個優(yōu)先級，網關按優(yōu)先級順序依次調用各攔截器。
對網關層來說，它接收和處理的數據都是Request對象，網關層在接收到請求后，把請求封裝為Request對象，為了讓后續(xù)的filter能夠獲得這個對象，可以考慮把Request對象保存在線程變量中。
有些攔截器，例如一些調試日志的攔截器，通常情況下都是關閉的，只有在出現問題的時候才需要打開。為了保證網關的高可用，網關層必須具備在線啟用或關閉攔截器的能力。一般，網關需要提供restful接口方式，來關閉和啟用一個攔截器。類似這樣的命令：PUT/apigateway/v1/filters/filterName?enable=value
- 5）API管理與動態(tài)發(fā)布設計
對服務管理來說，分為前端服務管理與后端服務管理。前端服務指的是網關層暴露給客戶端使用的服務API，后端服務指的是服務層提供的業(yè)務服務API。一個服務暴露給客戶端使用，除了網關層和服務層提供服務的代碼外，還需要配置前端服務與后端服務的映射關系。
網關層API調用服務層API，有多種方式。例如，可以由按照服務層API的服務契約，生成一段客戶端代碼，發(fā)布給網關層使用。這種方式的弊端是，網關層代碼依賴于服務層代碼，服務層頻繁修改和調整接口時，導致網關層的代碼很難維護。
可以通過配置前后端服務映射的方式，解耦網關層對服務層的依賴。當服務層的API（例如服務名、參數名等）發(fā)生變化時，只需調整映射關系，無需對網關層的代碼進行調整。網關層按照映射，自動裝配服務層API所需要的數據格式。這樣，網關層團隊與服務層團隊可以相互不受干擾地開發(fā)各自的服務。
總結：API網關作為企業(yè)能力開放的一個門戶，除了具備基本的請求轉發(fā)、協(xié)議轉換、路由等功能，以及高性能和高穩(wěn)定性外，還需具備良好的擴展性，已便于網關能力的不斷增強。在網關實施過程中，要規(guī)劃好網關層與服務層的交互方式，盡量使得網關層與服務層解耦，便于各個團隊工作的獨立性。
轉自普元云。
