利用已有開源軟體聚合成 API 閘道器思路介紹
https://www.cnblogs.com/savorboard/p/api-gateway.html
API 閘道器是一個伺服器，是系統的唯一入口。它封裝了系統內部架構，為每個客戶端提供一個定製的 API，同時它可能還有其它許可權（身份驗證、快取、請求分片與管理、靜態響應處理）。所有客戶端和消費端都要透過統一的閘道器接入微服務，並且在閘道器層處理所有非業務功能，閘道器也提供 REST/HTTP的訪問 API。
-
理想的閘道器服務——單節點閘道器：
-
理想的閘道器服務——單客戶端單節點閘道器服務：
相關開源 API 閘道器專案：
- Tyk（https://tyk.io/）：Tyk是一個開放原始碼的API閘道器，它是快速、可擴充套件和現代的。Tyk提供了一個API管理平臺，其中包括API閘道器、API分析、開發人員門戶和API管理皮膚。Try 是一個基於Go實現的閘道器服務。
- Kong（https://getkong.org/about/）：Kong是一個可擴充套件的開放原始碼API Layer(也稱為API閘道器或API中介軟體)。Kong 在任何RESTful API的前面執行，透過外掛擴充套件，它提供了超越核心平臺的額外功能和服務。
- Orange（http://orange.sumory.com/）：和Kong類似也是基於OpenResty的一個API閘道器程式，是由國人開發的，學姐也是貢獻者之一。
- Netflix zuul：Zuul是一種提供動態路由、監視、彈性、安全性等功能的邊緣服務。Zuul是Netflix出品的一個基於JVM路由和服務端的負載均衡器。
- apiaxle: Nodejs 實現的一個 API 閘道器。
- api-umbrella: Ruby 實現的一個 API 閘道器。
美團 Shepherd API閘道器服務
為什麼要做 API閘道器
現多為微服務架構，這就設計到對原始單體應用的內部服務拆分細化，然後進行獨立的部署和維護，這個過程帶來的是 API 規模的成倍增長，API 管理難度也日益增加。所以我們需要一個外部請求和內部服務中搭建一箇中間層，由中間層來統一維護並實現一些非業務功能（比如說協議轉換、身份認證、鑑權、流控、引數校驗、監控等通用功能）。
Shepherd API 閘道器架構
主要最佳化點在於對非業務功能的統一管理，並且支援自主配置，提升開發效率。
Shepherd 閘道器的整體架構包括：
- 控制面：管理平臺和監控中心組成，管理平臺主要完成 API 的全生命週期管理以及配置下發的工作；監控中心完成 API 請求監控以及資料收集和業務告警功能；
- 配置中心：完成控制面與資料面的互動，由 Lion 統一實現；
- 資料面：一個或多個
Shepherd服務端組成。一次完成的 API 請求，可能是從移動應用、Web應用、或者是內部系統發起的，在經過 Nginx 負載均衡後請求到達服務端。在服務端內部整合了一系列的基礎功能元件和業務自定義元件，透過泛化請求呼叫後端 RPC 服務、HTTP 服務、函式服務或者服務編排服務，最後返回響應結果。
控制面
在控制面內部，研發人員可以輕鬆完成 API 的全部生命週期的管理。
- 建立 API，完成引數錄入、DSL 指令碼生成；
- 透過文件或者 MOCK 功能提供對 API 的測試；
- 測試完成後，為保證服務上線的穩定性，提供釋出審批、灰度上線、版本回滾等一系列措施；
- API執行期間，監控 API 的呼叫情況並記錄請求日誌，一旦發現異常及時發出告警；
- 對於不再使用的 API 下線後，回收 API 所佔用的各類資源並等待重新啟用。
配置中心
使用自定義的 DSL 來描述 API 配置資訊，用於向 API 閘道器的資料面下發 API 路由、規則、元件等配置變更。
配置資訊說明：
- Name、Group：名字、所屬分組。
- Request：請求的域名、路徑、引數等資訊。
- Response：響應的結果組裝、異常處理、Header、Cookies資訊。
- Filters、FilterConfigs：API使用到的功能元件和配置資訊。
- Invokers：後端服務(RPC/HTTP/Function)的請求規則和編排資訊。
資料面
API 路由
API 閘道器的資料面在感知到 API 配置後，會在記憶體中建立請求路徑與 API 配置的路由資訊。通常在 HTTP 請求路徑上會包含一些路徑變數，考慮到效能問題，Shepherd 沒有采用正則匹配的方式，而是設計了兩種資料結構來儲存。
- 不包含路徑變數的請求，直接對映到 MAP 結構。其中 Key 就是完整的域名和路徑資訊，Value 是具體的 API 配置。
- 另一種是包含路徑變數的字首樹資料結構。因此透過字首匹配的方式，進行葉子節點的精確查詢（類似於 Gin 的路由匹配）。
功能元件
當請求流量命中API請求路徑進入服務端，具體處理邏輯由DSL中配置的一系列功能元件完成。閘道器提供了豐富的功能元件整合，包括鏈路追蹤、實時監控、訪問日誌、引數校驗、鑑權、限流、熔斷降級、灰度分流等，如下圖所示：
協議轉換/服務呼叫
API呼叫的最後一步，就是協議轉換以及服務呼叫了。閘道器需要完成的工作包括：獲取HTTP請求引數、Context本地引數，拼裝後端服務引數，完成HTTP協議到後端服務的協議轉換，呼叫後端服務獲取響應結果並轉換為HTTP響應結果。
高可用設計
效能隱患排除，保證高效能
對於外部請求，利用 Jetty IO 執行緒非同步提交到業務處理執行緒池，處理執行緒呼叫後端服務使用 RPC/HTTP 框架的非同步方式，釋放了由於網路等待引起的執行緒佔用。
後續改用 netty，效能進一步提升，QPS 達到 15000 以上。
服務隔離
- 叢集隔離：Shepherd 起初就按照業務線維度進行叢集隔離。
- 請求隔離：Shepherd 支援快慢執行緒池隔離。快慢執行緒池隔離主要用於一些使用了同步阻塞的 API，比如 SSO鑑權、自定義鑑權，可能導致長時間阻塞業務執行緒池。快慢隔離的原理是統計 API 請求的處理時間，將請求耗時長、超過容忍度閾值的 API 請求隔離到慢執行緒池，避免影響其它 API 的呼叫；
服務編排
服務編排的需求應運而生，服務編排是對既有服務進行編排呼叫，同時對獲取的資料進行處理。主要應用在資料聚合場景：一次HTTP請求返回的資料需要呼叫多個或多次服務（RPC或HTTP）才能獲取到完整的結果。
採用海盜中介軟體設計服務編排方法。