選擇合適的 API 網關模式,實現有效的 API 交付

語言: CN / TW / HK

原文作者: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 相關的技術乾貨、互動問答、系列課程、活動資源: