如何架構一個合適的企業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、OAuth2.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介面方式，來關閉和啟用一個攔截器。類似這樣的命令：PUT /apigateway/v1/filters/filterName?enable=value

5）API管理與動態釋出設計

對服務管理來說，分為前端服務管理與後端服務管理。前端服務指的是閘道器層暴露給客戶端使用的服務API，後端服務指的是服務層提供的業務服務API。一個服務暴露給客戶端使用，除了閘道器層和服務層提供服務的程式碼外，還需要配置前端服務與後端服務的對映關係。

閘道器層API呼叫服務層API，有多種方式。例如，可以由按照服務層API的服務契約，生成一段客戶端程式碼，釋出給閘道器層使用。這種方式的弊端是，閘道器層程式碼依賴於服務層程式碼，服務層頻繁修改和調整介面時，導致閘道器層的程式碼很難維護。

可以透過配置前後端服務對映的方式，解耦閘道器層對服務層的依賴。當服務層的API（例如服務名、引數名等）發生變化時，只需調整對映關係，無需對閘道器層的程式碼進行調整。閘道器層按照對映，自動裝配服務層API所需要的資料格式。這樣，閘道器層團隊與服務層團隊可以相互不受干擾地開發各自的服務。

總結：API閘道器作為企業能力開放的一個門戶，除了具備基本的請求轉發、協議轉換、路由等功能，以及高效能和高穩定性外，還需具備良好的擴充套件性，已便於閘道器能力的不斷增強。在閘道器實施過程中，要規劃好閘道器層與服務層的互動方式，儘量使得閘道器層與服務層解耦，便於各個團隊工作的獨立性。