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

與將模塊高度耦合并部署為一個(gè)大的應(yīng)用程序相比，微服務(wù)的目標(biāo)是將應(yīng)用程序充分分解或者解耦為松散耦合的許多微服務(wù)或者模塊，這樣做對(duì)下面幾點(diǎn)有很大幫助：

• 每個(gè)微服務(wù)都可以獨(dú)立于應(yīng)用程序中的同級(jí)服務(wù)進(jìn)行部署、升級(jí)、擴(kuò)展、維護(hù)和重新啟動(dòng)。
• 通過(guò)自治的跨職能團(tuán)隊(duì)進(jìn)行敏捷開(kāi)發(fā)和敏捷部署。
• 運(yùn)用技術(shù)時(shí)具備靈活性和可擴(kuò)展性

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

客戶(hù)端到微服務(wù)的連接

在考慮客戶(hù)端與每個(gè)已部署的微服務(wù) 直接通信 的問(wèn)題時(shí)，應(yīng)考慮以下挑戰(zhàn)：

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

API 網(wǎng)關(guān)

為了解決上述挑戰(zhàn)，人們引入了一個(gè)附加層，該附加層位于客戶(hù)端和服務(wù)器之間，充當(dāng)從客戶(hù)端到服務(wù)器的反向代理路由請(qǐng)求。與面向?qū)ο笤O(shè)計(jì)的模式相似，它為封裝底層系統(tǒng)架構(gòu)的 API 提供了一個(gè)單一的入口，稱(chēng)為 API 網(wǎng)關(guān)。

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

API 網(wǎng)關(guān)的功能

路由

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

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

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

后端服務(wù)前端模式（BFF Backend for Frontend）

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

到底需要多少 BFF

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

GraphQL 與 BFF

GraphQL 是一種 API 的查詢(xún)語(yǔ)言。PhilCal?ado 提出 BFF 和 GraphQL 的想法是相似的，但不是互斥的概念。他補(bǔ)充說(shuō)，BFF 與你端口的形狀無(wú)關(guān)，而在于賦予客戶(hù)端對(duì)應(yīng)用程序的自治權(quán)，您可以在其中構(gòu)建與許多 BFF 或 OSFA（one-size-fits-all）的 GraphQL API。

著名的 API 網(wǎng)關(guān)

Netflix API 網(wǎng)關(guān)：Zuul

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

Netflix 的 Zuul 2 是所有進(jìn)入 Netflix 云基礎(chǔ)架構(gòu)的請(qǐng)求的第一步。Zuul 2 大大改進(jìn)了架構(gòu)和功能，使我們的網(wǎng)關(guān)能夠處理、路由和保護(hù) Netflix 的云系統(tǒng)，并幫助為我們的 1.25 億會(huì)員提供最佳體驗(yàn)。

亞馬遜 API

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

Kong API 網(wǎng)關(guān)

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

其他 API 網(wǎng)關(guān)

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

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

API 組合與聚合

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

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

API 網(wǎng)關(guān)和聚合

具備復(fù)雜功能的網(wǎng)關(guān)會(huì)增大測(cè)試和部署的難度。強(qiáng)烈建議大家避免在 API 網(wǎng)關(guān)中進(jìn)行聚合和數(shù)據(jù)轉(zhuǎn)換。領(lǐng)域?qū)俚墓δ芨鼞?yīng)該遵循軟件開(kāi)發(fā)實(shí)踐的定義，在應(yīng)用程序的代碼中完成。Netflix API Gateway Zuul 2 從他們?cè)?Zuul 到原始系統(tǒng)的網(wǎng)關(guān)中，刪除了許多業(yè)務(wù)邏輯。

Service Mesh 與 API 網(wǎng)關(guān)

微服務(wù)中的 Service Mesh 是處理進(jìn)程間通信的可配置網(wǎng)絡(luò)基礎(chǔ)結(jié)構(gòu)層。這和通常稱(chēng)為 Sidecar 代理或 Sidecar 網(wǎng)關(guān)的東西很像。它提供了許多功能，例如：

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

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

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

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

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

• 可能產(chǎn)生的單點(diǎn)故障或者瓶頸
• 由于通過(guò) API 網(wǎng)關(guān)進(jìn)行了額外的網(wǎng)絡(luò)跳轉(zhuǎn)以及復(fù)雜性風(fēng)險(xiǎn)，響應(yīng)時(shí)間增長(zhǎng)了。

原文鏈接：

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

關(guān)注我并轉(zhuǎn)發(fā)此篇文章，私信我“領(lǐng)取資料”，即可免費(fèi)獲得InfoQ價(jià)值4999元迷你書(shū)！