如今，API網關經歷了一些身份危機。

• 它們是集中的共享資源，有助於將API暴露和治理到外部實體嗎？
• 它們是否聚集入口監控，嚴格控制用戶流量進出集群？
• 或者它們是某種API粘合膠水，為了更簡潔地表達API？具體取決於它可能具有的客戶類型？
• 服務網格是否會使API網關過時？

一些背景

隨著技術的快速發展，以及行業在技術和架構模式中的快速發展，你會想到“所有這一切都讓我頭暈目眩”。在這篇文章中，我希望簡化“API網關”的不同身份，澄清組織中哪些組可能使用API​​網關（他們試圖解決的問題），並重新關注第一原則。理想情況下，在本文結束時，您將更好地瞭解不同團隊在不同級別的API基礎架構的作用，以及如何從每個級別中獲取最大價值。

在我們深入研究之前，讓我們對API這個術語搞清楚。

我對API的定義：

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

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

相反，僅僅因為我們可以通過網絡與另一個軟件通信並不一定意味著遠程端點就等同於這裡定義的API。許多系統彼此通信，但是這種通信更加隨意地發生，並且通過耦合和其他因素進行即時交換。

我們創建API以提供對業務部分的深思熟慮的抽象，以實現新的業務功能以及偶然的創新。

在討論API網關時首先列出的是API管理。

API管理

很多人都在API管理方面考慮API網關。這是公平的。但是讓我們快速看看這個網關到底是做什麼的。

通過API Management，我們希望解決“當我們希望公開現有API以供其他人使用時”的問題，我們如何跟蹤誰使用這些API，實施關於允許誰使用這些API的策略，建立安全流以進行身份​​驗證和授權允許使用並構建可在設計時使用的服務目錄，以促進API使用併為有效治理奠定基礎。

我們希望解決“我們有這些現有的，策劃的API，我們希望與他人分享但按照我們的條款分享”的問題。

API管理還可以很好地允許用戶（潛在API消費者）自助服務，註冊不同的API消費計劃（想一想：指定價格點在給定時間範圍內每個端點的每個用戶的調用數）。我們能夠實施這些管理功能的基礎設施是我們的API流量通過的網關。在這一點上，我們可以執行諸如身份驗證，速率限制，指標收集，其他策略執行等操作。

利用API網關的API管理軟件示例：

• Google Cloud Apigee
• 紅帽3Scale
• Mulesoft
• Kong

在這個層面上，我們考慮API是如何最好地管理和允許訪問它們。我們沒有考慮服務器，主機，端口，容器甚至服務。

API管理（以及它們相應的網關）通常實現為由“平臺團隊”，“集成團隊”或其他API基礎架構團隊擁有的嚴格控制的共享基礎架構。通常這樣做是為了強制執行一定級別的治理，變更管理和策略。在某些情況下，即使這些基礎架構集中部署和管理，它們也可能支持更分散的物理部署。例如，Kong的首席技術官Marco Palladino在評論中指出，Kong可以選擇部署的組件來支持集中式或分散式模型。

有一點需要注意：我們要注意不要讓任何業務邏輯進入這一層。如前一段所述，API管理是共享基礎架構，但由於我們的API流量遍歷它，它傾向於重新創建“全知全能”（像企業服務總線）治理門戶，我們通過它必須全部協調以改變我們的服務。理論上這聽起來很棒。實際上，這可能最終成為組織瓶頸。有關更多信息，請參閱此文章：使用ESB，API管理和現在的應用程序網絡功能...服務網格？

集群入口

為了構建和實現API，我們專注於代碼，數據，生產力框架等方面。但是，要為這些提供價值的東西，必須對它們進行測試，部署到生產中並進行監控。當我們開始部署到雲原生平臺時，我們開始考慮部署，容器，服務，主機，端口等，並構建我們的應用程序以在此環境中生活。我們可能正在製作工作流程（CI）和管道（CD），以利用雲平臺快速移動，進行更改，將其置於客戶面前等等。

在這種環境中，我們可以構建和維護多個集群來託管我們的應用程序，並且需要某種方式來訪問這些集群內的應用程序和服務。以Kubernetes為例。我們可以使用Kubernetes Ingress控制器來允許訪問Kubernetes集群（集群中的其他所有內容都無法從外部訪問）。通過這種方式，我們可以非常嚴格地控制流量可能進入（甚至離開）我們的群集，具有明確定義的入口點，如域/虛擬主機，端口，協議等。

在這個級別，我們可能希望某種“入口網關”成為允許請求和消息進入集群的流量哨兵。在這個級別，你在考慮“我在我的集​​群中有這項服務，我需要集群外部的人才能調用它”。這可能是一個服務（暴露API），現有的整體，gRPC服務，緩存，消息隊列，數據庫等。有些人選擇將其稱為API網關，其中一些可能實際上做得更多比流量入口/出口，但重點是群集操作級別存在此級別的問題。由於我們傾向於部署更多集群（相對於單個高度多租戶集群），因此我們最終會有更多的入口點以及彼此交互的需求。

這些類型的入口實現的示例包括：

• Envoy Proxy 基於它構建的:
• Datawire Ambassador
• Solo.io Gloo
• Heptio Contour
• HAproxy
• Including OpenShift’s Router
• NGINX
• Traefik
• Kong

此級別的集群入口控制器由平臺團隊操作，但是這個基礎架構通常與更分散的自助服務工作流程相關聯（正如您期望從雲原生平臺那樣）。請參閱Weaveworks的優秀人員所描述的“GitOps”工作流程

API網關模式​​​​​​​

API網關”這一術語的另一個擴展是我聽到這個術語時通常會想到的是，而且是最接近的：API網關模式。Chris Richardson在第8章的“微服務模式”一書中做了很好的工作。我強烈建議將這本書和其他微服務模式教育用於本書。可以在他關於API Gatway Pattern的microservices.io網站上看到更快的遊覽簡而言之，API網關模式是為了策劃API，以便不同類別的消費者更好地使用它。此策展涉及API間接級別。您可能聽到的代表API網關模式的另一個術語是“前端後端”，其中“前端”可以是文字前端（UI），移動客戶端，物聯網客戶端，甚至是其他服務/應用程序開發人員。

在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模型，那麼實現API網關模式的API網關將被要求集成更多的Level 0請求（以及介於兩者之間的所有內容）而不是Level 1-3實現。

這些類型的網關實現仍然需要解決諸如速率限制，認證/授權，電路中斷，度量收集，流量路由等之類的事情。這些類型的網關可以在群集的邊緣用作群集入口控制器，也可以在群集的深處用作應用程序網關。

此類API網關的示例包括：

• Spring Cloud Gateway
• Solo.io Gloo
• Netflix Zuul
• IBM-Strongloop Loopback / Microgateway

這種類型的網關也可以使用更通用的編程或集成語言/框架來構建，例如：

• Apache Camel
• Spring集成
• Ballerina.io
• Eclipse Vert.x
• NodeJS

由於這種類型的API網關與應用程序和服務的開發密切相關，我們希望開發人員能夠參與幫助指定API網關公開的API，瞭解所涉及的任何mashup邏輯以及需要能夠快速測試和更改此API基礎結構。我們還希望操作或SRE對API網關的安全性，彈性和可觀察性配置有一些看法。此級別的基礎架構還必須適應不斷髮展的按需自助服務開發人員工作流程。再次參見GitOps模型以獲取更多信息。

帶上服務網格

在雲基礎架構上運行服務架構的一部分包括難以在網絡中構建適當級別的可觀察性和控制。在解決此問題的先前迭代中，我們使用應用程序庫和有希望的開發人員治理來實現此目的。然而，在規模和多語言環境中，服務網格技術的出現提供了更好的解決方案。服務網格通過透明實現為平臺及其組成服務帶來以下功能：

• 服務到服務（即東西向交通）的恢復能力
• 安全性包括最終用戶驗證，相互TLS，服務到服務RBAC / ABAC
• 黑盒服務可觀察性（專注於網絡通信），用於請求/秒，請求延遲，請求失敗，電路中斷事件，分佈式跟蹤等
• 服務到服務速率限制，配額執行等

精明的讀者會認識到，API網關和服務網格的功能似乎有些重疊。服務網格的目標是通過在L7上透明地解決任何服務/應用程序來解決這些問題。換句話說，服務網格希望融入服務（實際上沒有被編碼到服務的代碼中）。另一方面，API網關位於服務網格和應用程序（L8？）上方。

服務網格為服務，主機，端口，協議等（東/西流量）之間的請求流帶來價值。它們還可以提供基本的群集入口功能，以便為進/出流量帶來一些此功能。但是，這不應與API網關可以為進/出流量帶來的功能相混淆（如在群集的進/出和嚮應用程序或應用程序組的進/出）。

服務網格和API網關在某些領域的功能上重疊，但它們是互補的，因為它們生活在不同的層次並解決不同的問題。理想的解決方案是將每個組件（API Management，API Gateway，Service Mesh）即插即用，並在需要時在組件之間保持良好的界限（或者在不需要它們時將其排除）。

同樣重要的是找到適合您的分散開發人員和運營工作流程的這些工具的實現。儘管這些不同組成部分的術語和身份存在混淆，但我們應該依賴於第一原則並理解我們的架構中這些組件在何處帶來價值以及它們如何獨立存在並共存互補性。

寫在最後：

歡迎留言討論，如需Java方面的架構資料，我這裡剛好有一份，怎麼領取→→→關注+轉發 然後私信“架構資料” 即可領取

點關注，不迷路，持續更新！！！

閱讀更多 Java高級架構獅 的文章

關鍵字: 軟件 級別 科技