工作幾年了，API 網關還不懂？

譯者：蚊子 squirrel  來源：www.jianshu.com/p/9fab0982c6bb

原文：https://medium.com/solo-io/api-gateways-are-going-through-an-identity-crisis-d1d833a313d7

這些年來，API 網關正在經歷一些身份危機。

房間裏的大象：英語習語，指的是一些雖然顯而易見，但卻由於可能造成尷尬、爭執、觸及敏感或禁忌等原因被人刻意忽視的事情。

一些背景

隨着技術發展日新月異，整個行業通過技術和架構模式進行快速洗牌，如果你說 “所有這些都使我頭大”，也可以理解。

在本文中，我希望總結出 “API 網關” 的不同身份，闡明公司中的哪些羣體可以使用 API 網關（他們正在嘗試解決的問題），並重新關注這些首要原則。

理想情況下，在本文結束時，您將更好地瞭解 API 基礎架構在不同層級、對不同團隊的作用，同時明白如何從每個層級獲得最大價值。

我對 API 的定義：

一個明確定義和目的型接口，通過網絡調用，使軟件開發人員能夠以受控且方便的方式，對組織內的數據和功能進行編程訪問。

這些接口抽象了實現它們的技術架構細節。對於這些設計的網絡端點，我們希望獲得一定程度的文檔、使用指南、穩定性和向後兼容性。

相反，僅僅因爲我們可以通過網絡與另一軟件進行通信，並不一定意味着遠程端點就是符合此定義的 API。許多系統相互通信，但是通信發生更加隨意，並在與耦合和其他因素之間進行權衡。

我們創建 API 來爲業務的各個部分提供周全的抽象，以實現新的業務功能以及偶然的創新。

在談論 API 網關時，首先要提到的是 API 管理。

API 管理

通過 API Management，我們試圖解決 “何時公開現有的 API 供他人使用” 的問題，如何跟蹤誰使用這些 API，實施關於允許誰使用它們的政策，建立安全流程來進行身份驗證和授權許可，同時創建一個服務目錄（該目錄可在設計時使用以促進 API 使用，併爲有效治理奠定基礎）。

我們想解決 “我們擁有要與他人共享，但要按我們的條款共享這些現有的、經過精心設計的 API” 的問題。

API 管理也做得很好，它允許用戶（潛在的 API 使用者）進行自助服務，簽署不同的 API 使用計劃（請考慮：在給定時間範圍內，在指定價格點上，每個端點每個用戶的調用次數）。有能力完成這些管理功能的基礎架構就是網關（API 流量所經過的）。在網關層，我們可以執行身份驗證，速率限制，指標收集，其它策略執行等操作。

API Management Gateway

基於 API 網關的 API 管理軟件示例：

在這個級別上，我們考慮的是 API（如上定義）是如何最好地管理和允許對其進行訪問。我們不是在考慮服務器，主機、端口、容器甚至服務（另一個定義不明確的詞）。

API 管理（以及它們相應的網關）通常被作爲由 “平臺團隊”、“集成團隊” 或其它 API 基礎架構團隊所擁有的、嚴格控制的共享基礎架構。

需要注意的一件事：我們要小心，別讓任何業務邏輯進入這一層。如前一段所述，API 管理是共享的基礎結構，但是由於我們的 API 流量經過了它，因此它傾向於重新創建 “大包大攬的全能型”（認爲是企業服務總線）網關，這會導致我們必須與之協調來更改我們的服務。

從理論上講，這聽起來不錯。實際上，這最終可能成爲組織的瓶頸。有關更多信息，請參見這篇文章：

http://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/

集羣入口

爲了構建和實現 API，我們將重點放在代碼、數據、生產力框架等方面。但是，要想使這些事情中的任何一個產生價值，就必須對其進行測試，部署到生產中並進行監控。當我們開始部署到雲原生平臺時，我們開始考慮部署、容器、服務、主機、端口等，並構建可在此環境中運行的應用程序。我們可能正在設計工作流（CI）和管道（CD），以利用雲平臺快速遷移、更改、將其展示在客戶面前等等。

在這種環境中，我們可能會構建和維護多個集羣來承載我們的應用程序，並且需要某種方式來訪問這些羣集中的應用程序和服務。以 Kubernetes 爲例思考。我們可能會通過 Kubernetes Ingress 來訪問 Kubernetes 集羣（集羣中的其它所有內容都無法從外部訪問）。

這樣，我們就可以通過定義明確的入口點（例如域 / 虛擬主機、端口、協議等），嚴格控制哪些流量可以進入（甚至離開）我們的集羣。

在這個級別上，我們可能希望某種 “ingress 網關” 成爲允許請求和消息進入羣集的流量哨兵。在這個級別上，您的思考更多是“我的集羣中有此服務，我需要集羣外的人能夠調用它”。

這可能是服務（公開 API）、現有的整體組件、gRPC 服務，緩存、消息隊列、數據庫等。有些人選擇將其稱爲 API 網關，而且實際上可能會做比流量的入口 / 出口更多的事情，但重點是這個層級的問題是屬於集羣操作級別的。

Cluster Ingress Gateway

這些類型的 ingress 實現的示例包括：
Envoy Proxy 及其基礎上的項目包括：

基於其他反向代理 / 負載均衡器構建的其它組件：

此層級的集羣入口控制器由平臺團隊操作，但是，這部分基礎架構通常與更加去中心化的、自助服務工作流相關聯（正如您對雲原生平臺所期望的那樣）。

參見：https://www.weave.works/blog/gitops-operations-by-pull-request

API 網關模式

關於 “API 網關” 一詞的另一種擴展是我在聽到該術語時通常想到的，它是與 API 網關模式最相似的。Chris Richardson 在其 “微服務模式” 一書第 8 章很好地介紹了這種用法。

我強烈建議您將此書用於此模式和其他微服務模式學習資料。可在他的 microservices.io 網站 API Gatway Pattern 可以進行快速瀏覽。簡而言之，API 網關模式是針對不同類別的消費者來優化 API 的使用。

這個優化涉及一個 API 間接訪問。您可能會聽到另一個代表 API 網關模式的術語是 “前端的後端”，其中“前端” 可以是字符終端（UI）、移動客戶端、IoT 客戶端甚至其它服務 / 應用程序開發人員。

在 API 網關模式中，我們明顯簡化了一組 API 的調用，以模擬針對特定用戶、客戶端或使用者的 “應用程序” 內聚 API。回想一下，當我們使用微服務構建系統時，“應用程序”的概念就消失了。API 網關模式有助於恢復此概念。這裏的關鍵是 API 網關，一旦實現，它將成爲客戶端和應用程序的 API，並負責與任何後端 API 和其他應用程序網絡端點（不滿足上述 API 定義的端點）進行通信。

與上一節中的 Ingress 控制器不同，此 API 網關更接近開發人員的視角，而較少關注哪些端口或服務暴露以供集羣外使用的方面。此 “API 網關” 也不同於我們管理現有 API 的 API 管理視角。

此 API 網關將對後端的調用聚合在一起，這可能會公開 API，但也可能是與 API 描述較少的東西，例如對舊系統的 RPC 調用，使用不符合 “REST” 的協議的調用（如通過 HTTP 但不使用 JSON），gRPC，SOAP，GraphQL、websockets 和消息隊列。這種類型的網關也可用來進行消息級轉換、複雜的路由、網絡彈性 / 回退以及響應的聚合。

如果您熟悉 REST API 的 Richardson Maturity 模型，就會發現相比 Level 1–3，實現了 API 網關模式的 API 網關來集成了更多的 Level 0 請求（及其之間的所有內容）。

https://martinfowler.com/articles/richardsonMaturityModel.html

這些類型的網關實現仍需要解決速率限制、身份驗證 / 授權、斷路、度量收集、流量路由等問題。這些類型的網關可以在集羣邊緣用作集羣入口控制器，也可以在集羣內部用作應用程序網關。

API Gateway Pattern

此類 API 網關的示例包括：

也可以使用更通用的編程或集成語言 / 框架（例如：

由於這種類型的 API 網關與應用和服務的開發緊密相關，因此我們希望開發人員能夠參與幫助指定 API 網關公開的 API，瞭解所涉及的任何聚合邏輯以及快速測試和更改此 API 基礎架構的能力。

我們還希望運維人員或 SRE 對 API 網關的安全性、彈性和可觀察性配置有一些意見。這種層級的基礎架構還必須適應不斷髮展的、按需的、自助服務開發人員工作流。可以通過查看 GitOps 模型獲取更多這方面信息。

進入服務網格 (Service Mesh)

在雲基礎架構上運行服務架構的一部分難點是，如何在網絡中構建正確級別的可觀察性和控制。在解決此問題的先前迭代中，我們使用了應用程序庫和希望的開發人員治理來實現此目的。

但是，在大規模和多種開發語言環境下，服務網格技術的出現提供了更好的解決方案。服務網格通過透明地實現爲平臺及其組成服務帶來以下功能：

精明的讀者會認識到，API 網關和服務網格在功能上似乎有所重疊。服務網格的目的是通過在 L7 透明地解決所有服務 / 應用程序的這些問題。換句話說，服務網格希望融合到服務中（實際上它的代碼並沒有嵌入到服務中）。

另一方面，API 網關位於服務網格以及應用程序之上（L8？）。服務網格爲服務、主機、端口、協議等（東西向流量）之間的請求流帶來了價值。它們還可以提供基本的集羣入口功能，以將某些此功能引入南北向。但是，這不應與 API 網關可以帶來北 / 南流量的功能相混淆。（一個在集羣的南北向和一個是在一組應用程序的南北向）

Service Mesh 和 API 網關在某些方面在功能上重疊，但是在它們在不同層面互補，分別負責解決不同的問題。理想的解決方案是將每個組件（API 管理、API 網關、服務網格）合適的安置到您的解決方案中，並根據需要在各組件間建立良好的邊界（或在不需要時排除它們）。

同樣重要的是找到適合去中心化開發人員和運營工作流程的這些工具實現。即使這些不同組件的術語和標識存在混淆，我們也應該依靠基本原理，並瞭解這些組件在我們的體系結構中帶來的價值，從而來確定它們如何獨立存在和互補並存。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。

猜你喜歡