簡介：多年SOA規劃建設，私有云PaaS平臺架構設計經驗，長期從事一線專案實踐

今天準備再詳細講解下API閘道器的基礎概念，使用場景和核心功能，以及基於API閘道器核心引擎做的API全生命週期管理功能擴充套件等，最好再介紹下當前主流的開源API閘道器引擎。

在微服務架構體系裡面，我們一般會使用到微服務閘道器或叫API閘道器。

大家都比較清楚，在微服務架構體系下本身是去中心化的架構，通過服務註冊中心來實現服務註冊發現和消費呼叫，那麼為何又需要使用API閘道器？

在傳統的ESB匯流排進行服務整合的時候我們就經常談到一個概念就是位置透明，即需要遮蔽底層業務模組提供API介面服務地址資訊，並實現多個微服務API介面的統一出口。即類似設計模式裡面經常談到的門面模式。

如何給API閘道器一個定義？

簡單來說API閘道器就是將所有的微服務提供的API介面服務能力全部匯聚進來，統一接入進行管理，也正是通過統一攔截，就可以通過閘道器實現對API介面的安全，日誌，限流熔斷等共性需求。如果再簡單說下，通過閘道器實現了幾個關鍵能力。

內部的微服務對外部訪問來說位置透明，外部應用只需和閘道器互動統一攔截介面服務，實現安全，日誌，限流熔斷等需求

從這裡，我們就可以看到API閘道器和傳統架構裡面的ESB匯流排是類似的，這些關鍵能力本身也是ESB服務匯流排的能力，但是ESB服務匯流排由於要考慮遺留系統的接入，因此增加了：

大量介面卡實現對遺留系統的遺留介面適配，多協議轉換能力進行資料的複製對映，路由等能力

對於兩者，我原來做過一個簡單的對比，大家可以參考。

這個概念理解後，我們再回到微服務架構裡面。

對於微服務架構大家經常說的最多的就是去中心化的架構，認為ESB中心化架構模式已經過時。而實際上經過上面分析你可以看到。在微服務架構裡面的API閘道器仍然是中心化的架構模式，所有的API介面都要經過閘道器這個點。

非中心化架構-》走微服務裡面的服務註冊中心進行介面互動中心化架構-》走閘道器進行介面服務暴露和共享互動

對於微服務架構裡面有無去中心化的架構？當然是有的，即我們常說的微服務模組之間可以通過服務註冊中心來實現服務發現查詢，服務間的點對點呼叫即使去中心化的。

如果一個單體拆分為微服務後，完全不需要和外部應用打交道，也不需要共享自己的介面能力，那麼這個微服務體系裡面就不需要用API閘道器，僅僅使用服務註冊中心即可。通過服務註冊中心實現完全的去中心化和介面呼叫更高的效能。

什麼時候需要使用API閘道器？

如果一個微服務架構下，雖然不會外部的其它應用進行互動和整合，但是整個應用本身存在APP應用端，而APP應用端通過前後端分析開發，同時需要通過網際網路訪問。本身存在需要一個統一訪問API訪問入口，同時也需要考慮和內部微服務模組進一步進行安全隔離。

當我們談到這裡的時候，你會發現我們常說的API閘道器的服務代理或透傳能力，實際和我們常說的Ngnix反向代理或路由是一個意思。

如果你僅僅是為了統一API介面的訪問出口，並考慮類似DMZ區的安全隔離，那麼在你架構前期完全不需要馬上實施API閘道器，直接採用Ngnix進行服務路由代理即可。因為在這種架構下，API介面消費端，提供端全部是一個開發團隊開發，各種問題分析排查都相當方便，類似API介面安全訪問等也可以通過JWT，Auth2.0等統一實現，而且這個過程也並不複雜。

能力開放或多應用外部整合對API管控治理需要

但是當我們面臨是和多個外部應用整合，或者說將自己的API介面服務能力開放給外部多個合作伙伴使用的時候，這個時候對於API介面的管控治理要求自然增加。

即在常規的服務代理路由基礎上，需要增加類似負載均衡，安全，日誌，限流熔斷等各種能力，而且我們不希望這些能力在API介面開發的時候考慮，而是希望這些能力是在API接入到閘道器的時候統一靈活配置來實現管控。

那麼這個時候使用API閘道器作用就體現出來。

對於API閘道器實際上前面已經多次強調，可以看做是ESB匯流排的輕量化實現，不再需要複雜的協議轉換，適配和資料對映等能力，但是提升了流量控制和安全，實時監控等方面的能力。對於API閘道器引擎部分提供的核心功能，再簡單總結如下：

1.實現統一服務代理和服務統一出口

這點是閘道器和常規點對點服務註冊中心最大的一個區別點，就是位置透明，消費端只需要和閘道器打交道，具體閘道器如何和後臺的微服務模組打交道，後臺微服務模組的部署邏輯，模組提供服務的IP地址等都不用關心。

由於實現了位置透明，帶來一點就是資料流必須通過閘道器，那麼閘道器本身又成為了去中心的微服務架構中的中心化節點，那麼就必須考慮閘道器節點的效能，可靠性和彈性擴充套件能力。

閘道器要實現位置透明，延伸出來對應的閘道器必須提供的能力就包括了

提供服務註冊和服務接入的能力提供服務代理和服務路由能力，能夠將服務路由到具體的原始服務上提供負載均衡能力（該點並不是必須具備）

在這裡準備重點強調下負載均衡能力，實際上對於API閘道器往往並不是必須具備負載均衡能力。

其一是提供API介面服務的模組本身進行了負載均衡，再提供地址其二是類似容器化整合和部署，已經可以通過Kubernetes實現了負載均衡

我們可以看下對於註冊和接入到API閘道器服務的三種場景，只有場景一需要由API閘道器來提供負載均衡能力。

注意API閘道器是否需要具備負載均衡能力，是必須考慮的一個點，即如果底層微服務模組提供的API介面服務本身能夠提供負載均衡後的地址，那麼閘道器不需要進行負載均衡。如果底層模組不具備這個能力，那麼閘道器必須具備負載均衡能力。

微服務模組本身可以基於容器化資源池提供的能力進行動態擴充套件，因此這個地方本身又有兩層負載均衡，一個是kubernates提供的叢集能力，一個是多個API閘道器本身提供的叢集能力。當然API閘道器本身也具備負載均衡功能，可以和Kubernate進行銜接。

2. 通過閘道器的攔截能力來實現所有共效能力抽取和實現

剛才已經談到啟用閘道器後就承載了資料流，因此可以通過對介面訪問輸入和輸出的攔截來實現所有共性可複用能力的抽取和實現。這些共效能力可以理解為閘道器實現的一個個攔截外掛，本身可插拔，靈活可配置。

這些外掛能力中最核心的就是安全，日誌，流控。

其中安全可以實現訪問安全，傳輸安全，資料安全等，其中訪問安全本身又可以實現類似Token，IP，使用者名稱密碼等多種安全控制策略。包括對Auth2.0等標準規範的支援等。

對於日誌也是閘道器提供的一個關鍵能力，即可以實現對服務消費日誌，詳細的輸入和輸出報文的查詢能力，這個在各開源閘道器往往並不具備這個能力，也無法面向業務系統人員去使用，因此這塊能力提升往往都需要在開源閘道器基礎上做大量擴充套件。

流控是我們談的另外一個關鍵能力，包括了服務限流和服務熔斷。對於服務限流主要是實現對服務消費前執行緒數控制，資源分配實現消費前等待。而對於服務熔斷，即直接對服務進行下線或禁用，以避免大併發服務消費呼叫對閘道器造成的影響或帶來的服務雪崩等。

一個閘道器來說，流控能力相對關鍵，因為閘道器是中心化節點，必須保證閘道器的高可靠執行。因此閘道器流控能力強弱直接影響到閘道器的高可靠性和效能，而判斷流控能力強弱的關鍵則在於靈活的流量控制策略配置，只有這樣才能夠做到既實現流控，又不影響到關鍵業務和介面服務的訪問。

3. 滿足前後端分離的需求

注意，如果一個企業開發的業務系統涉及到手機APP端，而手機APP端一定涉及到公網訪問，按業務系統內部部署安全策略也一定涉及到DMZ區的設定和硬體防火牆隔離。

而對於API閘道器本身恰好又是可以部署到DMZ區的一個內容，既實現了服務代理路由，又實現了安全隔離，如果存在這種場景，即使業務應用不和外部系統打交道，為了前後端的隔離和外部訪問，往往也需要API閘道器能力支撐。當然前期你也可以使用Ngnix來替代API閘道器實現統一代理。

4. 灰度釋出或金絲雀釋出

這個在我原來談閘道器的文章的時候很少談到這點，但是實際上在DevOps和微服務架構實施下，對於灰度釋出能力往往也是必須的。比如我們對已有的一個介面服務做了修改，我們想先在某些業務系統試用，沒有問題再發布到所有的業務系統。這個時候就涉及到金絲雀釋出的問題。當然你可以配置是按系統，按IP，按使用者還是其他的釋出策略。

這塊的能力不僅僅是DevOps的自動部署，同時也必須考慮閘道器層能夠基於動態釋出的內容進行路由。確保服務呼叫消費的路由路徑是隔離開的。而對於金絲雀釋出策略允許你直接只匯入指定量的流量到新的版本，API閘道器就可以幫你來做這件事情。你可以配置10%的請求到新的版本，然後一旦你確保了新版本沒有bug，你可以把流量切換到100%。

5. 服務組合能力

實際上當我們談API閘道器的時候，一般不會談服務組合能力，因為一涉及到服務組合或編排，那麼必然匯入閘道器整體架構變重。從當前主流閘道器看，一般也不提供類似能力。

實際上服務組合編排難點在於，上個服務的輸出往往要成為下一個服務的輸入，同時服務輸入和輸出還存在大量的資料對映操作。我們回顧下類似智慧家庭裡面的組合場景編排，實際上很簡單，比如我回到家後需要開啟空調，關窗簾，開啟熱水器，開燈的一系列動作，我只是需要簡單將這些動作編排在一起。

對應到API閘道器的服務組合，實際上我們也可以做輕量的服務組合，即去掉資料對映等複雜組合場景，只需要實現簡單的服務多次呼叫，服務返回資料的組合等即可。

對於具體的服務組合和編排，可以參考下面這篇文章：

API全生命週期管理能力

可以看到，API閘道器更多是一個底層引擎，而要實現完整的API管控，往往還需要配合API全生命週期管理能力。這個完全可以在底層API閘道器引擎基礎上進行擴充套件開發。

API介面的定義

在定義API介面的時候首先要定義API分組，這個從京東，淘寶等OpenAPI能力開放平臺的API文件都可以看到，首先要有API歸類分組，然後再定義詳細的API。

比如京東開放平臺，有商品，店鋪，倉儲，支付等多個類目，然後各類目下有詳細的API的定義。

API的定義包括兩個部分，一個是API基本資訊定義，一個是詳細輸入輸出定義。

API基本資訊仍然是包括了API的編碼，API名稱，API的分組，API的用途描述，API的快取，安全等基本控制資訊的定義等。還有就是這個API介面的訪問路徑定義，API介面是Get還是Post方法定義等。

API詳細資訊主要就是API的輸入和輸出資訊定義。

API的輸入引數注意實際有多種形式，一個就是在API訪問路徑上的路徑引數，還有一個就是在訪問路徑後?引數後面的查詢引數資訊，還有就是一個完整的Request Body請求引數資訊。

比如對於Http Rest查詢介面，這類Get方法介面，可以看到並沒有Body資訊，更多的是通過路徑和查詢引數定義來完成查詢。而對於Post介面往往就涉及到具體的Body資訊定義。

但是要注意，為了實現Http Rest介面和SOAP WS介面服務的互相轉換，對於SOAP WS查詢服務介面在自動轉換為Http Rest介面服務的時候實際上仍然為轉換為Post方法+Body引數模式。

對於API介面定義，仍需要預留標準的系統級引數部分內容。這部分內容是API閘道器實現統一標準化管理的基礎，不能隨便修改和變動。比如京東API平臺預留的API名稱，方法，版本，Token，APP_Key，Date等都是使用系統級別的引數定義，是每一個介面API暴露後都需要增加的引數頭資訊。

API快速開發的支援

在API介面服務定義完成後，一方面是可以通過類似WADL或RAML等標準的Rest介面定義規範檔案，另外一個就是需要提供客戶端和服務端的開發框架程式碼。

在這個基礎上，還可以提供完整的示例程式碼下載，方便開發商或合作伙伴對API介面進行快速開發。開發完成的後端原始服務介面，在註冊接入前還可以提供介面服務的模型匹配自校驗功能，確認開發的服務完全遵循從上到下方式-》API開發框架生成和API後端服務開發。

對於API介面管理，如果是標準的從頂朝下模式，即在定義了API介面後，實現生成類似WADL或RAML標準介面規範。後端服務基於我們標準的API介面契約進行開發，那麼開發完成後就方便快速代理方式接入，在接入過程中就不再有引數對映和轉換的問題，否則我們的API接入過程會比較複雜。

API介面服務的註冊和接入

API介面定義過程和API介面的註冊接入最好分開。

在API介面定義完成後進行API介面服務的註冊，即選擇具體的後端服務，然後對服務進行接入。同時將後端服務對應到我們在前面定義的API介面代理服務上。注意在前面談到的API路徑定義，方法型別定義，實際上也可以在API介面服務註冊和接入的時候來完成。

API介面服務的後續變更釋出，還可以考慮和DevOps平臺配合並支援灰度釋出功能。

反向的後端服務快速接入併發布為API介面服務，即直接對後端已有的API服務進行快速接入，將API後端服務釋出為代理服務，在整個接入過程中需要定義API介面名稱，API訪問路徑，API方法型別等資訊。在釋出為API介面服務後，對於後端服務的API引數資訊也需要進行快速匯入，以方便在API介面查詢中看到詳細的介面內容定義。

在將後端業務服務釋出為API介面服務的時候，釋出的代理服務要自動增加系統級的輸入引數資訊，這個輸入引數最好的方式是在訪問路徑中進行增加，以減少對已有的後端服務的影響。

API介面在註冊和接入完成後，將自動進行服務部署和服務釋出，即註冊接入完成後的服務可以通過釋出的訪問路徑地址進行訪問。

服務接入適配能力

服務註冊接入本身分為兩個層面，一個是已有服務的註冊接入，一個是需要適配後的服務釋出。在設計的時候需要考慮到兩個方面的需求。

對於已有服務的存代理接入最簡單，即只需要提供業務系統的Rest介面服務地址即可，在接入的時候，對相關的日誌，安全，流控，負載均衡等策略進行配置，配置完成後即完成服務接入和註冊。同時對於路由服務接入需要單獨考慮，對於路由服務在接入的時候可以適配到多個原始業務系統的介面服務地址。

服務釋出是對原來我們服務適配功能的一個改進，即直接從底向上的進行服務釋出，而不需要實現定義服務元資料或模型，制定服務契約格式等，在服務釋出完成後再生成相關的基礎資料到服務元資料庫即可。對於服務釋出參考服務適配的能力，我們可以考慮如下場景下的需求。

將一個已有的SOAP WS服務釋出和註冊為一個Http Rest介面服務。將一個數據庫表，或儲存過程釋出為一個Http Rest介面服務。 將一個JMS訊息介面釋出為一個Http Rest介面服務。將一個JAR包中的API介面方法或函式釋出為一個Http Rest介面服務。

對於服務釋出而言，如果不僅僅是微服務閘道器能力，而是一個微服務支撐或微服務快速開發平臺的話，還可以提供完整的服務開發和設計能力。即在微服務平臺首先定義資料或物件模型，然後將物件模型轉換為Http Rest中的資源物件，併發布對應的Get , Post各種Http Rest介面服務。

對應釋出的介面服務可以直接在微服務平臺上進行攔截，模擬生成相關的輸入或輸出資料。當然也可以直接將資料模型物件生成到對應的資料庫，同時將微服務API介面的實現生成對應的Java程式碼框架並給出參考實現。而我們剩餘的工作，僅僅是填充程式碼邏輯即可。通過這種方式可以極大的提高我們進行微服務架構開發的速度。

API介面線上模擬測試功能

這個功能參考當前的OpenAPI能力開放平臺的做法來實現即可。即對於已經發布完成的API介面服務，提供線上測試工具進行線上測試。同時對介面服務呼叫的輸入引數進行結構化展示，方便使用者對測試需要的各種引數進行輸入。在輸入完成後形成完整的提交引數完整字串。通過測試，可以返回最終的模擬呼叫返回結果字串資訊。

同樣，這裡可以採用Swagger工具來完成，Swagger不僅僅是API介面的定義，介面文件的生成，同時還可以根據可以介面定義，自動生成介面測試用例，對介面進行測試工作。我們也很容易將Swagger能力整合都API閘道器的管理平臺中。

API介面查詢功能

對於API介面查詢功能也是一個標準的功能，實際上可以考慮將查詢功能和API介面服務的分類瀏覽分開。對於API介面的分類瀏覽參考開放平臺的API介面文件做法來實現介面。對於API介面查詢，即可以設定不同的動態查詢條件，對API介面進行查詢，返回結果集。對於查詢到的API介面清單列表，可以點選詳細進入到API介面詳細的輸入和輸出資訊檢視介面。

API狀態管理功能

對於已經註冊和釋出的API介面可以對其狀態進行管理。其中主要的狀態包括了待發布，上線，暫停，下線廢棄等幾種關鍵狀態。對於API狀態本身還需要和後續的API監控管理結合，能夠通過API效能監控動態的調整API介面的狀態。比如在API觸發熔斷後，自動對API介面狀態調整為暫停。

API版本管理能力

對於API需要啟用版本管理能力。當前一些API介面服務實現方法會在路徑引數中增加API版本資訊，以確定究竟訪問哪個版本。但是由於不同的API版本可能存在返回的結果集的資料結構不一樣的問題，因此對於這種場景需要針對該API定義不同的大版本，不同的大版本實際上對應不同的後端原始服務。

在這裡我們介紹下當前主流的一些API閘道器功能供參考。

在微服務架構之下，服務被拆的非常零散，降低了耦合度的同時也給服務的統一管理增加了難度。如上圖左所示，在舊的服務治理體系之下，鑑權，限流，日誌，監控等通用功能需要在每個服務中單獨實現，這使得系統維護者沒有一個全域性的檢視來統一管理這些功能。API 閘道器致力於解決的問題便是為微服務納管這些通用的功能，在此基礎上提高系統的可擴充套件性。

Kong 的外掛機制是其高可擴充套件性的根源，Kong 可以很方便地為路由和服務提供各種外掛，閘道器所需要的基本特性，Kong 都如數支援：

從上面圖可以看到，Kong閘道器是基於OpenResty應用伺服器，OpenResty是一個基於 Nginx 與 Lua 的高效能 Web 平臺，其內部集成了大量精良的 Lua 庫、第三方模組以及大多數的依賴項。用於方便地搭建能夠處理超高併發、擴充套件性極高的動態 Web 應用、Web 服務和動態閘道器。而Kong 核心基於OpenResty構建，並且擁有強大的外掛擴充套件功能。

在Http請求到達Kong閘道器後，轉發給後端應用之前，可以通過閘道器的各種外掛對請求進行流量控制，安全，日誌等各方面的處理能力。當前Kong的外掛分為開源版和社群版，社群版還有更多的定製功能，但是社群版是要收費的。

目前，KONG開源版本一共開放28個外掛，如下：

acl、aws-lambda、basic-auth、bot-detection、correlation-id、cors、datadog、file-log、galileo、hmac-auth、http-log、ip-restriction、jwt、key-auth、ldap-auth、loggly、oauth2、rate-limiting、request-size-limiting、request-termination、request-transformer、response-ratelimiting、response-transformer、runscope、statsd、syslog、tcp-log、udp-log。

以上這些外掛主要分五大類，Authentication認證，Security安全，Traffic Control流量控制，Analytics & Monitoring分析&監控，Logging日誌，其他還有請求報文處理類。外掛類似AOP開發中的橫切功能，可以靈活的配置進行攔截控制，下面選擇一些關鍵性的外掛進行簡單的說明。

黑白名單控制能力-ip-restriction

Kong提供的IP黑白名單控制能力還算相當強，從配置項裡面可以看到主要可以針對兩個維度進行配置，一個是針對所有的API介面還是針對特定的API介面，一個是針對所有的所有的消費方還是特定的某個消費方。對於IP配置可以是一個區段，也可以是特定的IP地址。但是黑白名單不能同時配置，其次當前沒有一個功能是針對某一個系統提供的所有服務都啟用黑名單或白名單功能。

日誌記錄能力-syslog, file-log，http-log

這裡主要日誌的外掛比較多，一個是sysLog在配置後可以直接將Kong產生的日誌寫入到應用伺服器的系統日誌檔案中。如果配置了file-log則是單獨寫入到你指定的file檔案中。對於http-log則是對於http服務請求，可以詳細的記錄請求的輸入和輸出報文資訊，但是具體是記錄到哪裡，需要通過config.http_endpoint配置。具體關鍵的配置引數資訊如下：

consumer_id: 可選引數,消費者id(啟用了消費者認證可以使用，根據id識別發出請求的消費者);

config.http_endpoint: 日誌接收伺服器(包括使用的協議,http or https);

config.method: 可選引數,預設POST,訪問日誌伺服器的請求方式(可選值:PUT,PATCH,POST);

config.timeout: 可選引數,預設10000毫秒,請求超時時間

config.keepalive: 可選引數,預設60000毫秒,連線在關閉之前可存活時間

熔斷外掛-request-termination

該外掛用來定義指定請求或服務不進行上層服務,而直接返回指定的內容.用來為指定的請求或指定的服務進行熔斷。注意Kong的熔斷外掛感覺是臨時對服務的禁用，而不是說當達到某一種監控閾值的時候自動觸發熔斷，或者相關內容還沒有了解到。從官方文件的應用場景也可以看到這點。

Temporarily disable a Service (e.g. it is under maintenance).

Temporarily disable a Route (e.g. the rest of the Service is up and running, but a particular endpoint must be disabled).

Temporarily disable a Consumer (e.g. excessive consumption).

如果僅僅是這種方式的熔斷話，實際上意義並不是很大。但是可用的地方就在於當某個業務系統進行發版部署的時候我們可以對該業務系統或該業務系統所提供的所有服務進行熔斷。

限流外掛-rate-limiting

Kong當前提供的限流相對來說還是比較弱，即主要是控制某一個API介面服務在單位時間內最多隻能夠呼叫多少次，如果超過這個次數那麼閘道器就直接拒絕訪問並返回錯誤提示資訊。而在前面我講限流和流量控制的時候經常會說到，就是限流實際上一個是根據服務呼叫次數，一個是根據服務呼叫資料量，需要在這兩個方面進行限流。而裡面更加重要的反而是資料量的限流，因為大資料量報文往往更加容易造成記憶體溢位異常。

安全認證類外掛

當前Kong閘道器提供basic-auth，key-auth、ldap-auth，hmac-auth多種認證外掛。

Basic-auth基本認證外掛，即我們根據使用者名稱和密碼來生成一個base64編碼，同時將該編碼和目標服務繫結，這樣在消費目標服務的時候就需要在報文頭填寫這個Base64編碼資訊。

Key-auth認證外掛則是利用提前預設好的關鍵字名稱，如下面設定的keynote = apices，然後為consumer設定一個key-auth 金鑰，假如key-auth=test@keyauth。在請求api的時候，將apikey=test@keyauth，作為一個引數附加到請求url後，或者放置到headers中。

Hmac-auth外掛是設定繫結的service和rout，以啟動hmac驗證。然後在Consumers頁面中Hmac credentials of Consumer設定中新增一個username和secret。

請求報文容量限制-request-size-limiting

該外掛用於限制請求報文的資料量大小，可以限制單個服務，也可以顯示所有的API介面服務。

支援OAuth2.0身份認證-oauth2

Kong閘道器支援OAuth2.0身份認證，OAuth2.0 協議根據使用不同的適用場景，定義了用於四種授權模式。

Authorization code（授權碼模式）：標準的 Server 授權模式，非常適合 Server 端的 Web 應用。一旦資源的擁有者授權訪問他們的資料之後，他們將會被重定向到 Web 應用並在 URL 的查詢引數中附帶一個授權碼（code）。在客戶端裡，該 code 用於請求訪問令牌（access_token）。並且該令牌交換的過程是兩個服務端之前完成的，防止其他人甚至是資源擁有者本人得到該令牌。另外，在該授權模式下可以通過 refresh_token 來重新整理令牌以延長訪問授權時間，也是最為複雜的一種方式。

Implicit Grant（隱式模式）：該模式是所有授權模式中最簡單的一種，併為運行於瀏覽器中的指令碼應用做了優化。當用戶訪問該應用時，服務端會立即生成一個新的訪問令牌（access_token）並通過URL的#hash傳回客戶端。這時，客戶端就可以利用JavaScript等將其取出然後請求API介面。該模式不需要授權碼（code），當然也不會提供refresh token以獲得長期訪問的入口。

Resource Owner Password Credentials（密碼模式）：自己有一套使用者體系，這種模式要求使用者提供使用者名稱和密碼來交換訪問令牌（access_token）。該模式僅用於非常值得信任的使用者，例如API提供者本人所寫的移動應用。雖然使用者也要求提供密碼，但並不需要儲存在裝置上。因為初始驗證之後，只需將 OAuth 的令牌記錄下來即可。如果使用者希望取消授權，因為其真實密碼並沒有被記錄，因此無需修改密碼就可以立即取消授權。token本身也只是得到有限的授權，因此相比最傳統的 username/password 授權，該模式依然更為安全。

Client Credentials（客戶端模式）：沒有使用者的概念，一種基於 APP 的金鑰直接進行授權，因此 APP 的許可權非常大。它適合像資料庫或儲存伺服器這種對 API 的訪問需求。

簡單轉換能力-request-transformer and response transformer

Kong閘道器提供對輸入和輸出報文簡單轉換的能力，這部分內容後續再詳細展開介紹。從當前配置來看，主要是對訊息報文提供了Add, Replace,Rename,Append等各種簡單操作能力。

Kong閘道器和其它閘道器的一些對比。

從上面對比圖也可以看到，Kong閘道器在功能，效能，外掛可擴充套件性各方面都能夠更好的滿足企業API閘道器的需求。因此我們也是基於Konga來進一步定製對Kong閘道器的管控治理平臺。

在整個定製中增加了基於DB適配的Http Rest API介面的自動釋出，API服務自動化註冊，服務日誌採集和服務日誌查詢，常見對映模板定製，介面服務的自動化測試等方面的能力。

首先我們來看下阿里雲提供的API閘道器產品的功能介紹：

API 閘道器（API Gateway），是提供API託管服務，涵蓋API釋出、管理、運維、售賣的全生命週期管理。輔助使用者簡單、快速、低成本、低風險的實現微服務聚合、前後端分離、系統整合，向合作伙伴、開發者開放功能和資料。

阿里提供的API閘道器提供的關鍵功能，參考產品本身的功能文件說明，主要如下：

API 生命週期管理

支援包括API 註冊和接入釋出、API 測試、API 下線等生命週期管理功能。支援 API 日常管理、API 版本管理、API 快速回滾等維護功能。基本需要覆蓋API管理全生命週期。

全面的安全防護

支援多種認證方式，支援 HMAC (SHA-1，SHA-256) 演算法簽名。支援 HTTPS 協議，支援 SSL 加密。防攻擊、防注入、請求防重放、請求防篡改。（沒看到是否支援Auth2.0和具體的Token驗證機制）

靈活的許可權控制

使用者以 APP 作為請求 API 的身份，閘道器支援針對 APP 的許可權控制。只有已經獲得授權的 APP 才能請求相應的 API。API 提供者可以將呼叫某個API 的許可權主動授予給某個APP。若 API上架到 API 市場，購買者可以將已購買的 API 授權給自己的 APP。(沒看到是否基於IP進行控制，還是基於Token進行控制，即對於消費方分配獨立的Token資訊)

精準的流量控制

流量控制可以用於管控 API的被訪問頻率、APP的請求頻率、使用者的請求頻率。流量控制的時間單位可以是分鐘、小時、天。支援流控例外，允許設定特殊的 APP 或者使用者。（流量控制只支援服務執行頻率，沒看到可以基於資料量進行流控）

請求校驗

支援引數型別、引數值（範圍、列舉、正則、Json Schema）校驗，無效校驗會被 API 閘道器直接拒絕，以減少無效請求對後端造成的資源浪費，大幅降低後端服務的處理成本。（這個功能實際有一定的用處，並不會犧牲太多的效能，但是會實現一些簡單的引數完整性校驗能力。）

資料轉換

通過配置對映規則，實現前、後端資料翻譯。支援前端請求的資料轉換。支援返回結果的資料轉換。(暫時不清楚資料轉換功能能夠實現的能力）

監控報警

提供視覺化的API實時監控，包括：呼叫量、流量大小、響應時間、錯誤率，在陸續增加維度。支援歷史情況查詢，以便統籌分析。可配置預警方式（簡訊、Email），訂閱預警資訊，以便實時掌握API執行情況。

自動工具

自動生成 API 文件，可供線上檢視。API 閘道器提供多種語言 SDK 的示例。降低 API 的運維成本。提供視覺化的介面除錯工具，快速測試，快速上線。(當前網上也有不少的API介面文件自動生成工具可選）

API 市場

可將 API 上架到 API 市場，供更多開發者採購和使用。

從整個功能的介紹可以看到對於API的全生命週期管理（註冊，接入，代理，路由，負載均衡），安全，許可權，流量控制，監控和告警等是所有API閘道器都必須具備的功能。而對於API市場，API文件自動生成，請求的引數校驗，資料的轉換等則可以看做是擴充套件功能。

對於API市場往往是一個重要的擴充套件能力，即對於API介面服務可以作為商品一樣進行訂購和使用，並根據相應的呼叫次數，呼叫的資料量等條件進行計費處理。這我們我們說的PaaS平臺的服務層能力作為產品和服務釋出，能夠進行訂購生產訂單，能夠進行計費等完全是一個道理。

對於公有云上API閘道器存在的背景說明

對於類似亞馬遜，華為雲，阿里雲等公有云上為何要提供API閘道器類產品，其關鍵點還是在於一個企業如果內部的主動業務應用和系統都遷移到公有云後，那麼當企業需要將內部多個業務系統的共享或釋出給外部使用的時候如何做？這個時候必須要有一個API閘道器，來進行能力的統一發布，最基本是提供統一的服務目錄訪問，更加重要的是實現統一的安全管理，授權，服務日誌監控預警能力。

因此一個企業遷移到公有云後，只要存在內部多業務系統，多元件都需要釋出API介面能力給外部使用的時候，一定存在API閘道器的應用場景。

其它開源API閘道器

有贊團隊的API閘道器實踐

https://tech.youzan.com/api-gateway-in-practice/

有贊API閘道器目前承載著微商城、零售、微小店、餐飲、美業、AppSDK、部分PC、三方開發者等多個業務的呼叫，每天有著億級別的流量。

有贊後端服務最開始是由PHP搭建，隨著整個技術體系的升級，後面逐步從PHP遷移到基於Dubbo開發了一個新的框架Nova，相容Dubbo呼叫，同時支援呼叫PHP服務。於是閘道器也支援了新的Nova協議，這樣就有Dubbo、Http、Nova三種協議。

在這篇文章中提到的閘道器核心設計部分相關內容可以參考

非同步特性：我們使用Jetty容器來部署應用，並開啟Servlet3.0的非同步特性，由於閘道器業務本身就是呼叫大量業務介面，因此IO操作會比較頻繁，使用該特效能較大提升閘道器整體併發能力及吞吐量。

快取：為了進一步提升閘道器的效能，我們增加了一層分散式快取（借用Codis實現），將一些不經常變更的API元資料快取下來，這樣不僅減少了應用和DB的互動次數，還加快了讀取效率。

鏈式處理：在設計閘道器的時候，我們採用責任鏈模式來實現閘道器的核心處理流程，將每個處理邏輯看成一個Pipe，每個Pipe按照預先設定的順序先後執行

平滑限流：消除了簡單計數器限流帶來的短時間內流量不均的問題。目前閘道器支援IP、店鋪、API、應用ID和三方ID等多個維度的限流，也支援各維度的自由組合限流。

熔斷降級：使用Hystrix進行熔斷降級處理。Hystrix支援執行緒池和訊號量2種模式的隔離方案，內部也開發了一個基於Hystrix的服務熔斷平臺

預警監控：實時地從Kafka消費API呼叫日誌，如果發現某個API的RT或者錯誤次數超過配置的報警閾值，則會立即觸發報警

企業級API閘道器設計

https://cloud.tencent.com/developer/article/1080652

這篇文章是對企業級API閘道器設計必須系統化的產生，從API閘道器的概述，API閘道器所起的作用，當前主流的API閘道器功能對比分析，API閘道器的高可用性設計多方面進行了闡述。

閘道器層作為客戶端與服務端的一層擋板，主要起到了三大類作用：

隔離作用：作為企業系統邊界，隔離網路系統與內網系統。解耦作用：通過解耦，使得微服務系統的各方能夠獨立、自由、高效、靈活地調整。腳手架作用：提供了一個地點，方便通過擴充套件機制對請求進行一系列加工和處理。

API閘道器作為對外提供服務的入口，就像企業服務的大門。一方面，要有足夠的能力，應對大量的對外訪問，另一方面，還要給對內的服務提供一定的安全保障。除此之外，企業提供的API服務多種多樣，API閘道器要能夠對這些API的全生命週期進行便捷的管理，例如服務釋出、調整、下架、計費、監控等。

企業API閘道器在功能設計上主要應該考慮如下內容：

API 生命週期管理功能：覆蓋 API 的定義、測試、釋出的整個生命週期管理。

API開發和使用支援功能：

安全防護功能：API 請求到達閘道器需要經過身份認證、許可權認證，才能到達後端服務。流量控制功能：API呼叫次數，異常，分級。流控粒度：分鐘、小時、天。請求管理功能：可根據配置進行引數型別、引數值（範圍、列舉、正則）的校驗監控告警功能：提供實時、視覺化的 API 監控，呼叫量、呼叫方式、響應時間、錯誤率。API交易功能： 提供API交易市場，計量計費、Quota 控制、運營售賣等需求。

順著這篇文章，我們參考了另外一篇談如何設計高併發下API閘道器的一篇文章，重點對併發模型，SEDA基於事件的併發架構進行了闡述。

地址：https://mp.weixin.qq.com/s?__biz=MzI5MDEzMzg5Nw==&mid=412734308&idx=1&sn=f1c1bd5e22e2ae7dedf4b788a625e814&scene=21#wechat_redirect

傳統的併發程式設計模型主要有兩種：一種是Thread-based concurrency, 另一種是Event-driven concurrency。總結下兩種模式的特點如下：

基於執行緒的併發：每個任務一執行緒直線式的程式設計使用資源高昂，context切換代價高，競爭鎖昂貴，太多執行緒可能導致吞吐量下降，響應時間暴漲；

基於事件的併發：單執行緒處理事件的每個併發流實現為一個有限狀態機應用直接控制併發負載增加的時候，吞吐量飽和響應時間線性增長。

SEDA架構是目前雲端計算、微服務時代下一種優秀的訊息處理架構，而且歷經考驗，穩定可靠。SEDA架構的核心思想：把一個請求處理過程分成幾個Stage，每個Stage可由不同的微服務進行處理，不同資源消耗的Stage使用不同數量的執行緒來處理，微服務之間採用非同步通訊的模式。

開源API閘道器Goku

GoKu API Gateway，中文名：悟空API閘道器，是eoLinker旗下、國內首個企業級開源的go語言API閘道器，幫助企業進行API服務治理與API效能安全維護，為企業數字化賦能。

GoKu支援OpenAPI與微服務管理，支援私有云部署，實現API轉發、請求引數轉換、資料校驗等功能，提供圖形化介面管理，能夠快速管理多個API閘道器，提高API業務安全性。

碼雲地址：https://gitee.com/eolinker/goku-api-gateway官網地址：https://www.eolinker.com/product/api_gateway/

Goku API Gateway （悟空 API 閘道器）是執行在企業系統服務邊界上的微服務閘道器。當您構建網站、App、IOT甚至是開放API交易時，Goku API Gateway 能夠幫你將內部系統中重複的元件抽取出來並放置在Goku閘道器上執行，如進行使用者授權、訪問控制、防火牆、資料轉換等；並且Goku 提供服務編排的功能，讓企業可以快速從各類服務上獲取需要的資料，對業務實現快速響應。

Goku API Gateway 的社群版本（CE）擁有完善的使用指南和二次開發指南，程式碼使用純 Go 語言編寫，擁有良好的效能和擴充套件性，並且內建的外掛系統能夠讓企業針對自身業務進行定製開發。並且 Goku API Gateway 支援與 EOLINKER 旗下的 API Studio 介面管理平臺結合，對 API 進行全面的管理、自動化測試、監控和運維。

產品關鍵特性

控制檯：通過清晰的UI介面對閘道器叢集進行各項配置。叢集管理：Goku閘道器節點是無狀態的，配置資訊自動同步，支援節點水平拓展和多叢集部署。熱更新：無需重啟服務，即可持續更新配置和外掛。服務編排：一個編排API對應多個backend，backend的入參支援客戶端傳入，也支援backend間的引數傳遞；backend的返回資料支援欄位的過濾、刪除、移動、重新命名、拆包和封包；編排API能夠設定編排呼叫失敗時的異常返回。資料轉換：支援將返回資料轉換成JSON或XML。負載均衡：支援有權重的round-robin負載平衡。服務發現：從 Consul、Eureka 等註冊中心發現後端伺服器。HTTP(S)反向代理：隱藏真實後端服務，支援 Rest API、Webservice。多租戶管理：根據不同的訪問終端或使用者來判斷。訪問策略：支援不同策略訪問不同的API、配置不同的鑑權（匿名、Apikey、Basic）等。靈活的轉發規則：支援模糊匹配請求路徑，支援改寫轉發路徑等，可為不同訪問策略或叢集設定不同的負載。IP黑白名單。自定義外掛：允許外掛掛載在常見階段，例如before match，access和proxy。CLI: 使用命令列來啟動、關閉和重啟Goku。Serverless: 在轉發過程的每一個階段，都可以新增並呼叫自定義的外掛。請求日誌(access log)：僅記錄轉發的基本內容，自定義記錄欄位與排序順序，定期自動清理日誌。執行日誌(system log)：提供控制檯和節點的執行日誌，預設僅記錄ERROR等級的資訊，可將等級按實際情況調成INFO、WARN或DEBUG。可擴充套件：簡單易用的外掛機制方便擴充套件功能。高效能：效能在眾多閘道器之中表現優異。Open API：提供 API 對閘道器進行操作，便於整合。版本控制：支援操作的釋出和多次回滾。監控和指標：支援Prometheus、Graphite。

具體對比：/file/2020/08/19/20200819183312_1616.jpg 定期檢查節點執行狀態，若節點出現異常則通過郵件或者API傳送告警資訊，並自動嘗試重啟修復節點。實際我們看到對於API的監控檢查包括了兩個方面，一個是通過閘道器封裝後的API節點的監控檢查，一個是後端業務API服務的監控檢查。

API斷線重連：請求轉發失敗後，閘道器會進行一定次數的斷線重連，防止因網路閃斷等原因導致API訪問品質下降。這個類似我們說的服務重試機制，傳統ESB匯流排的標準能力。該功能還是有用，主要是為了防止網路閃斷引起的服務訪問異常。

在閘道器裡可以給不同的呼叫方或客戶端設定訪問策略，不同的訪問策略可以設定不同的 API 訪問許可權、鑑權方式以及外掛功能等。閘道器支援 開放策略 與 普通策略：

開放策略：系統自帶訪問策略，使用開放策略時不需要傳遞策略 ID 引數;普通策略：自定義訪問策略，需要傳遞策略 ID 引數。

閘道器的外掛分為 策略外掛 與 API外掛。

策略外掛包括：流量控制、鑑權、IP黑白名單等。API外掛包括：引數對映、額外引數、熔斷、服務降級等。

鑑權的物件為 策略 (Strategy) ，策略可表示為一個公司、一個業務部門或一個使用者。開源版閘道器支援以下鑑權方式：Public、Basic、Apikey。暫時沒有看到基於消費訪問IP地址的服務訪問鑑權，不清楚是否企業版由對應的IP認證鑑權支援。

日誌管理能力

網關係統的日誌分為兩大部分：請求日誌（access.log）和系統執行時日誌；執行時日誌又分為：控制檯的執行日誌（console.log）、各節點的執行日誌（node.log）。對於請求日誌可以詳細的配置日誌存放路徑，記錄週期，具體記錄的內容等。

整體相對來說，當前閘道器提供的日誌管理能夠偏弱，特別是日誌資訊的檢視，基於服務日誌執行進行的API介面服務的執行分析統計等方面的能力。

引數對映：功能具備，但是使用起來會比較麻煩，暫時沒看到圖形化或者表格方式的引數對映介面。對於引數對映不一定完全的圖形化，但是提供類似阿里雲API閘道器的表格化對映是一種可行的方式。

小豹API閘道器

http://www.xbgateway.com/architecture.html

這個是最近在網上查詢API閘道器相關資料的時候搜尋到的一個商用的API閘道器，從產品介紹材料來看，我們前面談過的閘道器的核心功能基本上全部包括，而且相當來說也比較完善。同時提供了一個較方便的API閘道器的治理管控平臺，可以方便的對API註冊接入和執行全生命週期， 方便對安全，流控，日誌各方面進行靈活管控。

下面我們看下網站對API閘道器架構特點的一些說明：

基於Netty NIO的響應式架構；分散式快取基於Redis；資料庫基於Mysql，分散式配置基於ZooKeeper

API配置快取，執行時不依賴DB，配置更新後自動通知各閘道器節點；

支援自定義元件，動態載入，在不中斷閘道器服務的情況下重新載入配置和執行元件；

API服務連續異常後自動熔斷和自我恢復，訪問異常、超時處理；

閘道器核心執行過程不寫磁碟IO，避免磁碟IO效能影響閘道器吞吐量；

Docker容器化支援，拆分閘道器、管理服務、第三方中介軟體依賴等映象，便於靈活擴容。

RestCloud API企業微服務API開發

http://www.restcloud.cn/restcloud/mycms/apigateway.html

RestCloud API閘道器是完全自主研發的面向企業級的API閘道器，一且以簡單、易用、輕量級為目標進行研發，同時兼顧作為企業級的服務匯流排可以替換企業原有的ESB產品，RestCloud是集ESB和API網關於一體的企業級閘道器產品。這個不僅僅提供了API閘道器， 也提供了微服務快速開發平臺，API服務治理平臺，DaaS等相關元件。

另外RestCloud本身還提供了Http Rest API介面的快速開發平臺，可以將資料庫表，表物件，1多多物件關係的快速的釋出為Http Rest API介面服務，同時支援多資料庫介面適配。