微服務API閘道器 vs. 傳統企業級API閘道器

翻譯 | 李守超

原文 | https://www.getambassador.io/a ... ways/

導讀

企業API閘道器是一個很成熟的工具，市場上的相關成熟產品也很多。但是，在對輕量級、快速響應要求很高的微服務架構下，傳統企業級API閘道器作為企業的公共基礎設施，又顯得有些重了。在本文中，我們將討論業務目標（生產率與管理）的不同是如何要求我們實現一種完全不同的API閘道器。

在過去十年中，企業組織一直致力於通過定義良好的API公開內部的業務系統。如何將數百或數千個API安全地暴露給終端使用者（內部和外部），巨大的挑戰促使了API閘道器的出現。在對外發布服務時，傳統企業級API閘道器作為一個系統的後端總入口，承載著所有服務的組合路由轉換等工作。除此之外，我們一般也會把安全，限流，快取，日誌，監控，重試，熔斷等放到 API 閘道器來做。隨著時間的推移，API閘道器逐漸成為核心且重要的基礎架構之一。

隨著對雲原生和微服務的概念的不斷推廣和使用，我們開始遇到一些新的問題。區別於傳統企業級API閘道器，業界提出了旨在加速獨立服務團隊的開發工作流程的微服務API閘道器。微服務API閘道器為團隊提供了獨立釋出，監控和更新微服務的所有功能，關注於加速開發測試部署的工作流程。

微服務組織

在微服務組織中，小型開發團隊彼此獨立工作，以快速向客戶提供功能。為了使每個服務團隊獨立工作，通過高效的工作流程，服務團隊需要能夠：

釋出服務，以便其他人可以使用該服務

監控服務，觀察它的執行情況

測試並更新服務，以便可以繼續改進服務

團隊需要做到所有這些而不需要其他操作或平臺團隊的幫助，因為只要服務團隊需要另一個團隊，他們就不是所謂的獨立工作，進而導致瓶頸的出現。

對於服務釋出，微服務API閘道器為消費者提供靜態地址，並動態地將請求路由到適當的服務地址，這裡的服務地址一般指由服務團隊開發和維護的一個或多個服務的多個例項。此外，為安全性提供身份驗證和TLS終止是向其他使用者公開服務的典型考慮因素。

瞭解服務的終端使用者體驗對於改進服務至關重要。例如，軟體更新可能會無意中影響某些請求的延遲。微服務API閘道器可以很好地收集終端使用者流量的關鍵可觀察性的指標，因為它可以將流量路由到終端服務。

微服務API閘道器還支援將使用者請求動態路由到不同的服務版本以進行金絲雀測試。通過將一小部分終端使用者請求路由到新版本的服務，服務團隊可以安全地測試本次更新對一小部分使用者產生的影響。

微服務API閘道器與企業API閘道器

乍一看，上述用例可以通過以企業為中心的API閘道器來實現。雖然可以實現，但企業API閘道器和微服務API閘道器的實際重點有些不同：

自服務釋出

團隊需要能夠向客戶釋出新服務，而無需運營或API管理團隊。這種部署和釋出自助服務的能力使團隊能夠保持較高的釋出速度和頻率。雖然傳統的企業API閘道器可以提供用於釋出新服務的簡單機制（例如，REST API），但實際上只限於負責閘道器運維的團隊使用。限制單個團隊釋出API，主要原因是為了安全考慮：錯誤的API呼叫可能會對生產環境造成災難性影響。

微服務API閘道器允許服務團隊輕鬆和安全地釋出新的服務，是因為在微服務場景下，我們預設服務團隊對微服務有清楚的瞭解並承擔全部的責任。一旦有問題出現可以快速解決。而且微服務閘道器可以提供可配置的監控以方便發現問題，並提供除錯鉤子，例如檢查流量或流量轉移/複製。

監控和速率限制

API的常見商業模式是計量，其中根據API使用情況向消費者收取不同的費用。傳統的企業API閘道器在這一點上一般做的比較好：它們提供了監控每個客戶端API使用的功能，並且具備當客戶端超出配額時限制其使用的能力。

微服務閘道器也需要監控和速率限制，但原因有所不同。監控使用者可見的指標（如吞吐量，延遲和可用性）非常重要，它可以確保微服務的更新不會影響到終端使用者。穩定可靠的監控指標對於實現快速增量更新至關重要。速率限制則用於提高服務的整體彈性。當服務未按預期響應時，API閘道器可以限制傳入請求以允許服務恢復並防止級聯故障，也即微服務設計中經常使用的熔斷、降級等模式。

測試和更新

微服務應用程式具有多個服務，每個服務都是獨立更新的。上生產環境之前的自動化測試是必要的，但對於微服務來說還是不夠。金絲雀部署將一小部分生產流量路由到新服務版本，是幫助測試更新的重要工具。通過將新服務版本限制為一小部分使用者，即便出現問題，服務故障的影響是有限的。當測試穩定以後逐步替換舊版本，最終實現所有服務例項的版本更新。

在傳統的企業API閘道器中，路由用於隔離或組合/聚合變化的API版本。上生產環境前的自動化測試，上生產環境後的手動驗證和檢查，二者都是必須的。

總結

傳統的企業API閘道器旨在解決API管理的挑戰。雖然它們似乎可以解決微服務架構下的一些挑戰，但實際情況是微服務工作流提出了一組不同的需求。將微服務API閘道器整合到微服務的開發工作流程中，使服務團隊能夠快速，安全地自行釋出，監控和更新其服務。這將使我們能夠以更快的速度釋出軟體，並且具有前所未有的可靠性。