解讀開源Hango網關的雲原生設計與實踐，本文先從雲原生溯源，解讀雲原生API網關選型特點；再進一步解讀網易數帆開源Hango雲原生API網關設計及大規模落地實踐。
雲原生溯源什麼是雲原生
CNCF（雲原生計算基金會）對雲原生的定義是：雲原生是一種架構模式，有利於各組織在公有雲、私有雲和混合雲等動態環境中，構建和運行可彈性擴展的應用。代表技術包括，容器、微服務、不可變基礎設施和聲明式API。
從雲原生的定義可以看出，雲原生具備快速集成，擁有良好的擴展性及高可用性。得益於Kubernetes的發展，雲原生技術蓬勃發展，已然邁入新時代。
API網關的意義
隨着容器技術以及微服務理念的發展，更多的產品組織着重於暴露開放API，用於客戶端進行交互。API網關充當API代理的功能，網關接收請求，將請求進行統一路由轉發至後端服務。網關作為抽象層，為整個微服務系統或集群提供統一接入層。
除了代理功能外，API網關為微服務集群提供統一的安全、響應轉換、熔斷、降級和監控等多維度功能，確保流量安全可靠。
隨着雲原生理念引領微服務進行演進，應用迭代頻率以及交付速度會加快，API網關的出現可以使得業務開發更加專注於自身業務邏輯的設計，提升研發敏捷性。在雲原生的架構下，API網關也在向雲原生演進，Hango網關便是雲原生設計下催生的優秀網關產品。
雲原生API網關特點
進入雲原生時代，行業用戶除了關注傳統API網關提供的請求代理，流量治理等常規功能外，更多的開始關注云原生兼容性，支撐場景的多樣以及更優異的性能。
相較於傳統API網關，在雲原生模式下筆者認為API網關應該具備的一些思考：
服務發現方式：與傳統網關服務發現需要手動指定upstream，雲原生網關在服務發現上需要動態感知業務變化。
更高的性能追求：隨着Kubernetes以及容器將雲原生帶入新時代以及微服務理念的發展，API網關的卓越性能可以減少整個鏈路的RT。
雲原生架構兼容/整合：網關的部署架構是否能夠和雲原生架構進行兼容，能否和容器以及服務網格進行無縫對接。
動態配置能力：傳統的反向代理無法實現動態配置加載能力，雲原生模式下的代理配置更新變化較頻繁，動態配置下發能力顯得尤為關鍵。
部署形態及架構：網關部署架構能否滿足彈性擴展，是否支持從業務混部到獨立部署的平滑遷移。
監控/鏈路追蹤：雲原生架構中，良好的監控和鏈路追蹤能力可以便於運維人員進行服務觀測以及問題定位。
Hango API 網關設計
隨着集團內業務大規模進行容器化改造，業務對網關的訴求也愈發強烈。我們團隊着手於建設新一代高性能API網關Hango（項目地址：https://github.com/hango-io/hango-gateway），目的是替換集團內部較多的採用Java的異步網關、Zull，同時滿足業務逐漸上雲的南北向流量治理需求。
在選型方面，我們選擇Envoy作為雲原生網關實踐的關鍵基礎組件，具備豐富的特性，包括：
原生功能豐富：相較於Nginx，HAProxy等流量代理所需的基本功能，Envoy本身基於C++實現了相當多的高級治理功能，包括負載均衡、熔斷、限流、故障注入等。更為豐富的功能使得Envoy 天生具備多場景。
豐富的可觀察性：Envoy具備靈活的日誌配置、豐富的指標數據以及開箱即用的多種Tracing能力。
靈活的擴展性：Envoy提供了L4/L7 Filter機制，可以讓開發者在不侵入Envoy主幹的前提下對Envoy進行擴展與增強。同時，xDS協議的提出，使得Envoy幾乎所有的配置都可以動態下發、加載、生效，而無需重新加載進程。
同時，Envoy在行業內的發展趨勢也非常迅猛，2020年雲原生報告顯示，Envoy 在行業內使用量上升明顯，去年排名第四的Envoy，超過F5和HAProxy 從15%的份額增長到29%。
架構設計
基於以上典型特性，秉承雲原生的理念，通過大量內部積累實踐經驗，我們開源了Hango API 網關。Hango 中文名「函谷」，是一個高性能，可擴展，功能豐富的雲原生API網關。
Hango網關基於Envoy及Istio構建。數據面基於Envoy擴展，增強插件鏈；控制面基於Istio進行擴展。具體架構如下：
控制面組件包括Hango Portal, Hango API Plane, Slime以及Istiod。Hango API Plane生成Gateway、DestinationRule、VirtualService等CRD以及EnvoyPlugin等Slime CRD；通過Slime進行擴展，將Slime CRD動態轉化為EnvoyFilter，對數據面envoy進行擴展。
下圖展示Hango網關插件鏈的數據流，通過創建EnvoyPlugin CR，Slime動態監聽聚合生成對應的EnvoyFilter，完成對Envoy filter chain的動態擴展。
高性能
和傳統API網關相比，在雲原生模式下，業務開發更加敏捷，業務拆分更加細緻。這樣會使得業務每一跳之間的時延更加敏感。網關承接整個微服務集群的流量代理，良好的性能是業務是否選擇網關的必備條件。
Hango API網關採用Envoy作為核心數據面，眾多核心功能通過原生C++實現，相較於Nginx、HAProxy等通過擴展腳本實現主要功能的方式，性能優勢更為明顯。
同時，在實際落地過程，我們也對網關做了一定的性能優化，包括：
配置過濾：通過對集群svc以及DestinationRule 資源的配置過濾，減少envoy cluster 數量。
插件配置：提供全局插件開關以及路由維度的插件開關，減少非必要插件邏輯對性能的開銷。
通過優化，基於20個cluster，500條route配置規模，我們對Hango進行了梯度測試，在容器網絡下，500條route配置規模，Hango RPS可以達到9.5w。
多場景
Hano API網關具備支撐微服務網關、七層負載均衡、Kubernetes Ingress等多場景能力。作為業務上雲的南北流量入口，Hango網關具備以下特性：
靈活路由配置：支持不限於請求Path，Header、Method、Query等進行靈活路由配置。
多註冊方式：支持Kubernetes註冊中心動態感知業務集群變化，滿足業務平滑擴縮容場景；支持傳統邏輯部署，使得業務可以平滑遷移。
多場景治理：支持多維度限流、熔斷、降級、重試等多場景流量治理。
多協議支持：支持HTTP、gRPC、Websocket等多協議接入。
多維度安全：支持多維度黑白名單、外部認證等多種認證方式。
同時，作為通用網關，Hango同樣可以被用於L7 負載均衡器，Kubernetes 邊緣網關等通用場景。
可擴展功能擴展
Hango網關開源Rider模塊，用於功能擴展。用戶可以通過簡單的教程進行可插拔插件的形式的動態擴展網關功能。
Rider作為Hango API網關開源的module，提供插件開發的SDK，使得用戶可以通過Lua擴展的方式編寫自定義插件，通過簡單的配置即可以動態擴展envoy L7 filters，使得Lua 插件可以像其他Native Http filter一樣在運行時進行配置。
可以參考Hango Github 網頁Rider自定義插件教程，這裡提供一個簡單的開箱即用的UA黑白名單插件，讀者可以進行自定義插件學習。
彈性伸縮
Hango網關支持容器化部署，提供基於Kubernetes的部署架構。建立在數據面和控制面隔離的基礎上，數據面節點基於無狀態的envoy進行部署。基於xDS協議的動態下發設計，數據面可以進行動態橫向擴展，在業務大促或流量增長時進行平滑伸縮。
容錯性
Hango網關可以實現業務配置隔離，增加業務容錯性，對於重點業務可以單獨區分網關集群進行部署，提升整個網關產品可用性。
Hango網關設計之初便可以完成對業務配置的隔離，基於Istio的模型，在Hango網關最初在規模實踐就考慮到了增強Istio的能力，通過對DestinationRule 相關CR增加對應的Gateway label。通過label匹配的方式控制cluster資源的下發，起到配置隔離作用。
Istio社區也在版本演進過程中（>Istio1.7），提出了一種解決思路，cluster的獲取可以依賴VirtualService（VS）中的host配置，通過VS資源route host與DestinationRule資源進行映射 ，生成對應的cluster, 下發至指定的Proxy。這樣可以確保不同網關之間的cluster配置隔離，減少不同配置相互影響，提升服務穩定性；同時，大大減少線上cluster的數量，進一步提升proxy性能。
如下所示，通過配置隔離，a-hango 網關集群僅能收到app1的cluster。通過此可以實現線上配置隔離，提升產品穩定性，同時進一步提升網關性能。
易操作
Hango網關提供從控制界面以及API的方式提升用戶操作體驗。
控制平面
提供簡單的控制面，用戶可以通過可視化操作進行服務和路由的生命周期管理。具體可以參考：Hango網關控制面操作流程
OpenAPI
為了便於企業用戶接口Hango, Hango提供了標準的Restful API，便於企業用戶完成對已有網關產品向Hango的平滑遷移。
Hango API 網關規模落地
在網易集團內部，基於Hango網關構建的輕舟網關已經大規模落地實踐，承擔網易集團每日百億級流量。本文主要從平滑納管、灰度發布以及可觀測實踐三個角度介紹Hango網關在網易集團內部的落地實踐。
平滑納管
基於Hango網關規模落地中，我們對容器服務，裸金屬服務等實現了平滑納管以及平滑遷移，為業務上雲提供了便利接入，打消了業務上雲無法平滑的顧慮。
在網易集團內部，針對不同的業務劃分不同的網關集群，從業務上進行配置隔離，提升網關可靠性。
灰度發布
在實踐過程中，灰度主要涉及兩方面，一方面是業務容器化改造過程中的灰度遷移，另一方面便是網關產品自身的灰度策略。
業務容器灰度
業務在容器化改造過程中，存在多版本上線場景，需要根據不同版本進行灰度發布。Hango網關提供根據業務不同版本進行灰度的過程，通過對服務打label的形式，在路由的過程中，選擇不同的label進行灰度權重配置。
網關灰度
作為微服務集群的入口，網關的穩定運行關係着整個集群流量的穩定及可靠。在實地落地過程中，建立一整套網關自身灰度體系非常有必要，Hango網關在網易集團內部落地過程採用四層LB進行灰度體系構建，通過對Hango數據面打label的形式，控制網關自身灰度。
可觀測
基於Envoy良好的觀測性，Hango網關在網易集團內部進行規模落地過程中，結合服務網格場景，提供豐富的觀測能力，整體架構如下：
日誌
Envoy中事件的詳細記錄，Hango網關基於Envoy進行數據面擴展，提供了靈活易配置的AccessLog，支持自定義格式，自定義過濾規則以及輸出。
基於filebeat以及elastic的能力，構建一體化日誌審計平台。
監控
基於Envoy cluster mertic等信息，利用Promethues構建網關/服務等多維度指標體系。同時，針對網關容器化部署模式，基於Kubernetes 容器對應的 metrics構建容器維度的指標監控，涵蓋CPU/內存/帶寬等多維度監控。
鏈路追蹤
基於Envoy開箱即用的多種tracing接入，拓展力強，目前已完成線上SkyWalking等tracing的接入。
寫在最後
Hango作為一名開源領域的新生兒，我們會秉承擁抱雲原生的理念，繼續跟進Istio/Envoy的演進，發揮更大的領域價值。下一階段，我們會在多語言擴展，LB融合等多場景進行發力，也期待更多關注云原生、API網關的同學能夠加入Hango開源社區建設。
誠摯的歡迎大家關注Hango Gateway：
https://github.com/hango-io/hango-gateway
參考文檔
雲原生（Cloud Native）的定義
https://jimmysong.io/kubernetes-handbook/cloud-native/cloud-native-definition.html
雲原生關乎文化，而不是容器
https://cloudnative.to/blog/cloud-native-culture-not-container/
Hango 開源解讀：雲原生網關實踐，為何要選擇 Envoy ？
https://mp.weixin.qq.com/s/J8ROB79yi4xlmTpQOR2sOA
作者簡介
韓佳浩，開源項目 Hango 核心開發者，網易數帆資深研發工程師，主導 Hango 網關開源研發及設計，負責網易數帆輕舟 API 網關在網易內部大規模落地及產品化建設。具有三年網關相關研發及大規模實踐經驗。
分享預告
9月9日20:00，Hango 項目核心開發者，網易數帆技術專家王佰平將在 InfoQ 公開課分享《如何基於開源Envoy，構建高性能雲原生微服務網關》，從網易數帆開源 API 網關項目 Hango 實踐出發，介紹如何基於開源 Envoy 構建高性能、易擴展、可觀察的雲原生微服務網關。敬請點擊「閱讀原文」報名預約觀看！
留言列表