根據(jù) Gartner 對微服務的定義：“微服務是范圍狹窄、封裝緊密、松散耦合、可獨立部署且可獨立伸縮的應用程序組件?！?/p>

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

• 每個微服務都可以獨立于應用程序中的同級服務進行部署、升級、擴展、維護和重新啟動。
• 通過自治的跨職能團隊進行敏捷開發(fā)和敏捷部署。
• 運用技術時具備靈活性和可擴展性

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

客戶端到微服務的連接

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

1. 如果微服務向客戶端公開了細粒度的 API，則客戶端應向每個微服務發(fā)出請求。在典型的單頁中，可能需要進行 多次服務器往返，才能滿足請求。對于較差的網(wǎng)絡條件下運行的設備（例如移動設備），這可能會更糟。
2. 微服務中存在的 多種通信協(xié)議（例如 gRpc、thrift、REST、AMQP 等）使客戶端很難輕松采用所有這些協(xié)議。
3. 必須在每個微服務中實現(xiàn) 通用網(wǎng)關功能（例如身份驗證、授權、日志記錄）。
4. 在不中斷客戶端連接的情況下，很難在微服務中進行更改。例如，在合并或劃分微服務時，可能需要重新編寫客戶端部分代碼。

API 網(wǎng)關

為了解決上述挑戰(zhàn)，人們引入了一個附加層，該附加層位于客戶端和服務器之間，充當從客戶端到服務器的反向代理路由請求。與面向對象設計的模式相似，它為封裝底層系統(tǒng)架構的 API 提供了一個單一的入口，稱為 API 網(wǎng)關。

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

API 網(wǎng)關的功能

路由

網(wǎng)關封裝了底層系統(tǒng)并與客戶端分離，為客戶端提供了與微服務系統(tǒng)進行通信的單個入口點。

整合 API 網(wǎng)關整合了一些邊緣的重復功能，無需讓每個微服務都實現(xiàn)它們。它包括如下功能：

• 認證和授權
• 服務發(fā)現(xiàn)集成
• 緩存響應結果
• 重試策略、熔斷器、QoS
• 限速和節(jié)流
• 負載均衡
• log 日志、鏈路追蹤、關聯(lián)
• Header、query 字符串 以及 claims 轉義
• IP 白名單
• IAM
• 集中式日志管理（服務之間的 transaction ID、錯誤日志等）
• 身份的提供方，驗證與授權

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

它是 API 網(wǎng)關模式的一種變體。它提供了基于客戶端的多個網(wǎng)關，而不是提供給客戶端一個單一的入口點。目的是根據(jù)客戶端的需求提供量身定制的 API，從而消除了為所有客戶端制作通用 API 造成的大量的浪費。

到底需要多少 BFF

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

GraphQL 與 BFF

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

著名的 API 網(wǎng)關

Netflix API 網(wǎng)關：Zuul

Netflix 的流媒體服務可在 1000 多種不同類型的設備（電視、機頂盒、智能手機、游戲系統(tǒng)、平板電腦等）上使用，在高峰時段可以每秒處理 50,000 個請求，這種需求是 OSFA （one-size-fits-all）的 REST API 難以滿足的，因此他們?yōu)槊總€設備量身定制了 API 網(wǎng)關。

Netflix 的 Zuul 2 是所有進入 Netflix 云基礎架構的請求的第一步。Zuul 2 大大改進了架構和功能，使我們的網(wǎng)關能夠處理、路由和保護 Netflix 的云系統(tǒng)，并幫助為我們的 1.25 億會員提供最佳體驗。

亞馬遜 API

網(wǎng)關 AWS 提供了完備的托管服務，用于創(chuàng)建、發(fā)布、維護、監(jiān)視以及保護 REST、HTTP 和 WebSocket，開發(fā)人員可以在其中創(chuàng)建用于訪問 AWS 或其他 Web 服務的 API，并將數(shù)據(jù)存儲在 AWS 云上面。

Kong API 網(wǎng)關

Kong Gateway 是一個開源的，輕量級的微服務 API 網(wǎng)關，可提供無與倫比的延遲性能優(yōu)化和可伸縮性。如果您只需要這些基礎能力，那么它就是很合適的選項。只需要增加更多節(jié)點就可以輕松橫向擴展。它以非常低的延遲來支持大量可變的工作負載。

其他 API 網(wǎng)關

• Apigee API Gateway
• MuleSoft
• Tyk.io
• Akana
• SwaggerHub
• Azure API Gateway
• Express API Gateway
• Karken D

選擇正確的網(wǎng)關 評估標準里面，一些常見的指標包括簡便性、開源還是專有、可伸縮性和靈活性、安全性、后續(xù)功能、社區(qū)、管理（支持情況、監(jiān)控和部署）、環(huán)境配置（安裝、配置、是否支持托管）、定價和文檔等。

API 組合與聚合

API 網(wǎng)關中的一些 API 請求直接映射到單個服務的 API 上，可以通過將請求路由到相應的微服務來提供服務。但是，在需要從多個微服務獲得結果的復雜 API 操作的情況下，可以通過 API 組合 / 聚合（分散 – 收集機制）來提供服務。在需要同步通信的情況下，如果服務彼此依賴，則必須遵循鏈式組合模式。組合層必須支持很大一部分的 ESB / 集成功能，例如轉換、編排、彈性和穩(wěn)定性模式。

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

API 網(wǎng)關和聚合

具備復雜功能的網(wǎng)關會增大測試和部署的難度。強烈建議大家避免在 API 網(wǎng)關中進行聚合和數(shù)據(jù)轉換。領域專屬的功能更應該遵循軟件開發(fā)實踐的定義，在應用程序的代碼中完成。Netflix API Gateway Zuul 2 從他們在 Zuul 到原始系統(tǒng)的網(wǎng)關中，刪除了許多業(yè)務邏輯。

Service Mesh 與 API 網(wǎng)關

微服務中的 Service Mesh 是處理進程間通信的可配置網(wǎng)絡基礎結構層。這和通常稱為 Sidecar 代理或 Sidecar 網(wǎng)關的東西很像。它提供了許多功能，例如：

• 負載均衡
• 服務發(fā)現(xiàn)
• 健康檢查
• 安全性

從表面上看，API 網(wǎng)關和 Service Mesh 似乎解決了相同的問題，因此好像是多余的。它們確實解決了相同的問題，但是應用在不同的場景。API 網(wǎng)關被部署為業(yè)務解決方案的一部分，被外部的服務發(fā)現(xiàn)，處理縱向的流量（面對外部客戶端），但是，Service Mesh 是用來處理橫向流量（在不同的微服務之間）。

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

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

API 網(wǎng)關實現(xiàn)的注意事項：

• 可能產(chǎn)生的單點故障或者瓶頸
• 由于通過 API 網(wǎng)關進行了額外的網(wǎng)絡跳轉以及復雜性風險，響應時間增長了。

原文鏈接：

https://medium.com/dev-genius/microservices-design-api-gateway-pattern-980e8d02bdd5

關注我并轉發(fā)此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書！