選擇合適的 API 網關模式,實現有效的 API 交付
原文作者: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 相關的技術乾貨、互動問答、系列課程、活動資源:
- 選擇合適的 API 網關模式,實現有效的 API 交付
- 分享實錄|NGINX Gateway API(下)
- 分享實錄|NGINX Gateway API(上)
- 如何在 NGINX 中安全地分發 SSL 私鑰
- 課程實錄 | 從 0 搭建高可用 Wordpress 博客(上)
- 實現 10 倍應用性能提升的 10 個技巧
- 將 NGINX 部署為 API 網關,第 1 部分
- 避免 10 大 NGINX 配置錯誤(下)
- 如何應對突發的流量激增和服務器過載問題
- 解決 NGINX LDAP 參考實施中的安全問題
- 收藏!0基礎開源數據可視化平台FlyFish大屏開發指南
- 使用 NGINX 作為對象存儲網關
- 藉助 TCP 負載均衡和 Galera 集羣擴展 MySQL
- 一張小圖看盡 Nginx
- 在 Kubernetes 中實施零信任的七條準則
- API 網關 vs. Ingress Controller vs. Service Mesh,該怎麼選?
- NGINX QUIC 和 HTTP/3 開發路線圖
- NGINX Ingress Controller 2.0 版:那些你不得不知道的事兒
- 一把王者的時間,我就學會了 Nginx!
- NGINX 登頂全球 Web 服務器榜單,未來前景更為樂觀