微服務API網關 vs. 傳統企業級API網關

翻譯 | 李守超
原文 | https://www.getambassador.io/about/microservices-api-gateways/

導讀

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

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

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

微服務組織

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

1.發布服務，以便其他人可以使用該服務
2.監控服務，觀察它的運行情況
3.測試并更新服務，以便可以繼續改進服務

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

對于服務發布，微服務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網關集成到微服務的開發工作流程中，使服務團隊能夠快速，安全地自行發布，監控和更新其服務。這將使我們能夠以更快的速度發布軟件，并且具有前所未有的可靠性。

本文由博云研究院翻譯發表，轉載請注明出處。