談?wù)勎⒎?wù)設(shè)計(jì)中的API網(wǎng)關(guān)模式

來源：架構(gòu)頭條（ID: ArchFront）

原文：http://dwz.date/crrw

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

與將模塊高度耦合并部署為一個(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)。

• 通過自治的跨職能團(tuán)隊(duì)進(jìn)行敏捷開發(fā)和敏捷部署。

• 運(yùn)用技術(shù)時(shí)具備靈活性和可擴(kuò)展性

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

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

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

1. 如果微服務(wù)向客戶端公開了細(xì)粒度的 API，則客戶端應(yīng)向每個(gè)微服務(wù)發(fā)出請(qǐng)求。在典型的單頁中，可能需要進(jìn)行 多次服務(wù)器往返，才能滿足請(qǐng)求。對(duì)于較差的網(wǎng)絡(luò)條件下運(yùn)行的設(shè)備（例如移動(dòng)設(shè)備），這可能會(huì)更糟。

2. 微服務(wù)中存在的 多種通信協(xié)議（例如 gRpc、thrift、REST、AMQP 等）使客戶端很難輕松采用所有這些協(xié)議。

3. 必須在每個(gè)微服務(wù)中實(shí)現(xiàn)通用網(wǎng)關(guān)功能（例如身份驗(yàn)證、授權(quán)、日志記錄）。

4. 在不中斷客戶端連接的情況下，很難在微服務(wù)中進(jìn)行更改。例如，在合并或劃分微服務(wù)時(shí)，可能需要重新編寫客戶端部分代碼。

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

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

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

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

路由

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

整合

API 網(wǎng)關(guān)整合了一些邊緣的重復(fù)功能，無需讓每個(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)模式的一種變體。它提供了基于客戶端的多個(gè)網(wǎng)關(guān)，而不是提供給客戶端一個(gè)單一的入口點(diǎn)。目的是根據(jù)客戶端的需求提供量身定制的 API，從而消除了為所有客戶端制作通用 API 造成的大量的浪費(fèi)

到底需要多少 BFF

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

GraphQL 與 BFF

GraphQL 是一種 API 的查詢語言。PhilCal?ado 提出 BFF 和 GraphQL 的想法是相似的，但不是互斥的概念。他補(bǔ)充說，BFF 與你端口的形狀無關(guān)，而在于賦予客戶端對(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 多種不同類型的設(shè)備（電視、機(jī)頂盒、智能手機(jī)、游戲系統(tǒng)、平板電腦等）上使用，在高峰時(shí)段可以每秒處理 50,000 個(gè)請(qǐng)求，這種需求是 OSFA （one-size-fits-all）的 REST API 難以滿足的，因此他們?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，開發(fā)人員可以在其中創(chuàng)建用于訪問 AWS 或其他 Web 服務(wù)的 API，并將數(shù)據(jù)存儲(chǔ)在 AWS 云上面。

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

Kong Gateway 是一個(gè)開源的，輕量級(jí)的微服務(wù) API 網(wǎng)關(guān)，可提供無與倫比的延遲性能優(yōu)化和可伸縮性。如果您只需要這些基礎(chǔ)能力，那么它就是很合適的選項(xiàng)。只需要增加更多節(jié)點(diǎn)就可以輕松橫向擴(kuò)展。它以非常低的延遲來支持大量可變的工作負(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)里面，一些常見的指標(biāo)包括簡(jiǎn)便性、開源還是專有、可伸縮性和靈活性、安全性、后續(xù)功能、社區(qū)、管理（支持情況、監(jiān)控和部署）、環(huán)境配置（安裝、配置、是否支持托管）、定價(jià)和文檔等。

API 組合與聚合

API 網(wǎng)關(guān)中的一些 API 請(qǐng)求直接映射到單個(gè)服務(wù)的 API 上，可以通過將請(qǐng)求路由到相應(yīng)的微服務(wù)來提供服務(wù)。但是，在需要從多個(gè)微服務(wù)獲得結(jié)果的復(fù)雜 API 操作的情況下，可以通過 API 組合 / 聚合（分散 - 收集機(jī)制）來提供服務(wù)。在需要同步通信的情況下，如果服務(wù)彼此依賴，則必須遵循鏈?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)該遵循軟件開發(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)層。這和通常稱為 Sidecar 代理或 Sidecar 網(wǎng)關(guān)的東西很像。它提供了許多功能，例如：

• 負(fù)載均衡

• 服務(wù)發(fā)現(xiàn)

• 健康檢查

• 安全性

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

實(shí)現(xiàn) Service Mesh 可避免在您自己的代碼中出現(xiàn)一些彈性交互，例如熔斷器、服務(wù)發(fā)現(xiàn)、健康檢查以及服務(wù)觀察。對(duì)于少量的微服務(wù)，應(yīng)考慮使用其他替代方法來進(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)故障或者瓶頸

• 由于通過 API 網(wǎng)關(guān)進(jìn)行了額外的網(wǎng)絡(luò)跳轉(zhuǎn)以及復(fù)雜性風(fēng)險(xiǎn)，響應(yīng)時(shí)間增長(zhǎng)了。

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問題，請(qǐng)聯(lián)系我們，謝謝！