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

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

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

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

• 每個微服務(wù)都可以獨立于應(yīng)用程序中的同級服務(wù)進行部署、升級、擴展、維護和重新啟動。

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

• 運用技術(shù)時具備靈活性和可擴展性

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

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

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

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

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

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

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

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

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

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

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

路由

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

整合

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

• 認證和授權(quán)

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

• 緩存響應(yīng)結(jié)果

• 重試策略、熔斷器、QoS

• 限速和節(jié)流

• 負載均衡

• log 日志、鏈路追蹤、關(guān)聯(lián)

• Header、query 字符串 以及 claims 轉(zhuǎn)義

• IP 白名單

• IAM

• 集中式日志管理（服務(wù)之間的 transaction ID、錯誤日志等）

• 身份的提供方，驗證與授權(quán)

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

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

到底需要多少 BFF

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

GraphQL 與 BFF

GraphQL 是一種 API 的查詢語言。PhilCal?ado 提出 BFF 和 GraphQL 的想法是相似的，但不是互斥的概念。他補充說，BFF 與你端口的形狀無關(guān)，而在于賦予客戶端對應(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è)備（電視、機頂盒、智能手機、游戲系統(tǒng)、平板電腦等）上使用，在高峰時段可以每秒處理 50,000 個請求，這種需求是 OSFA （one-size-fits-all）的 REST API 難以滿足的，因此他們?yōu)槊總€設(shè)備量身定制了 API 網(wǎng)關(guān)。

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

亞馬遜 API 網(wǎng)關(guān)

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

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

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

其他 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)

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

API 組合與聚合

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

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

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

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

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

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

• 負載均衡

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

• 健康檢查

• 安全性

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

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

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

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

• 可能產(chǎn)生的單點故障或者瓶頸

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

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