​簡介：下文將為你解說雲原生閘道器如何助你解決一系列痛點，優雅玩轉雲上微服務架構升級。

作者：百丈

隨著雲原生技術的發展，微服務的架構選型也是日新月異。在 Kubernetes 重塑運維體系的雲時代，我們在安全、降本提效、精細化運營等方面都有了更高的要求和更多的選擇。曾經關炙手可熱的 Zuul/SpringCloud Gateway/Kong 等在其閘道器位置上開始顯得力不從心。它們欠缺發現容器服務的能力，效能可能不如 Nginx Ingress，可觀測、安全等方面都需要二次開發再整合，這些關鍵短板都阻礙著技術發展。今天來看雲原生閘道器如何助你解決這些痛點，優雅玩轉雲上微服務架構升級。

微服務（閘道器）的發展

微服務發展大事記

​

1. 微服務從單點支援向平臺解決方案發展，例如 SpringCloud 解決方案、 Kubernetes 體系。
    
2. 開源和商業產品融合得更加緊密，雲原生的發展讓技術從業者有了更多的選擇。

微服務閘道器的變化

​

1. 2013 ZUUL：Netflix 開源的負載均衡元件，簡單易上手，不過早期的 ZUUL 1 效能上限稍低。
2. 2015 KONG：基於 Nginx 的 API 閘道器，效能強勁，Lua 國內開發者相對較少。
3. 2016 SpringCloud Gateway：閘道器開始作為整個微服務解決方案的門面出現。
4. 2019 Ambasssador（現在更名 Emissaey-ingress）：支援 Kubernetes ingress 標準，且與 Istio 無縫整合。

微服務逐步向平臺解決方案發展的同時，對閘道器的整合能力也有了更高的需求。這也是我們看到了這個趨勢，雲原生閘道器應運而生，而且雲原生閘道器不僅集齊了他們的優點，而且功能更豐富、效能更強勁、穩定更可靠。  

Kubernetes 微服務

這裡為什麼單獨提 Kubernetes 微服務？這需要回到沒有 Kubernetes 的時候採用微服務架構我們碰到哪些問題？

1. 拆分了微服務後相應的構建部署工作量開始翻倍，運維壓力急劇提升；
2. 隨著業務迭代，微服務之間呼叫鏈路變的複雜，強弱依賴不清晰，故障/瓶頸排查困難；
3. 不同業務團隊使用異構的服務框架或技術棧，相互依賴整合成本增加。

通過合理的拆分服務可以降低協作成本及控制變更風險，這是微服務思想帶來的價值，然而隨之而來的也有巨大的治理難度和運維壓力。

不過 Kubernetes 以其完整的網路、服務、負載均衡的標準定義似乎解決了我們不少問題。

統一的服務定義及服務發現機制

得益於 Kubernetes 的網路模型和 Pod 標準，Kubernetes Service 可以將執行在一組 Pods  [2]上的應用程式抽象為網路服務（Kubernetes 微服務），你無需修改應用程式即可使用不熟悉的服務發現機制。Kubernetes 為 Pods 提供自己的 IP 地址，併為一組 Pod 提供相同的 DNS 名， 並且可以在它們之間進行負載均衡。

userspace 代理模式：

​

​

​

Ingress 公開了從叢集外部到叢集內服務的 HTTP 和 HTTPS 路由。流量路由由 Ingress 資源上定義的規則控制。

​

技術趨勢及痛點

雲原生時代的高要求和可選擇

Kubernetes 是好，同時其龐大的體系和眾多的概念標準也給技術從業者帶來了學習成本，DevOps 似乎比之前多了不少的工作量，好在雲原生時代，商業化產品滿足高要求的同時給了我們更多的選擇。

​

從技術的角度，雲原生架構是基於雲原生技術的一組架構原則和設計模式的集合，旨在將雲應用中的非業務程式碼部分進行最大化的剝離，從而讓雲設施接管應用中原有的大量非功能特性(如彈性、韌性、安全、 可觀測性、灰度等)，使業務不再有非功能性業務中斷困擾的同時，具備輕量、敏捷、高度自動化的特點。

精細化運營的需求

微服務架構的一路發展過來，從簡單的拆分服務到服務發現機制，再到支援 Sidecar 代理治理流量，最終的形態是什麼樣的？或者我們技術需求是怎麼樣？

簡單的拆分

​

Sidecar代理流量

雲原生架構成熟度模型 & API 安全質量報告

在雲原生時代，雲原生微服務體系將充分利用雲資源的高可用和安全體系，讓應用獲得更有保障的彈性、 可用性與安全性。應用構建在雲所提供的基礎設施與基礎服務之上，充分利用雲服務所帶來的便捷性、穩定性， 降低應用架構的複雜度。雲原生的微服務體系也將幫助應用架構全面升級，讓應用天然具有更好的可觀測性、 可控制性、可容錯性等特性。

我們可能需要類似上述一個模型描述架構在服務化能力、彈效能力、可觀測性及自動化能力等維度的成熟度，雖然這樣比較全面，似乎不太適合總結溝通。如果用簡單概念來描述，筆者總結幾個階段層次：

1. 極致彈性：應對突發流量，彈效能力是重要的手段，是否極致對應著故障的恢復速度，彈效能力有時候還依賴於服務化程度。
2. 可觀測體驗：能夠應對突發流量後開始關注效能優化及故障處理，體系化的可觀測體驗及指標資料對我們的治理工作至關重要。
3. 故障無感自愈：能夠 360 度發現問題就能總結規律制定常用的預案及檢查機制，常規故障即可自動化恢復。

最重要的結果衡量還有我們使用者的體驗，比較好代表使用者的應該就是 API 安全質量報告，如果 API 的可用率提升了，如果 API 的響應 RT 減少了，這顯然說明架構升級/治理給我們帶來了巨大的價值，滿足精細化運營的需求。

架構升級的痛點

架構升級（治理）能帶來的價值有目共睹，甚至我們也有了相關架構持續演進的閉環方法論。

​

1. 怎麼發現當前微服務架構的問題？
2. Kubernetes Ingress 後面再部署微服務閘道器影響效能嗎？
3. 使用者登入鑑權邏輯能否集中處理/升級？
4. 多個 Kubernetes 叢集是否可以共用一個閘道器？
5. 同時使用 SpringCloud 和 Kubernetes svc 怎麼灰度？

此處只是稍作舉例，實際的痛點大家深有體會，開源產品往往和我們的業務需求不是那麼匹配，接下來看雲原生閘道器是如何解決這些問題的。

雲原生閘道器的優勢

雲原生閘道器=流量閘道器+微服務閘道器+？

雲原生閘道器從開始就一直在強調，將流量閘道器（Kubernetes Ingress、Nginx）和微服務閘道器（Spring Cloud Gateway、Zuul 閘道器等）二合一，降低 50%資源成本，同時縮短了請求時間，降低運維複雜度。

​

1. 開箱即用， 預設支援全域性看板、例項監控、日誌檢索、業務 TOP 榜、日誌投遞、鏈路追蹤及報警管理等體系化可觀測能力，讓你輕鬆瞭解微服務及 API 質量情況。
2. 卓越的效能，詳見下文效能更強勁。
3. 支援 Ingress 標準，Kubernetes 體系首選閘道器產品。
4. 多種服務發現，支援 ACK 容器服務、Nacos 等多種服務發現方式，可以同時接入多個 Kubernetes 叢集。
5. 基於 envoy+istio 實現，完美相容服務網格，技術大勢所趨。

功能更豐富

​

效能更強勁

​

• 雲原生閘道器的 TPS 基本是 SpringCloud Gateway 的 2 倍，是Zuul 1 的 5 倍。
• 雲原生閘道器的 TPS 相比 Nginx Ingress 高出約 90%。

穩定更可靠

​

• 自內部 2020.5 上線，雲原生閘道器已在支付寶、釘釘、淘寶、天貓、優酷、飛豬、口碑等阿里各業務系統中使用，兩年以來可用率 100%，無任何故障。
• 歷經 2020、2021 雙 11 海量請求的考驗，大促日可輕鬆承載每秒承載數 10 萬筆請求，日請求量達到百億級別。

重磅功能層出不窮

​

原文連結

本文為阿里雲原創內容，未經允許不得轉載。

​