微服務設計中的API閘道器模式

根據 Gartner 對微服務的定義：“微服務是範圍狹窄、封裝緊密、鬆散耦合、可獨立部署且可獨立伸縮的應用程式元件。”

與將模組高度耦合並部署為一個大的應用程式相比，微服務的目標是將應用程式充分分解或者解耦為鬆散耦合的許多微服務或者模組，這樣做對下面幾點有很大幫助：

• 每個微服務都可以獨立於應用程式中的同級服務進行部署、升級、擴充套件、維護和重新啟動。

• 通過自治的跨職能團隊進行敏捷開發和敏捷部署。

• 運用技術時具備靈活性和可擴充套件性

在微服務架構中，我們根據各自的特定需求部署不同的鬆耦合服務，其中每個服務都有其更細粒度的 API 模型，用以服務於不同的客戶端（Web，移動和第三方 API）。

1客戶端到微服務的連線

在考慮客戶端與每個已部署的微服務 直接通訊 的問題時，應考慮以下挑戰：

1. 如果微服務向客戶端公開了細粒度的 API，則客戶端應向每個微服務發出請求。在典型的單頁中，可能需要進行 多次伺服器往返，才能滿足請求。對於較差的網路條件下執行的裝置（例如移動裝置），這可能會更糟。

2. 微服務中存在的 多種通訊協議（例如 gRpc、thrift、REST、AMQP 等）使客戶端很難輕鬆採用所有這些協議。

3. 必須在每個微服務中實現 通用閘道器功能（例如身份驗證、授權、日誌記錄）。

4. 在不中斷客戶端連線的情況下，很難在微服務中進行更改。例如，在合併或劃分微服務時，可能需要重新編寫客戶端部分程式碼。

2API 閘道器

為了解決上述挑戰，人們引入了一個附加層，該附加層位於客戶端和伺服器之間，充當從客戶端到伺服器的反向代理路由請求。與物件導向設計的模式相似，它為封裝底層系統架構的 API 提供了一個單一的入口，稱為 API 閘道器。

簡而言之，它的行為就像 API 管理員一樣，但重要的是不要將 API 管理與 API Gateway 混為一談。

3API 閘道器的功能

路由

閘道器封裝了底層系統並與客戶端分離，為客戶端提供了與微服務系統進行通訊的單個入口點。

整合

API 閘道器整合了一些邊緣的重複功能，無需讓每個微服務都實現它們。它包括如下功能：

• 認證和授權

• 服務發現整合

• 快取響應結果

• 重試策略、熔斷器、QoS

• 限速和節流

• 負載均衡

• log 日誌、鏈路追蹤、關聯

• Header、query 字串 以及 claims 轉義

• IP 白名單

• IAM

• 集中式日誌管理（服務之間的 transaction ID、錯誤日誌等）

• 身份的提供方，驗證與授權

4後端服務前端模式（BFF Backend for Frontend）

它是 API 閘道器模式的一種變體。它提供了基於客戶端的多個閘道器，而不是提供給客戶端一個單一的入口點。目的是根據客戶端的需求提供量身定製的 API，從而消除了為所有客戶端製作通用 API 造成的大量的浪費。

到底需要多少 BFF

BFF 的基本概念是為每種使用者體驗開發利基後端。菲爾·卡爾薩多（PhilCalçado） 的指導建議是“一種體驗，一種 BFF”。如果跨客戶端（IOS 客戶端、Android 客戶端、Web 瀏覽器等）的要求有很大差異，並且單個代理或 API 的釋出時間有嚴格要求，則 BFF 是一個很好的解決方案。還應注意，更復雜的設計需要複雜的步驟。

GraphQL 與 BFF

GraphQL 是一種 API 的查詢語言。PhilCalçado 提出 BFF 和 GraphQL 的想法是相似的，但不是互斥的概念。他補充說，BFF 與你埠的形狀無關，而在於賦予客戶端對應用程式的自治權，您可以在其中構建與許多 BFF 或 OSFA（one-size-fits-all）的 GraphQL API。

5著名的 API 閘道器

Netflix API 閘道器：Zuul

Netflix 的流媒體服務可在 1000 多種不同型別的裝置（電視、機頂盒、智慧手機、遊戲系統、平板電腦等）上使用，在高峰時段可以每秒處理 50,000 個請求，這種需求是 OSFA （one-size-fits-all）的 REST API 難以滿足的，因此他們為每個裝置量身定製了 API 閘道器。

Netflix 的 Zuul 2 是所有進入 Netflix 雲基礎架構的請求的第一步。Zuul 2 大大改進了架構和功能，使我們的閘道器能夠處理、路由和保護 Netflix 的雲系統，並幫助為我們的 1.25 億會員提供最佳體驗。

亞馬遜 API 閘道器

AWS 提供了完備的託管服務，用於建立、釋出、維護、監視以及保護 REST、HTTP 和 WebSocket，開發人員可以在其中建立用於訪問 AWS 或其他 Web 服務的 API，並將資料儲存在 AWS 雲上面。

Kong API 閘道器

Kong Gateway 是一個開源的，輕量級的微服務 API 閘道器，可提供無與倫比的延遲效能優化和可伸縮性。如果您只需要這些基礎能力，那麼它就是很合適的選項。只需要增加更多節點就可以輕鬆橫向擴充套件。它以非常低的延遲來支援大量可變的工作負載。

其他 API 閘道器

• Apigee API Gateway

• MuleSoft

• Tyk.io

• Akana

• SwaggerHub

• Azure API Gateway

• Express API Gateway

• Karken D

選擇正確的閘道器

評估標準裡面，一些常見的指標包括簡便性、開源還是專有、可伸縮性和靈活性、安全性、後續功能、社群、管理（支援情況、監控和部署）、環境配置（安裝、配置、是否支援託管）、定價和文件等。

6API 組合與聚合

API 閘道器中的一些 API 請求直接對映到單個服務的 API 上，可以通過將請求路由到相應的微服務來提供服務。但是，在需要從多個微服務獲得結果的複雜 API 操作的情況下，可以通過 API 組合 / 聚合（分散 - 收集機制）來提供服務。在需要同步通訊的情況下，如果服務彼此依賴，則必須遵循鏈式組合模式。組合層必須支援很大一部分的 ESB / 整合功能，例如轉換、編排、彈性和穩定性模式。

根容器的部署必須配備特殊的分發器和聚合器功能（或微服務）。分發者負責分解成細粒度的任務，並將這些任務分發給微服務例項。聚合器負責聚合業務工作流從組合微服務中得出的結果。

API 閘道器和聚合

具備複雜功能的閘道器會增大測試和部署的難度。強烈建議大家避免在 API 閘道器中進行聚合和資料轉換。領域專屬的功能更應該遵循軟體開發實踐的定義，在應用程式的程式碼中完成。Netflix API Gateway Zuul 2 從他們在 Zuul 到原始系統的閘道器中，刪除了許多業務邏輯。 

Service Mesh 與 API 閘道器

微服務中的 Service Mesh 是處理程式間通訊的可配置網路基礎結構層。這和通常稱為 Sidecar 代理或 Sidecar 閘道器的東西很像。它提供了許多功能，例如：

• 負載均衡

• 服務發現

• 健康檢查

• 安全性

從表面上看，API 閘道器和 Service Mesh 似乎解決了相同的問題，因此好像是多餘的。它們確實解決了相同的問題，但是應用在不同的場景。API 閘道器被部署為業務解決方案的一部分，被外部的服務發現，處理縱向的流量（面對外部客戶端），但是，Service Mesh 是用來處理橫向流量（在不同的微服務之間）。

實現 Service Mesh 可避免在您自己的程式碼中出現一些彈性互動，例如熔斷器、服務發現、健康檢查以及服務觀察。對於少量的微服務，應考慮使用其他替代方法來進行故障管理，因為 Service Mesh 整合可能代價太大了。但對於大量的微服務，它的收益是顯著的。

結合這兩種技術可能是確保應用程式正常執行時間和彈性伸縮能力的一種有效方法，同時又可以確保您的應用程式易於使用。將兩者視為同樣的產品是不對的，最好將兩者視為在涉及微服務和 API 的部署中相輔相成的工具。

API 閘道器實現的注意事項：

• 可能產生的單點故障或者瓶頸

• 由於通過 API 閘道器進行了額外的網路跳轉以及複雜性風險，響應時間增長了。