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

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

總體演進歷程

嚴選 API 網關演進圖

如上圖所示：

• Service Mesh1.0：嚴選自研的基于 Consul+Nginx 的服務網格，解決了內部微服務之間的流量治理問題，統一了嚴選微服務體系。
  API 網關 1.0：即嚴選 Ianus 網關，解決了外部對服務訪問的流量治理問題，并經受住了多次大促流量的考驗。
• Service Mesh2.0：嚴選的服務網格進化為網易輕舟（下文簡稱輕舟）的基于 Istio 的服務網格架構，支持更豐富的流量管控能力。
  邊緣網關：在流量遷移到輕舟過程中，API 網關角色就轉變為邊緣網關，負責跨云的流量管控，這里也推進了云內邊緣網關的建設。
• API 網關 2.0：即輕舟 Envoy 網關，此時數據面拋棄了 API 網關 1.0 版本，與輕舟一起建設基于 Envoy 的云原生 API 網關。

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 網關選型對比

隨著上云的深入，綜合考慮后，決定將云內網關建設的任務交給輕舟網關團隊負責，嚴選則從 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 平臺的建設。主導了網易嚴選風控系統、網關系統建設。