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

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

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 代理則負責處理和路由入站和出站的通訊。

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

• SSL/TLS 協定
• 用戶端身份驗證
• 集中記錄
• 跟蹤注入

然後使用 sidecar 代理作為每個 service 的入口點，以提供：

• 出站負載均衡
• 服務發現整合
• 服務間身份驗證
• 授權

sidecar 模式顯著增加了控制平面的複雜性，因為它只有在瞭解到整個應用拓撲後才能根據需要執行出站路由和負載均衡，然而應用拓撲卻經常有變更。 此外它還增加了數據平面的複雜性，因為 sidecar 代理必須透明地攔截來自本地應用的所有出站請求。 該模式在基於 sidecar 的 service mesh 模型上最容易實現，此類 service mesh 提供了 sidecar 代理、注入、流量捕獲以及模式所需的整合式控制平面。 sidecar 代理模式正逐漸成為service mesh 中最流行（儘管仍需完善）的方法，對從 service mesh 控制平面配置各個代理的多個團隊實現基於角色的存取控制。

NGINX 支援有效的 API 交付

如今，技術是實現創新、增長和盈利的主要差異化優勢。 API 是現代數位業務發展的「核心驅動」，支援企業存取服務和數據，從而為客戶、內部使用者和合作夥伴提供更出色的體驗。 您擁有的 API 越多，使用合適的現代 API 管理解決方案來簡化、擴展和保護 API 就變得越重要。

NGINX 提供了快捷的 API 管理解決方案，將 NGINX Plus 作為 API 閘道的卓越功能和性能與 NGINX Controller 相結合，使團隊能夠在多雲環境中大規模定義、發佈、保護、監控和分析 API。

資料來源：F5官網