選擇合適的 API 閘道器模式，實現有效的 API 交付

語言: CN / TW / HK
時間 2023-03-15 22:02:54
主題:

原文作者：Elle Poole Sidell of F5

原文連結：選擇合適的 API 閘道器模式，實現有效的 API 交付

轉載來源：NGINX 官方網站

NGINX 唯一中文官方社群 ，盡在 nginx.org.cn

ProgrammableWeb 的 API 目錄自 2005 年以來一直在跟蹤外部可用的 API，這個數字在 2019 年 6 月突破了 22,000 大關。在此之前的 4 年裡，釋出的 API 數量增長了近 60%，這表明 API 經濟不僅增長強勁，而且還將持續下去。

API 是許多業務的核心，能夠創造巨大的價值和收入。現在，IT 組織要想保持領先，就必須找到一種管理和控制 API 訪問的方法，而且這一需求比以往任何時候都迫切。

API 管理的重要性

隨著企業開始從單體應用過渡到基於微服務的應用，他們還意識到 API 不僅可以促進高效的數字化通訊，還可以成為新的收入來源。例如，Salesforce.com 有一半以上的年收入來自其 API，而 Expedia.com 有近 90% 的收入依賴於 API 經濟。

茲事體大，企業不能容忍其 API 架構出現任何閃失，他們必須要確保 API 具備出色的效能、可控性和安全性。

API 閘道器 ≠ API 管理

雖然“API 閘道器”和“API 管理”這兩個詞語有時被互換使用，但要注意其中的區別。

API 閘道器是 API 訪問許可權的“門衛”，負責保護和管理 API 使用者與暴露這些 API 的應用之間的流量。API 閘道器通常負責處理身份驗證和授權、請求路由、速率限制以避免系統過載、防護 DDoS 攻擊、解除安裝 SSL/TLS 流量以提高效能以及處理錯誤或異常。

而 API 管理是指在 API 的整個生命週期內管理 API 的過程，包括定義和釋出 API、監控 API 效能、分析使用模式以創造最大業務價值等。

常見的 API 閘道器部署模式

那麼，如何才能有效交付 API 呢？

作為全球首屈一指的 API 閘道器，NGINX 交付了當今網路上超過一半的 API 流量。雖然模式沒有對錯之分，但有一些 API 閘道器模式是最常用的，我們在此進行了總結。

集中式邊緣閘道器

這是最常見的 API 閘道器模式，採用了傳統的應用交付控制器 (ADC) 架構。在這種模式下，閘道器幾乎可以處理所有事情，包括：

  • SSL/TLS 解除安裝
  • 身份驗證
  • 授權
  • 請求路由
  • 速率限制
  • 請求/響應操作
  • Facade 路由

當從集中治理的單體應用暴露應用服務時，這種方法非常合適，但對於微服務架構或是總有頻繁更改的情況就差點意思了 —— 傳統邊緣閘道器都是針對南北向流量進行優化，並不能高效處理分散式微服務環境中產生的大量東西向流量。

雙層閘道器

隨著服務逐漸變得小型化和分散化，許多企業轉向了雙層（多層）閘道器模式，將多個閘道器的角色分離開來。

這種方法將安全閘道器作為第一層，以管理：

  • SSL/TLS 解除安裝
  • 身份驗證
  • 集中式連線和請求日誌記錄
  • 跟蹤注入

將路由閘道器作為第二層，以處理：

  • 授權
  • 服務發現
  • 負載均衡

在一些情況下，我們需要考慮分散的 service 的靈活性和功能獨立擴充套件的需求。雙層閘道器模式最適合這樣的情況。但是，當有多個團隊管理不同的環境和應用時，這種方法可能會帶來問題，因為它不支援分散式控制。

微閘道器

微閘道器模式建立在雙層閘道器方法之上，為各個 DevOps 團隊提供了專用閘道器，這不僅可以幫助他們管理 service 之間的流量（東西向流量），而且還支援在不影響其他應用的情況下進行變更。

此模式在邊緣提供了以下功能：

  • SSL/TLS 解除安裝
  • 路由
  • 速率限制

然後企業再為每個 service 新增獨立的微閘道器，以管理：

  • 負載均衡
  • 服務發現
  • 每個 API 的身份驗證

儘管微閘道器的設計初衷是與微服務協同工作，但它們也為實現一致性和可控性增加了阻力。每個微閘道器可能都有一組不同的策略和安全規則，並且需要整合多個 service 的監控資訊和指標。微閘道器很容易適得其反 —— 原本是為了儘量“小”，結果卻往往需要根據業務目標實施全量的 API 配置。

per-pod 閘道器

per-pod 閘道器模式將代理閘道器嵌入到了各個 pod 或容器中，從而完善了微閘道器模式。閘道器負責管理到 pod 的入向流量，應用了身份驗證和速率限制等策略，然後將請求傳遞到本地微服務。

per-pod 閘道器模式不執行任何路由或負載均衡，因此通常與上文提到的任一模式結合部署。具體來說，您可能會使用 per-pod 閘道器執行以下部分或全部功能：

  • pod 中應用的 SSL/TLS 解除安裝
  • 跟蹤和指標生成
  • 身份驗證
  • 速率限制和佇列
  • 錯誤處理，包括斷路器式的錯誤訊息

per-pod 閘道器通常是輕量級的，並且其配置是靜態的。它僅將流量轉發到本地微服務例項，因此當應用拓撲發生變化時不需要進行重新配置。如果需要更改其中一項策略，則可以使用新的代理配置重新部署微服務 pod。

Sidecar（邊車）閘道器和 service mesh（服務網格）

Sidecar 閘道器模式將閘道器部署為微服務的出入向代理，這允許 service 直接進行相互通訊，sidecar 代理則負責處理和路由入站和出站的通訊。

此模式使用邊緣閘道器管理：

如欲瞭解本文後續內容，請點選《選擇合適的 API 閘道器模式，實現有效的 API 交付》檢視後續內容。

NGINX 唯一中文官方社群 ，盡在 nginx.org.cn

更多 NGINX 相關的技術乾貨、互動問答、系列課程、活動資源：

「」