來源：架構頭條（ID: ArchFront）
原文：http://dwz.date/crrw
作者：Bibek Shah
根據 Gartner 對微服務的定義：“微服務是范圍狹窄冬殃、封裝緊密璃岳、松散耦合斜脂、可獨立部署且可獨立伸縮的應用程序組件柱徙∨钔疲”
與將模塊高度耦合并部署為一個大的應用程序相比卢肃，微服務的目標是將應用程序充分分解或者解耦為松散耦合的許多微服務或者模塊糙臼，這樣做對下面幾點有很大幫助：
每個微服務都可以獨立于應用程序中的同級服務進行部署、升級禾怠、擴展返奉、維護和重新啟動。
通過自治的跨職能團隊進行敏捷開發(fā)和敏捷部署吗氏。
運用技術時具備靈活性和可擴展性
在微服務架構中衡瓶，我們根據各自的特定需求部署不同的松耦合服務，其中每個服務都有其更細粒度的 API 模型牲证，用以服務于不同的客戶端（Web，移動和第三方 API）关面。
客戶端到微服務的連接
在考慮客戶端與每個已部署的微服務直接通信的問題時坦袍，應考慮以下挑戰(zhàn)：
如果微服務向客戶端公開了細粒度的 API十厢，則客戶端應向每個微服務發(fā)出請求。在典型的單頁中捂齐，可能需要進行 多次服務器往返蛮放，才能滿足請求。對于較差的網絡條件下運行的設備（例如移動設備）奠宜，這可能會更糟包颁。
微服務中存在的 多種通信協(xié)議（例如 gRpc、thrift压真、REST娩嚼、AMQP 等）使客戶端很難輕松采用所有這些協(xié)議。
必須在每個微服務中實現通用網關功能（例如身份驗證滴肿、授權岳悟、日志記錄）。
在不中斷客戶端連接的情況下泼差，很難在微服務中進行更改贵少。例如，在合并或劃分微服務時堆缘，可能需要重新編寫客戶端部分代碼滔灶。
API 網關
為了解決上述挑戰(zhàn)，人們引入了一個附加層吼肥，該附加層位于客戶端和服務器之間录平，充當從客戶端到服務器的反向代理路由請求。與面向對象設計的模式相似潜沦，它為封裝底層系統(tǒng)架構的 API 提供了一個單一的入口萄涯，稱為 API 網關。
簡而言之唆鸡，它的行為就像 API 管理員一樣涝影，但重要的是不要將 API 管理與 API Gateway 混為一談。
API 網關的功能
路由
網關封裝了底層系統(tǒng)并與客戶端分離争占，為客戶端提供了與微服務系統(tǒng)進行通信的單個入口點燃逻。
整合
API 網關整合了一些邊緣的重復功能，無需讓每個微服務都實現它們臂痕。它包括如下功能：
認證和授權
服務發(fā)現集成
緩存響應結果
重試策略伯襟、熔斷器、QoS
限速和節(jié)流
負載均衡
log 日志握童、鏈路追蹤姆怪、關聯
Header、query 字符串 以及 claims 轉義
IP 白名單
IAM
集中式日志管理（服務之間的 transaction ID、錯誤日志等）
身份的提供方稽揭，驗證與授權
后端服務前端模式（BFF Backend for Frontend）
它是 API 網關模式的一種變體俺附。它提供了基于客戶端的多個網關，而不是提供給客戶端一個單一的入口點溪掀。目的是根據客戶端的需求提供量身定制的 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 網關
Netflix API 網關：Zuul
Netflix 的流媒體服務可在 1000 多種不同類型的設備（電視逗嫡、機頂盒、智能手機株依、游戲系統(tǒng)驱证、平板電腦等）上使用，在高峰時段可以每秒處理 50,000 個請求恋腕，這種需求是 OSFA （one-size-fits-all）的 REST API 難以滿足的抹锄，因此他們?yōu)槊總€設備量身定制了 API 網關。
Netflix 的 Zuul 2 是所有進入 Netflix 云基礎架構的請求的第一步荠藤。Zuul 2 大大改進了架構和功能伙单，使我們的網關能夠處理、路由和保護 Netflix 的云系統(tǒng)哈肖，并幫助為我們的 1.25 億會員提供最佳體驗吻育。
亞馬遜 API 網關
AWS 提供了完備的托管服務，用于創(chuàng)建淤井、發(fā)布布疼、維護摊趾、監(jiān)視以及保護 REST、HTTP 和 WebSocket缎除，開發(fā)人員可以在其中創(chuàng)建用于訪問 AWS 或其他 Web 服務的 API严就，并將數據存儲在 AWS 云上面。
Kong API 網關
Kong Gateway 是一個開源的，輕量級的微服務 API 網關，可提供無與倫比的延遲性能優(yōu)化和可伸縮性萨咕。如果您只需要這些基礎能力叠骑，那么它就是很合適的選項。只需要增加更多節(jié)點就可以輕松橫向擴展祟印。它以非常低的延遲來支持大量可變的工作負載肴沫。
其他 API 網關
Apigee API Gateway
MuleSoft
Tyk.io
Akana
SwaggerHub
Azure API Gateway
Express API Gateway
Karken D
選擇正確的網關
評估標準里面，一些常見的指標包括簡便性蕴忆、開源還是專有颤芬、可伸縮性和靈活性、安全性套鹅、后續(xù)功能站蝠、社區(qū)、管理（支持情況卓鹿、監(jiān)控和部署）菱魔、環(huán)境配置（安裝、配置吟孙、是否支持托管）澜倦、定價和文檔等。
API 組合與聚合
API 網關中的一些 API 請求直接映射到單個服務的 API 上杰妓，可以通過將請求路由到相應的微服務來提供服務藻治。但是，在需要從多個微服務獲得結果的復雜 API 操作的情況下巷挥，可以通過 API 組合 / 聚合（分散 - 收集機制）來提供服務桩卵。在需要同步通信的情況下，如果服務彼此依賴句各，則必須遵循鏈式組合模式吸占。組合層必須支持很大一部分的 ESB / 集成功能，例如轉換凿宾、編排矾屯、彈性和穩(wěn)定性模式。
根容器的部署必須配備特殊的分發(fā)器和聚合器功能（或微服務）初厚。分發(fā)者負責分解成細粒度的任務件蚕，并將這些任務分發(fā)給微服務實例孙技。聚合器負責聚合業(yè)務工作流從組合微服務中得出的結果。
API 網關和聚合
具備復雜功能的網關會增大測試和部署的難度排作。強烈建議大家避免在 API 網關中進行聚合和數據轉換牵啦。領域專屬的功能更應該遵循軟件開發(fā)實踐的定義，在應用程序的代碼中完成妄痪。Netflix API Gateway Zuul 2 從他們在 Zuul 到原始系統(tǒng)的網關中哈雏，刪除了許多業(yè)務邏輯。
Service Mesh 與 API 網關
微服務中的 Service Mesh 是處理進程間通信的可配置網絡基礎結構層衫生。這和通常稱為 Sidecar 代理或 Sidecar 網關的東西很像裳瘪。它提供了許多功能，例如：
負載均衡
服務發(fā)現
健康檢查
安全性
從表面上看罪针，API 網關和 Service Mesh 似乎解決了相同的問題彭羹，因此好像是多余的。它們確實解決了相同的問題泪酱，但是應用在不同的場景派殷。API 網關被部署為業(yè)務解決方案的一部分，被外部的服務發(fā)現墓阀，處理縱向的流量（面對外部客戶端）毡惜，但是，Service Mesh 是用來處理橫向流量（在不同的微服務之間）岂津。
實現 Service Mesh 可避免在您自己的代碼中出現一些彈性交互虱黄，例如熔斷器、服務發(fā)現吮成、健康檢查以及服務觀察橱乱。對于少量的微服務，應考慮使用其他替代方法來進行故障管理粱甫，因為 Service Mesh 集成可能代價太大了泳叠。但對于大量的微服務，它的收益是顯著的茶宵。
結合這兩種技術可能是確保應用程序正常運行時間和彈性伸縮能力的一種有效方法危纫，同時又可以確保您的應用程序易于使用。將兩者視為同樣的產品是不對的乌庶，最好將兩者視為在涉及微服務和 API 的部署中相輔相成的工具种蝶。
API 網關實現的注意事項：
可能產生的單點故障或者瓶頸
由于通過 API 網關進行了額外的網絡跳轉以及復雜性風險，響應時間增長了瞒大。
