工作8年了，連API 閘道器都回答這麼太爛...

翻譯一篇API閘道器的文章，介紹了其三種角色：API管理、叢集ingress閘道器、API閘道器模式，最後還講了與service mesh的關係，透過此文可以更全面的理解API閘道器的作用。

這些年來，API閘道器正在經歷一些身份危機。

它們是否是集中的、共享的資源，從而促進了API對外部實體的暴露與治理？

它們是叢集入口（ingress）哨兵，從而可以嚴格控制哪些使用者流量進入或離開叢集嗎？

Java面試一戰到底（基礎卷）

檢視

或者它們根據自己擁有的客戶端型別，使用某種API結合膠水來更簡潔地表達API？

當然，房間裡的大象和我經常聽到的一個問題：“服務網格會使API閘道器過時嗎？

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

一些背景

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

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

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

我對API的定義：

一個明確定義和目的型介面，透過網路呼叫，使軟體開發人員能夠以受控且方便的方式，對組織內的資料和功能進行程式設計訪問。

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

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

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

在談論API閘道器時，首先要提到的是API管理。

API管理

Java核心技術 卷I 基礎知識（原書第11版）

檢視

許多人從API管理的角度考慮API閘道器。這是公平的。但是，讓我們快速看一下此類閘道器的功能。

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

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

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

API Management Gateway

基於API閘道器的API管理軟體示例：

Google Cloud Apigee

Red Hat 3Scale

Mulesoft

Kong

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

API管理（以及它們相應的閘道器）通常被作為由“平臺團隊”、“整合團隊”或其它API基礎架構團隊所擁有的、嚴格控制的共享基礎架構。

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

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

叢集入口

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

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

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

在這個級別上，我們可能希望某種“ingress閘道器”成為允許請求和訊息進入群集的流量哨兵。在這個級別上，您的思考更多是“我的叢集中有此服務，我需要叢集外的人能夠呼叫它”。

這可能是服務（公開API）、現有的整體元件、gRPC服務，快取、訊息佇列、資料庫等。有些人選擇將其稱為API閘道器，而且實際上可能會做比流量的入口/出口更多的事情，但重點是這個層級的問題是屬於叢集操作級別的。

Cluster Ingress Gateway

這些型別的ingress實現的示例包括：

Envoy Proxy 及其基礎上的專案包括：

Datawire Ambassador

Solo。io Gloo

Heptio Contour

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

HAProxy

OpenShift’s Router （based on HAProxy）

NGINX

Traefik

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

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請求（及其之間的所有內容）。

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

API Gateway Pattern

此類API閘道器的示例包括：

Spring Cloud Gateway

Netflix Zuul

IBM-Strongloop Loopback/Microgateway

也可以使用更通用的程式設計或整合語言/框架（例如：

Apache Camel

Spring Integration

Ballerina。io

Eclipse Vert。x

NodeJS

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

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

進入服務網格（Service Mesh）

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

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

服務到服務（即東西向流量）的彈性

安全性包括終端使用者身份驗證、相互TLS、服務到服務RBAC / ABAC

黑盒服務的可觀察性（專注於網路通訊），例如請求/秒、請求延遲、請求失敗、熔斷事件、分散式跟蹤等

服務到服務速率限制，配額執行等

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

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

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

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