到底什麼是API閘道器？它正經歷身份認同危機 - 軟體部落格

banq發表於2019-01-23
API

如今，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管理軟體示例：


在這個層面上，我們考慮API是如何最好地管理和允許訪問它們。我們沒有考慮伺服器，主機，埠，容器甚至服務。
API管理（以及它們相應的閘道器）通常實現為由“平臺團隊”，“整合團隊”或其他API基礎架構團隊擁有的嚴格控制的共享基礎架構。通常這樣做是為了強制執行一定級別的治理，變更管理和策略。在某些情況下，即使這些基礎架構集中部署和管理，它們也可能支援更分散的物理部署。例如，Kong的技術長Marco Palladino在評論中指出，Kong可以選擇部署的元件來支援集中式或分散式模型。
有一點需要注意：我們要注意不要讓任何業務邏輯進入這一層。如前一段所述，API管理是共享基礎架構，但由於我們的API流量遍歷它，它傾向於重新建立“全知全能”（像企業服務匯流排）治理門戶，我們透過它必須全部協調以改變我們的服務。理論上這聽起來很棒。實際上，這可能最終成為組織瓶頸。有關更多資訊，請參閱此文章：使用ESB，API管理和現在的應用程式網路功能...服務網格？

叢集入口
為了構建和實現API，我們專注於程式碼，資料，生產力框架等方面。但是，要為這些提供價值的東西，必須對它們進行測試，部署到生產中並進行監控。當我們開始部署到雲原生平臺時，我們開始考慮部署，容器，服務，主機，埠等，並構建我們的應用程式以在此環境中生活。我們可能正在製作工作流程（CI）和管道（CD），以利用雲平臺快速移動，進行更改，將其置於客戶面前等等。
在這種環境中，我們可以構建和維護多個叢集來託管我們的應用程式，並且需要某種方式來訪問這些叢集內的應用程式和服務。以Kubernetes為例。我們可以使用Kubernetes Ingress控制器來允許訪問Kubernetes叢集（叢集中的其他所有內容都無法從外部訪問）。透過這種方式，我們可以非常嚴格地控制流量可能進入（甚至離開）我們的群集，具有明確定義的入口點，如域/虛擬主機，埠，協議等。
在這個級別，我們可能希望某種“入口閘道器”成為允許請求和訊息進入叢集的流量哨兵。在這個級別，你在考慮“我在我的集​​群中有這項服務，我需要叢集外部的人才能呼叫它”。這可能是一個服務（暴露API），現有的整體，gRPC服務，快取，訊息佇列，資料庫等。有些人選擇將其稱為API閘道器，其中一些可能實際上做得更多比流量入口/出口，但重點是群集操作級別存在此級別的問題。由於我們傾向於部署更多叢集（相對於單個高度多租戶叢集），因此我們最終會有更多的入口點以及彼此互動的需求。
這些型別的入口實現的示例包括：


此級別的叢集入口控制器由平臺團隊操作，但是這個基礎架構通常與更分散的自助服務工作流程相關聯（正如您期望從雲原生平臺那樣）。請參閱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閘道器的示例包括：


這種型別的閘道器也可以使用更通用的程式設計或整合語言/框架來構建，例如：

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

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

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

精明的讀者會認識到，API閘道器和服務網格的功能似乎有些重疊。服務網格的目標是透過在L7上透明地解決任何服務/應用程式來解決這些問題。換句話說，服務網格希望融入服務（實際上沒有被編碼到服務的程式碼中）。另一方面，API閘道器位於服務網格和應用程式（L8？）上方。
服務網格為服務，主機，埠，協議等（東/西流量）之間的請求流帶來價值。它們還可以提供基本的群集入口功能，以便為進/出流量帶來一些此功能。但是，這不應與API閘道器可以為進/出流量帶來的功能相混淆（如在群集的進/出和嚮應用程式或應用程式組的進/出）。
服務網格和API閘道器在某些領域的功能上重疊，但它們是互補的，因為它們生活在不同的層次並解決不同的問題。理想的解決方案是將每個元件（API Management，API Gateway，Service Mesh）即插即用，並在需要時在元件之間保持良好的界限（或者在不需要它們時將其排除）。
同樣重要的是找到適合您的分散開發人員和運營工作流程的這些工具的實現。儘管這些不同組成部分的術語和身份存在混淆，但我們應該依賴於第一原則並理解我們的架構中這些元件在何處帶來價值以及它們如何獨立存在並共存互補性。

 

相關文章