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 代理則負責處理和路由入站和出站的通信。
此模式使用邊緣網關管理：Sidecar 網關模式将網關部署為微服務的出入向代理，這允許 service 直接進行互相通信，sidecar 代理則負責處理和路由入站和出站的通信。
此模式使用邊緣網關管理：
SSL/TLS 終止
用戶端身份驗證
集中 logging
跟蹤注入
然後使用 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。