從Kong到Envoy，網易嚴選網關架構演進之路

古語有云「一夫當關，萬夫莫開 」,網易嚴選網關除了提供豐富的功能滿足業務多樣性的需求之外，更重要的是保證穩定、可靠和高效，我們的架構演進也是圍繞這一核心目標進行。這兩年隨着嚴選雲原生架構的逐步落地，我們也實踐通過擁抱雲利用雲來更好的保證網關的穩定性。

 

網易嚴選自2016年誕生以來，不論從業務、技術還是體量，每年都在飛速發展。而作爲嚴選對外服務的總入口，網關承接了主要的業務流量，保障着嚴選業務的穩定運行，並幫助業務進行更好的容災和降級。

隨着服務化、容器化的演進，嚴選API網關也轉變角色，作爲嚴選邊緣網關，協助業務進行無感知的流量遷移。最後，嚴選API網關統一到了基於雲原生的網易輕舟Envoy API網關，不斷往更高級的形態演進。

總體演進歷程

嚴選API網關演進圖

 

如上圖所示：

• ServiceMesh1.0：嚴選自研的基於Consul+Nginx的服務網格，解決了內部微服務之間的流量治理問題，統一了嚴選微服務體系。

• API網關1.0：即嚴選Ianus網關，解決了外部對服務訪問的流量治理問題，並經受住了多次大促流量的考驗。

• ServiceMesh2.0：嚴選的服務網格進化爲網易輕舟（下文簡稱輕舟）的基於Istio的服務網格架構，支持更豐富的流量管控能力。

• 邊緣網關：在流量遷移到輕舟過程中，API網關角色就轉變爲邊緣網關，負責跨雲的流量管控，這裏也推進了雲內邊緣網關的建設。

• API網關2.0：即輕舟Envoy網關，此時數據面拋棄了API網關1.0版本，與輕舟一起建設基於Envoy的雲原生API網關。

SeviceMesh的演進之前已經由其它同事分享過，這裏不再詳述，感興趣的童鞋可以移步架構不止-嚴選Service Mesh架構的持續演進查看。

API網關1.0（嚴選Ianus網關）- 體系建設

經過產品調研和技術選型，我們最終基於Kong構建嚴選API網關，命名爲Ianus，開始了嚴選API網關的打怪升級之旅！

部署架構

嚴選Ianus網關模塊架構圖

如上圖所示：

• Yanxuan-Ianus：數據面組件，承接實際的業務流量。

• Yanxuan-Ianus-PGProxy：控制面代理組件，對PostgreSQL寫操作進行收斂，而Yanxuan-Ianus只保留只讀權限，消除安全隱患。

• Yanxuan-Ianus-Admin：控制面組件，提供完整的API配置、插件配置等操作。

嚴選Ianus網關集羣拓撲圖

 

如上圖所示，爲數據面的具體部署拓撲，通過合理的集羣規劃，可以做到：

• 物理上對業務進行隔離，避免相互干擾。

• 集羣根據自身業務流量進行容量配比，有利於資源精細化管理。

• 通過集羣方式進行API的配置管理，理解直觀、配置清晰。

數據面建設

嚴選Ianus網關技術棧

如上圖所示，數據面具體技術棧實現爲：

• Nginx：以Openresty主版本依賴爲準，擴充引入所需的功能模塊，其中consul-module用於集成Consul，統一到嚴選Servicemesh1.0的服務治理體系中；vts-module用於統計監控信息的採集。

• Openresty：直接引入官方的穩定版本，不做額外變更。

• Yanxuan-Kong：引入Kong的主幹版本，並進行額外的功能擴展，包括參數路由、集羣管理、租戶管理、灰度發佈等等。

• Yanxuan-Ianus：所有擴展功能插件均在此管理，適配微服務形態的地址路由等。

控制面建設

Kong原生的配置管理，沒有權限控制，沒有版本記錄，功能缺失較多，無法應用於生產環境。因此，我們對控制面進行了如下增強：

• 版本信息管理

在現有配置基礎之上，包裝了基於MongoDB的配置管理，支持歷史版本的回溯、版本回退、版本比較等功能。有效地避免了配置出錯導致的無法回滾，或回滾不方便等問題。

• 標準化配置流程

接入嚴選工單體系，提供統一的配置申請、審覈、發佈等節點動作，有效地對業務配置需求進行管理，在流程上對配置更新進行管控。

接入嚴選報警體系，在配置變更時，將變更通知到業務負責人、配置人員、網關運維人員，確保實時感知配置變動，預知風險點。

• 灰度發佈功能

將配置下發到指定的網關實例節點，進行灰度驗證，最小化配置出錯的影響範圍。

插件能力建設

Kong在Openresty上做的一項重大改進，就是對插件的規範，支持了熱插拔、配置動態下發等能力。嚴選擴充了頻控插件、路由插件、請求/響應轉換插件等30餘個，同時也爲部分業務定製了功能插件，如AB實驗分流插件、登錄鑑權插件、身份信息提取插件等。

• 容災能力

1. 增加了按百分比進行限流的能力，並支持分地域差別處理。

2. 熔斷降級能力，按需熔斷部分非重點業務接口，保證業務主體功能的穩定。

3. 頻控限流能力，根據服務自身的承載能力，在網關側配置相應閥值，避免業務被突發流量打垮。

• 鏈路跟蹤

基於插件形式擴展，與嚴選APM體系集成，將網關的請求數據採集到全鏈路監控體系中，補齊鏈路節點，消除鏈路追蹤盲點。爲避免引入性能損耗，此處基於日誌進行異步上報，並且採樣率可通過插件配置參數進行調整。

• AB實驗分流支持

AB實驗本身包括了多個方面的實驗，而網關側負責對入口流量的分流實驗進行落地。

AB實驗拓撲圖

如上圖所示：

1. 網關管理平臺對接實驗平臺，業務在實驗平臺配置實驗後，相應配置會下發到網關。

2. 網關對命中的接口，二次訪問實驗平臺的決策接口，獲取具體實驗方案。

3. 支持多種方案類型，根據決策平臺返回的結果執行對應的方案。

收益啓示

經過嚴選Ianus網關的體系建設，我們初步達成了：

1. 統一嚴選的API訪問入口，超過90%流量跑在嚴選Ianus網關之上。

2. 統一流量治理，在控制面上與微服務達成統一。

3. 提供標準的容災能力，如頻控、降級、靜態化等，從而業務可以進行復用。

4. 充分利用LUA的插件能力，滿足業務個性化需求。

期間線上問題進行實時的總結歸檔，比如Nginx的配置使用問題，Kong的版本跟蹤問題，PostgreSQL的優化等等。實際落地過程中，我們沒有侷限於網關，而是着眼於嚴選微服務體系的建設。

API網關1.5時代 - 邊緣網關

隨着ServiceMesh從1.0向2.0演進，過渡期會存在ServiceMesh1.0（嚴選VM）與ServiceMesh2.0(輕舟K8S)兩種類型的ServiceMesh共存的情形，自然面臨兩個ServiceMesh間的流量調撥問題。

爲方便介紹，如下描述中「雲外」代表ServiceMesh1.0，「雲內」代表ServiceMesh2.0。

跨ServiceMesh訪問

在各個ServiceMesh之上，部署自建的邊緣網關（Edge Gateway），與數據中心的基礎設施集成。雲內即推動輕舟將原有Istio服務網格中的Ingress/Egress進行替換，統一到輕舟Envoy網關（即下文的API網關2.0）。

雲內雲外互訪流程圖

如上圖所示，雲外採用嚴選Ianus網關進行部署，雲內採用輕舟Envoy進行部署。以雲外訪問雲內爲例：

1. 流量首先由ServiceMesh1.0進行管控，並路由/分流到邊緣網關（Ianus OUT）。

2. 邊緣網關（Ianus OUT）進行出口流量的權限認證以及路由。

3. 邊緣網關（Envoy IN），對流量在SericeMesh2.0中進行正常的路由/分流。

跨環境訪問

已有跨環境訪問，需要SA打通兩兩IP之間的防火牆。一方面，每次需要對應用服務器IPtable做專門的配置；另一方面，所有互訪配置離散到各個應用服務器，無法做集中管控。

這裏將跨數據中心的訪問流量，統一走到邊緣網關，在網關上進行相應的認證鑑權（基於插件實現）。

跨環境網關拓撲圖

如上圖所示，跨ServiceMesh可以認爲是東西向流量，而跨環境可以認爲是南北向流量。最終支持了各大環境互訪，統一業務訪問方式，消除環境差異，並對流量進行集中式管控，方便統一運維！

收益啓示

通過上述工作，我們完成了：

1. 承接了100%的跨ServiceMesh流量。

2. 無縫融合ServiceMesh1.0以及ServiceMesh2.0的流量調配機制，業務不感知流量跨ServiceMesh。

3. 統一了跨環境的認證鑑權，方便集中管控。

4. 通過流量兜底等能力，實現雙ServiceMesh熱備，支持業務的高可用。

這裏跨環境的支持，是雲內雲外互訪落地過程中，根據業務的需求反饋進行整理抽象得到的，進一步擴展了網關的部署架構，豐富了網關體系。

API網關2.0（輕舟Envoy網關）- 雲原生

網關選型

上雲之初，嚴選API網關團隊也調研對比了Kong、Traefik、Ambassador、Gloo、Istio Gateway等的特性，目標是構建一個雲原生的API網關。

雲原生API網關選型對比

產品	Kong	Traefik	Ambassador	Gloo	Istio Gateway
語言	Lua	Golang	Python	Golang	Golang
部署複雜度	中等	簡單	簡單	簡單	簡單
依賴	Cassandra或Postgres，可DBless	V2版本K8S	K8S	K8S	K8S
開源	Apache2.0開源	MIT協議開源	Apache2.0開源	Apache2.0開源	Apache2.0開源
核心技術	Nginx/Lua	Golang	Envoy	Envoy	Envoy
社區情況	大	大	中	中	大
API認證授權	支持	支持	支持	支持	支持
流控	支持	支持	支持	商業版支持	基於Envoy全侷限流
數據轉換	基於HTTP	不支持	基於HTTP	基於HTTP	不支持
路由策略	host, path, method	Host,path	host, head, path	header, queryparam, method, path,function	Host, head, path
容器集成	自帶數據面、控制面	僅作爲網關	作爲控制面適配Envoy	作爲控制面適配Envoy	作爲控制面適配Envoy

隨着上雲的深入，綜合考慮後，決定將雲內網關建設的任務交給輕舟網關團隊負責，嚴選則從API網關的需求以及當前的工程建設規劃出發，給出設計和建議。數據面部分，考慮了現有輕舟微服務體系的無縫融合以及主流的產品實現，選型採用了Envoy進行數據面的建設；控制面部分，考慮到嚴選需要複用現有管理平臺的功能，則基於現有的Istio體系進行共建。

部署架構

輕舟Envoy網關模塊架構圖

如上圖所示，整體分爲控制面和數據面兩部分。數據面由雙方共建設計方案，落地交由輕舟負責；控制面嚴選跟輕舟共建，統一到已有嚴選API網關管理平臺。而具體數據面集羣的規劃，沿用了嚴選Ianus網關的部署方式，在此不再贅述。

數據面建設

基於輕舟的微服務架構

如上圖所示，數據面在選型時，對流量是否要經過網關和Sidecar兩層進行了權衡，從簡化調用鏈路，網關與Sidecar角色差異考慮，採用了繞過Sidecar的模式。此時網關部分功能與Sidecar功能雖有重合，但與ServiceMesh保持了獨立，可各自演進。當前支持的基礎功能包括：默認路由能力、版本分流能力、兜底路由能力等。特別地，對請求流量治理時，需要同時考慮ServiceMesh跟API網關的控制指令下發。

控制面建設

網關管理平臺配置架構

如上圖所示，爲了保持嚴選API網關產品的一致性，輕舟的控制面最終需要跟當前嚴選API網關的管理平臺功能對齊，複用嚴選Ianus網關管理平臺的能力，包括配置管理、API發佈管控等等，確保用戶體驗的一致性！

輕舟Envoy網關配置下發鏈路

如上圖所示，爲整個控制面的下發鏈路，主要組件包括：

• API Gateway Admin

嚴選網關管理平臺，集成到現有的網關管理平臺中，通過數據中心（嚴選|輕舟）的切換，實現兩邊配置的管理，對外展示表現完全一致。

• API Plane

輕舟Envoy網關控制面配置適配層，負責接收配置數據（嚴選API配置模型），轉化格式（對應到Istio模型），並存儲到K8S Config Store。嚴選負責嚴選適配組件的擴展開發，輕舟負責基礎功能的實現。主要功能包括，網關集羣獲取、後端服務列表獲取、插件列表/詳情獲取、API創建/刪除等。最終發佈時，將輕舟側代碼反向同步到嚴選側的GIT上，統一到嚴選的發佈體系中。

• Istio Pilot

Pilot作爲Istio ServiceMesh方案控制面組件，主要負責以下功能：

1. 從註冊中心獲取服務註冊信息，並轉換爲CDS，EDS下發。

2. 從配置中心獲取服務配置信息，並轉換爲LDS，RDS，CDS下發。

3. Envoy靜態配置的生成以及生命週期的管理。

嚴選ServiceMesh2.0解決方案中，Pilot分飾兩角，一個作爲網格內服務控制面，另一個作爲網關服務控制面。

插件能力建設

爲支持嚴選Ianus網關長期的演進遷移到輕舟Envoy網關，同時參考了Kong和Envoy已有的插件能力進行落地。

Envoy原生插件

原生Envoy單個功能插件的開發，涉及到整個配置鏈路多模塊變更，喪失了插件可擴展性的優勢。

落地時，對插件配置的轉換進行了規範，歸一到Schema上來，後端根據該Schema進行統一的Istio資源轉換，前端管理平臺根據Schema進行統一的配置頁面渲染。開發成本縮減到一個模塊，擴展優勢得到體現。

LUA擴展插件

嚴選Ianus網關下，基於Kong的LUA插件擴展能力，已經實現了較豐富的功能插件，如果直接切換到輕舟Envoy網關，則原有的插件都需要按照新的規範重新開發。

在Envoy現有插件的基礎上，擴充LUA插件開發的能力。嚴選側總結分享Kong現有的插件開發實踐，爲Envoy下LUA插件的規範提供參考，最終保證兩者上手的差異最小化。落地遷移時，基本複用了嚴選Ianus網關的插件代碼，插件遷移代價（不論是開發還是測試）非常低，提高了輕舟Envoy網關的插件建設效率。

收益啓示

通過上述工作，我們實現了：

1. 網關管理平臺複用，保證用戶習慣一致性。

2. LUA插件複用，方便擴展功能的無縫遷移。

3. 函數級別路由能力的支持，爲後續FaaS的引流鋪平了道路。

整個控制面共建過程，Kong與Envoy兩個技術棧取長補短，共同打造了基於雲原生的輕舟Envoy網關體系，這也是我們未來的發展方向。

總結

API網關1.0（嚴選Ianus網關）在過去兩年的時間中發揮的作用是舉足輕重的，並且在整個嚴選業務遷移上雲的過程中也承載着核心流量調度管控。同時在API網關2.0（輕舟Envoy網關）崛起的過程中，Ianus網關也給出了有價值的參考，如插件體系的建設等。在接下來的道路中，API網關2.0將持續跟進雲原生、Serverless等的步伐，並不斷輸出反哺業界和社區，最終成爲網關的引領者！

 

作者簡介

楊文超，2012年加入網易，資深JAVA開發，致力於服務端的技術研發及方案設計工作，目前在數據平臺及風控部，負責嚴選FaaS平臺的建設。主導了網易嚴選風控系統、網關係統建設。

 

本文由嚴選技術團隊授權發佈