怎么架構一個合適的企業API網關

這期內容當中小編將會給大家帶來有關怎么架構一個合適的企業API網關，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

API Gateway（API GW / API 網關），顧名思義，是出現在系統邊界上的一個面向API的、串行集中式的強管控服務，這里的邊界是企業IT系統的邊界，主要起到隔離外部訪問與內部系統的作用。在微服務概念的流行之前，API網關的實體就已經誕生了，例如銀行、證券等領域常見的前置機系統，它也是解決訪問認證、報文轉換、訪問統計等問題的。

API網關的流行，源于近幾年來，移動應用與企業間互聯需求的興起。移動應用、企業互聯，使得后臺服務支持的對象，從以前單一的Web應用，擴展到多種使用場景，且每種使用場景對后臺服務的要求都不盡相同。這不僅增加了后臺服務的響應量，還增加了后臺服務的復雜性。隨著微服務架構概念的提出，API網關成為了微服務架構的一個標配組件。

一：網關的幾種使用場景

1、面向Web App

這類場景，在物理形態上類似前后端分離，此時的Web App已經不是全功能的Web App，而是根據場景定制、場景化的App。

2、面向Mobile App

這類場景，移動App是后端Service的使用者，此時的API GW還需要承擔一部分MDM（此處是指移動設備管理，不是主數據管理）的職能。

3、面向Partner OpenAPI

這類場景，主要為了滿足業務形態對外開放，與企業外部合作伙伴建立生態圈，此時的API GW需要增加配額、流控、令牌等一系列安全管控功能。

4、面向Partner ExternalAPI

這類場景，業界提的比較少，很多時候系統的建設，都是為了滿足企業自身業務的需要，實現對企業自有業務的映射。當互聯網形態逐漸影響傳統企業時，很多系統都會為了導入流量或者內容，依賴外部合作伙伴的能力，一些典型的例子就是使用「合作方賬號登錄」、「使用第三方支付平臺支付」等等，這些對于企業內部來說，都是一些外部能力。此時的API GW就需要在邊界上，為企業內部Service 統一調用外部的API做統一的認證、（多租戶形式的）授權、以及訪問控制。

在我們講的微服務架構下的API網關，一般指的是前三類使用場景。即，主要是把企業內部的API能力，暴露給其他應用或合作伙伴使用。網關層作為客戶端與服務端的一層擋板，主要起到了三大類作用：

第一類作用是隔離作用，作為企業系統邊界，隔離外網系統與內網系統。

第二類作用是解耦作用，通過解耦，使得微服務系統的各方能夠獨立、自由、高效、靈活地調整，而不用擔心給其他方面帶來影響。

第三類作用是腳手架作用，提供了一個地點，方便通過擴展機制對請求進行一系列加工和處理。

二：網關的好處

（1）網關層對外部和內部進行了隔離，保障了后臺服務的安全性。

（2）對外訪問控制由網絡層面轉換成了運維層面，減少變更的流程和錯誤成本

（3） 減少客戶端與服務的耦合，服務可以獨立發展。通過網關層來做映射。

（4）通過網關層聚合，減少外部訪問的頻次，提升訪問效率。

（5）節約后端服務開發成本，減少上線風險。

（6）為服務熔斷，灰度發布，線上測試提供簡單方案。

（7）便于擴展。

三：API網關需要考慮的因素

1、安全性問題

企業在把服務暴露給外部使用時，首先要確保服務使用的安全，防止外部的惡意訪問對公司業務的影響，特別是涉及交易方面的服務，更是要全面考慮安全性。為確保安全，需要考慮在通訊鏈路的建立、通訊數據的加密、數據的完整性、不可抵賴性等方面。

2、性能問題

作為企業API的入口，所有的請求都會經過API網關進行轉發，可想而知，對API網關的訪問壓力是巨大的，有的網站甚至達到每分鐘上千萬的訪問量。特別是在一些互聯網企業，海量的移動終端每時每刻都需要與后端的服務進行交互，如果不能保證網關的高性能，企業在網關層需要投入大量的設備和成本。曾在一家互聯網公司發生過，由于網關性能問題，網關的機器數量，需要與后臺服務器的數量保持同步增長。這種情況顯然是企業服務忍受的。

3、高可用問題

API網關作為邏輯上的單點，一旦發生問題，將造成企業服務的不可用，對企業來說可能造成的致命的影響。計算短時間的不可用，也會給企業帶來直接的經濟損失。所以，如何保證API網關的7*24小時的穩定運行，網關的自動伸縮、API的熱更新等問題，都是企業級的網關需要考慮的。

4、擴展性問題

前面說到，企業網關提供了一個腳手架，一些非功能性的問題，例如日志、安全、負載均衡策略、鑒權等。這些插件會隨著企業業務規模等的變化進行不斷的強化與調整。這就需要網關層提供這樣一種機制，使得可以靈活地進行這些調整和變化，而不用頻繁對網關層進行改動，確保網關層的穩定性。

5、API高效運維的問題

API在上線、發布過程中，都需要涉及到網關層的配合，例如，需要網關層知道API發布的地址，API的接口形式、報文格式，也需要網關層對后臺API進行封裝。在API調整后，需要作出相應的修改。所以，API網關設計時，需要明確網關層與服務層的職責切分與協作模式，使得API的管理、發布更加高效。

6、API全生命周期的管理

API服務的全生命周期，包括服務的開發、測試、上線發布；服務使用的申請、開通；服務分類分級別的管理、服務使用情況的監控、計費等等。

一個企業可能會暴露成百上千個API，日常也會經常進行API的發布、升級、改造、下架等操作。對不同的服務，不同的訪問者，需要提供不同的服務訪問策略。有的商業API公司，還需要對API的使用進行付費。所以，與API網關配套的，需要一套完善的自助系統，提供給服務的提供者、管理者、使用者，來對服務的發布、使用、和運營。

四：業界常用的API網關方案

1：Nginx + Lua

基本功能：

（1）靜態web資源服務器，能夠緩存打開的文件描述符

（2）支持http/imap/pop3/smtp的反向代理；支持緩存、負載均衡

（3）支持fastcgi(fpm)

（4）模塊化，非DSO機制，支持過濾器zip壓縮，SSI以及圖像大小調整

（5）支持SSL

Nginx的擴展功能：

（1）基于名稱和IP的虛擬主機

（2）支持keepalive的保持機制

（3）支持平滑升級

（4）定制訪問日志，支持使用日志緩存區提高日志存儲性能

（5）支持url rewrite

（6）支持路徑別名（root或alias指定）

（7）支持基于IP以及用戶的訪問控制

（8）支持傳輸速率限制，并發限制

性能和高可用性上：

Nginx性能極高，Nginx先天的事件驅動型設計、全異步的網絡I/O處理機制、極少的進程間切換以及許多優化設計，都使得Nginx天生善于處理高并發壓力下的互聯網請求。Nginx的穩定性也在各大網站得到驗證。官方提供的常用模塊都非常穩定，每個worker進程相對獨立，master進程在1個worker進程出錯時可以快速“拉起”新的worker子進程提供服務。支持熱部署，可以不停機更新配置文件、更新日志文件、更新服務器程序版本。

擴展性上：

Nginx的設計極具擴展性，它完全是由多個不同功能、不同層次、不同類型且耦合度極低的模塊組成。因此，當對某一個模塊修復Bug或進行升級時，可以專注于模塊自身，無須在意其他

易用性上：

Nginx使用最自由的BSD許可協議，允許用戶在自己的項目中直接使用或修改Nginx源碼，有大量的插件可以利用。但是，Nginx模塊需要用C開發，而且必須符合一系列復雜的規則。雖然通過第三方模塊，可以支持Nginx與Perl、Lua等腳本語言集成工作，但對使用者的要求還是很高。

2：Spring Cloud Zuul

基本功能

驗證與安全保障: 識別面向各類資源的驗證要求并拒絕那些與要求不符的請求。

審查與監控: 在邊緣位置追蹤有意義數據及統計結果，從而為我們帶來準確的生產狀態結論。

動態路由: 以動態方式根據需要將請求路由至不同后端集群處。

壓力測試: 逐漸增加指向集群的負載流量，從而計算性能水平。

負載分配: 為每一種負載類型分配對應容量，并棄用超出限定值的請求。

靜態響應處理: 在邊緣位置直接建立部分響應，從而避免其流入內部集群。

Netflix公司還利用Zuul的功能通過金絲雀版本實現精確路由與壓力測試。

雖然提供的功能還算豐富，但都比較弱，很難滿足高要求的場景。

性能和高可用性

Zuul處理每個請求的方式是針對每個請求是用一個線程來處理。通常情況下，為了提高性能，所有請求會被放到處理隊列中，從線程池中選取空閑線程來處理該請求。2016年底，Netflix將它們的網關服務Zuul進行了升級，全新的Zuul 2將HTTP請求的處理方式從同步變成了異步，以提升其處理性能。除了Netflix公司，目前Zuul在企業中用的還比較少，性能和穩定性方面還有待進一步觀察。

擴展性上，

從Zuul的架構圖上可以看出，Zuul更像是一個過濾器框架，其自身的路由、日志、反向代理、ddos預防等功能都是通過過濾器實現的。提供了PRE、ROUTING、POST和ERROR四個擴展點，可以很容易的添加自定義的過濾器。

易用性上

Zuul的搭建非常簡便，使用和配置也很簡單。Zuul的開源社區比較活躍，一直在更新狀態，但版本不算太穩定，在使用的過程中，還有一些坑要踩。例如重定向問題、異常處理問題，還沒有解決的很好，需要自己重寫一些filter。

3.Mashape Kong

Kong的一個非常誘人的地方就是提供了大量的插件來擴展應用，通過設置不同的插件可以為服務提供各種增強的功能。Kong默認插件插件包括：

l 身份認證：Kong提供了Basic Authentication、Key authentication、OAuth3.0 authentication、HMAC authentication、JWT、LDAP authentication認證實現。

l 安全：ACL（訪問控制）、CORS（跨域資源共享）、動態SSL、IP限制、爬蟲檢測實現。

l 流量控制：請求限流（基于請求計數限流）、上游響應限流（根據upstream響應計數限流）、請求大小限制。限流支持本地、Redis和集群限流模式。

l 分析監控：Galileo（記錄請求和響應數據，實現API分析）、Datadog（記錄API Metric如請求次數、請求大小、響應狀態和延遲，可視化API Metric）、Runscope（記錄請求和響應數據，實現API性能測試和監控）。

l 轉換：請求轉換、響應轉換

Kong本身也是基于Nginx的，所以在性能和穩定性上都沒有問題。Kong作為一款商業軟件，在Nginx上做了很擴展工作，而且還有很多付費的商業插件。Kong本身也有付費的企業版，其中包括技術支持、使用培訓服務以及 API 分析插件。

從對上面三種方案的比較中可以看到，Spring Cloud Zuul非常適合創業初期的團隊，快速搭建一個“基本可用”的API網關。Nginx適合有較強研發團隊，自主開發企業自己的API網關。Kong適合于沒有自身研發團隊，但需要擁有企業級API網關能力的公司。

五：如何設計一個好的企業級API網關產品

1：功能需求

1）API 生命周期管理功能：

覆蓋 API 的定義、測試、發布的整個生命周期管理，便捷的日常管理、版本管理，支持熱升級和快速回滾

2）開發和使用支持功能：

提供頁面調試工具，自動生成 API 文檔和 SDK，大大降低人力成本。

3）安全防護功能：

API 請求到達網關需要經過嚴格的身份認證、權限認證，才能到達后端服務。支持算法簽名，支持 SSL 加密。

4）流量控制功能：

可控制單位時間內 API 允許被調用次數。用來保護企業的后端服務，實現業務分級和用戶分級。 支持對 API 流控，您可以根據 API 的重要程度來配置不同流控，從而保障重要業務的穩定運行； 支持用戶、應用和例外流控，您可以根據用戶的重要性來配置不同流控，從而可以保證大用戶的權益； 流控粒度：分鐘、小時、天。

5）請求管理功能：

可根據配置進行參數類型、參數值（范圍、枚舉、正則、Json Schema）的校驗，減少后端對非法請求、無效請求的資源消耗和處理成本。可以在 API 網關定義參數映射規則，網關通過映射規則將后端服務通過映射翻譯成任何形式，以滿足不同用戶的不同需求，從而避免功能重復開發。

6）監控告警功能：

提供實時、可視化的 API 監控，包括：調用量、調用方式、響應時間、錯誤率，讓您能夠清楚的了解 API 的運行狀況和用戶的行為習慣。

支持自定義報警規則，來針對異常情況進行報警，降低故障處理時間。

提供可訂閱的數據分析報表和智能分析。

2：高性能設計

傳統的基于線程的并發模型（Thread-based concurrency），為每一個請求分配一個線程或進程。這種模型編程簡單，可以將處理一個完整請求的代碼編寫在一個代碼路徑中。這種模型的弊端是，隨著線程(進程)數的上升，操作系統在這些線程(進程)之間的頻繁切換，將急劇降低系統的性能。

3：高可用設計

1） 無狀態設計原則。

網關層為保證高可以，易于伸縮，快速啟動，需要設計成無狀態的。用戶的狀態數據我們通常使用session對象來封裝，網關層要設計成無狀態的，也就是說，不能由網關來負責session的維護。那由誰來維護session相關的信息呢？我們是采用cookie+session服務器的方式;

a) 用戶在登錄頁完成登錄操作后，服務器會生成一個登錄session信息，保存起來，設置個失效時間，并設置到用戶的cookie里

b) 用戶后續的每次請求里會帶著這個cookie信息，服務端會對這個cookie信息進行校驗，通過了就認為是合法用戶，執行請求操作

2）優雅下線原則

當需要撤掉一臺網關服務的時候，不是直接結束網關進程，而是先關閉監聽套接字，但是繼續為當前連接的客戶提供服務，所有客戶端的服務完成后，在把進程關閉。

3）Slow start特性

當網關監聽到有一臺新的服務注冊上來時，考慮到有些服務啟動后，剛開始會有許多初始化的工作，此時服務對請求的響應速度是比較慢的。如果一開始就給這臺服務分配太多的壓力，有可能導致服務瞬間被壓垮。為了避免這種情況，網關層需要考慮支持Slow Start特性。即，經過一段時間，逐漸把壓力增加到預設的值。

4）擴展性設計

我們知道，網關對請求的處理，可以分為三個階段：接受請求、路由并轉發請求、接受服務的返回數據并返回給請求者，除此之外，還有一種情況是處理錯誤。所以我們也可以在這四個地方添加擴展點。

（1）接受到請求后

（2）定位到一個服務，并準備轉發之前

（3）接受到服務的返回數據，返回給客戶端之前

（4）當服務調用失敗后

攔截器的處理順序，可以分為兩大類：一類為網關平臺自帶的攔截器，例如安全校驗、日志記錄等；一類為網關層邏輯開發的，例如格式轉換等。一般來說，網關先執行網關平臺自帶的攔截器，再執行為了業務邏輯編寫的攔截器。當然，網關也需要提供一種機制，可以較容易地調整攔截器的執行順序。最簡單的一種方法，就是給每個攔截器定義一個優先級，網關按優先級順序依次調用各攔截器。

對網關層來說，它接收和處理的數據都是Request對象，網關層在接收到請求后，把請求封裝為Request對象，為了讓后續的filter能夠獲得這個對象，可以考慮把Request對象保存在線程變量中。

有些攔截器，例如一些調試日志的攔截器，通常情況下都是關閉的，只有在出現問題的時候才需要打開。為了保證網關的高可用，網關層必須具備在線啟用或關閉攔截器的能力。一般，網關需要提供restful接口方式，來關閉和啟用一個攔截器。

5）API管理與動態發布設計

對服務管理來說，分為前端服務管理與后端服務管理。前端服務指的是網關層暴露給客戶端使用的服務API，后端服務指的是服務層提供的業務服務API。一個服務暴露給客戶端使用，除了網關層和服務層提供服務的代碼外，還需要配置前端服務與后端服務的映射關系。

網關層API調用服務層API，有多種方式。例如，可以由按照服務層API的服務契約，生成一段客戶端代碼，發布給網關層使用。這種方式的弊端是，網關層代碼依賴于服務層代碼，服務層頻繁修改和調整接口時，導致網關層的代碼很難維護。

可以通過配置前后端服務映射的方式，解耦網關層對服務層的依賴。當服務層的API（例如服務名、參數名等）發生變化時，只需調整映射關系，無需對網關層的代碼進行調整。網關層按照映射，自動裝配服務層API所需要的數據格式。這樣，網關層團隊與服務層團隊可以相互不受干擾地開發各自的服務。

上述就是小編為大家分享的怎么架構一個合適的企業API網關了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。