嚴(yán)選自 2016 年誕生以來，不論從業(yè)務(wù)、技術(shù)還是體量，每年都在飛速發(fā)展。而作為嚴(yán)選對外服務(wù)的總?cè)肟冢W(wǎng)關(guān)承接了主要的業(yè)務(wù)流量，保障著嚴(yán)選業(yè)務(wù)的穩(wěn)定運(yùn)行，并幫助業(yè)務(wù)進(jìn)行更好的容災(zāi)和降級。

隨著服務(wù)化、容器化的演進(jìn)，嚴(yán)選 API 網(wǎng)關(guān)也轉(zhuǎn)變角色，作為嚴(yán)選邊緣網(wǎng)關(guān)，協(xié)助業(yè)務(wù)進(jìn)行無感知的流量遷移。最后，嚴(yán)選 API 網(wǎng)關(guān)統(tǒng)一到了基于云原生的輕舟 Envoy API 網(wǎng)關(guān)，不斷往更高級的形態(tài)演進(jìn)。

總體演進(jìn)歷程

網(wǎng)易嚴(yán)選的網(wǎng)關(guān)架構(gòu)演進(jìn)之路

嚴(yán)選 API 網(wǎng)關(guān)演進(jìn)圖

如上圖所示：

Service Mesh1.0：嚴(yán)選自研的基于 Consul+Nginx 的服務(wù)網(wǎng)格，解決了內(nèi)部微服務(wù)之間的流量治理問題，統(tǒng)一了嚴(yán)選微服務(wù)體系。
API 網(wǎng)關(guān) 1.0：即嚴(yán)選 Ianus 網(wǎng)關(guān)，解決了外部對服務(wù)訪問的流量治理問題，并經(jīng)受住了多次大促流量的考驗(yàn)。
Service Mesh2.0：嚴(yán)選的服務(wù)網(wǎng)格進(jìn)化為網(wǎng)易輕舟（下文簡稱輕舟）的基于 Istio 的服務(wù)網(wǎng)格架構(gòu)，支持更豐富的流量管控能力。
邊緣網(wǎng)關(guān)：在流量遷移到輕舟過程中，API 網(wǎng)關(guān)角色就轉(zhuǎn)變?yōu)檫吘壘W(wǎng)關(guān)，負(fù)責(zé)跨云的流量管控，這里也推進(jìn)了云內(nèi)邊緣網(wǎng)關(guān)的建設(shè)。
API 網(wǎng)關(guān) 2.0：即輕舟 Envoy 網(wǎng)關(guān)，此時(shí)數(shù)據(jù)面拋棄了 API 網(wǎng)關(guān) 1.0 版本，與輕舟一起建設(shè)基于 Envoy 的云原生 API 網(wǎng)關(guān)。

API 網(wǎng)關(guān) 1.0（嚴(yán)選 Ianus 網(wǎng)關(guān)）——體系建設(shè)

經(jīng)過產(chǎn)品調(diào)研和技術(shù)選型，我們最終基于 Kong 構(gòu)建嚴(yán)選 API 網(wǎng)關(guān)，命名為 Ianus，開始了嚴(yán)選 API 網(wǎng)關(guān)的打怪升級之旅！

部署架構(gòu)

嚴(yán)選 Ianus 網(wǎng)關(guān)模塊架構(gòu)圖

如上圖所示：

Yanxuan-Ianus：數(shù)據(jù)面組件，承接實(shí)際的業(yè)務(wù)流量。
Yanxuan-Ianus-PGProxy：控制面代理組件，對 PostgreSQL 寫操作進(jìn)行收斂，而 Yanxuan-Ianus 只保留只讀權(quán)限，消除安全隱患。
Yanxuan-Ianus-Admin：控制面組件，提供完整的 API 配置、插件配置等操作。

嚴(yán)選 Ianus 網(wǎng)關(guān)集群拓?fù)鋱D

如上圖所示，為數(shù)據(jù)面的具體部署拓?fù)洌ㄟ^合理的集群規(guī)劃，可以做到：

物理上對業(yè)務(wù)進(jìn)行隔離，避免相互干擾。
集群根據(jù)自身業(yè)務(wù)流量進(jìn)行容量配比，有利于資源精細(xì)化管理。
通過集群方式進(jìn)行 API 的配置管理，理解直觀、配置清晰。

數(shù)據(jù)面建設(shè)

嚴(yán)選 Ianus 網(wǎng)關(guān)技術(shù)棧

如上圖所示，數(shù)據(jù)面具體技術(shù)棧實(shí)現(xiàn)為：

Nginx：以 Openresty 主版本依賴為準(zhǔn)，擴(kuò)充引入所需的功能模塊，其中 consul-module 用于集成 Consul，統(tǒng)一到嚴(yán)選 Servicemesh1.0 的服務(wù)治理體系中；vts-module 用于統(tǒng)計(jì)監(jiān)控信息的采集。
Openresty：直接引入官方的穩(wěn)定版本，不做額外變更。
Yanxuan-Kong：引入 Kong 的主干版本，并進(jìn)行額外的功能擴(kuò)展，包括參數(shù)路由、集群管理、租戶管理、灰度發(fā)布等等。
Yanxuan-Ianus：所有擴(kuò)展功能插件均在此管理，適配微服務(wù)形態(tài)的地址路由等。

控制面建設(shè)

Kong 原生的配置管理，沒有權(quán)限控制，沒有版本記錄，功能缺失較多，無法應(yīng)用于生產(chǎn)環(huán)境。因此，我們對控制面進(jìn)行了如下增強(qiáng)：

版本信息管理

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

標(biāo)準(zhǔn)化配置流程

接入嚴(yán)選工單體系，提供統(tǒng)一的配置申請、審核、發(fā)布等節(jié)點(diǎn)動作，有效地對業(yè)務(wù)配置需求進(jìn)行管理，在流程上對配置更新進(jìn)行管控。

接入嚴(yán)選報(bào)警體系，在配置變更時(shí)，將變更通知到業(yè)務(wù)負(fù)責(zé)人、配置人員、網(wǎng)關(guān)運(yùn)維人員，確保實(shí)時(shí)感知配置變動，預(yù)知風(fēng)險(xiǎn)點(diǎn)。

灰度發(fā)布功能

將配置下發(fā)到指定的網(wǎng)關(guān)實(shí)例節(jié)點(diǎn)，進(jìn)行灰度驗(yàn)證，最小化配置出錯的影響范圍。

插件能力建設(shè)

Kong 在 Openresty 上做的一項(xiàng)重大改進(jìn)，就是對插件的規(guī)范，支持了熱插拔、配置動態(tài)下發(fā)等能力。嚴(yán)選擴(kuò)充了頻控插件、路由插件、請求 / 響應(yīng)轉(zhuǎn)換插件等 30 余個，同時(shí)也為部分業(yè)務(wù)定制了功能插件，如 AB 實(shí)驗(yàn)分流插件、登錄鑒權(quán)插件、身份信息提取插件等。

容災(zāi)能力

增加了按百分比進(jìn)行限流的能力，并支持分地域差別處理。
熔斷降級能力，按需熔斷部分非重點(diǎn)業(yè)務(wù)接口，保證業(yè)務(wù)主體功能的穩(wěn)定。
頻控限流能力，根據(jù)服務(wù)自身的承載能力，在網(wǎng)關(guān)側(cè)配置相應(yīng)閥值，避免業(yè)務(wù)被突發(fā)流量打垮。

鏈路跟蹤
基于插件形式擴(kuò)展，與嚴(yán)選 APM 體系集成，將網(wǎng)關(guān)的請求數(shù)據(jù)采集到全鏈路監(jiān)控體系中，補(bǔ)齊鏈路節(jié)點(diǎn)，消除鏈路追蹤盲點(diǎn)。為避免引入性能損耗，此處基于日志進(jìn)行異步上報(bào)，并且采樣率可通過插件配置參數(shù)進(jìn)行調(diào)整。
AB 實(shí)驗(yàn)分流支持

AB 實(shí)驗(yàn)本身包括了多個方面的實(shí)驗(yàn)，而網(wǎng)關(guān)側(cè)負(fù)責(zé)對入口流量的分流實(shí)驗(yàn)進(jìn)行落地。

AB 實(shí)驗(yàn)拓?fù)鋱D

如上圖所示：

1、網(wǎng)關(guān)管理平臺對接實(shí)驗(yàn)平臺，業(yè)務(wù)在實(shí)驗(yàn)平臺配置實(shí)驗(yàn)后，相應(yīng)配置會下發(fā)到網(wǎng)關(guān)。

2、網(wǎng)關(guān)對命中的接口，二次訪問實(shí)驗(yàn)平臺的決策接口，獲取具體實(shí)驗(yàn)方案。

3、支持多種方案類型，根據(jù)決策平臺返回的結(jié)果執(zhí)行對應(yīng)的方案。

收益啟示

經(jīng)過嚴(yán)選 Ianus 網(wǎng)關(guān)的體系建設(shè)，我們初步達(dá)成了：

1、統(tǒng)一嚴(yán)選的 API 訪問入口，超過 90% 流量跑在嚴(yán)選 Ianus 網(wǎng)關(guān)之上。

2、統(tǒng)一流量治理，在控制面上與微服務(wù)達(dá)成統(tǒng)一。

3、提供標(biāo)準(zhǔn)的容災(zāi)能力，如頻控、降級、靜態(tài)化等，從而業(yè)務(wù)可以進(jìn)行復(fù)用。

4、充分利用 LUA 的插件能力，滿足業(yè)務(wù)個性化需求。

期間線上問題進(jìn)行實(shí)時(shí)的總結(jié)歸檔，比如 Nginx 的配置使用問題，Kong 的版本跟蹤問題，PostgreSQL 的優(yōu)化等等。實(shí)際落地過程中，我們沒有局限于網(wǎng)關(guān)，而是著眼于嚴(yán)選微服務(wù)體系的建設(shè)。

API 網(wǎng)關(guān) 1.5 時(shí)代——邊緣網(wǎng)關(guān)

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

為方便介紹，如下描述中“云外”代表 ServiceMesh1.0，“云內(nèi)”代表 ServiceMesh2.0。

跨 ServiceMesh 訪問

在各個 ServiceMesh 之上，部署自建的邊緣網(wǎng)關(guān)（Edge Gateway），與數(shù)據(jù)中心的基礎(chǔ)設(shè)施集成。云內(nèi)即推動輕舟將原有 Istio 服務(wù)網(wǎng)格中的 Ingress/Egress 進(jìn)行替換，統(tǒng)一到輕舟 Envoy 網(wǎng)關(guān)（即下文的 API 網(wǎng)關(guān) 2.0）。

云內(nèi)云外互訪流程圖

如上圖所示，云外采用嚴(yán)選 Ianus 網(wǎng)關(guān)進(jìn)行部署，云內(nèi)采用輕舟 Envoy 進(jìn)行部署。以云外訪問云內(nèi)為例：

1、流量首先由 ServiceMesh1.0 進(jìn)行管控，并路由 / 分流到邊緣網(wǎng)關(guān)（Ianus OUT）。

2、邊緣網(wǎng)關(guān)（Ianus OUT）進(jìn)行出口流量的權(quán)限認(rèn)證以及路由。

3、邊緣網(wǎng)關(guān)（Envoy IN），對流量在 SericeMesh2.0 中進(jìn)行正常的路由 / 分流。

跨環(huán)境訪問

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

這里將跨數(shù)據(jù)中心的訪問流量，統(tǒng)一走到邊緣網(wǎng)關(guān)，在網(wǎng)關(guān)上進(jìn)行相應(yīng)的認(rèn)證鑒權(quán)（基于插件實(shí)現(xiàn)）。

跨環(huán)境網(wǎng)關(guān)拓?fù)鋱D

如上圖所示，跨 ServiceMesh 可以認(rèn)為是東西向流量，而跨環(huán)境可以認(rèn)為是南北向流量。最終支持了各大環(huán)境互訪，統(tǒng)一業(yè)務(wù)訪問方式，消除環(huán)境差異，并對流量進(jìn)行集中式管控，方便統(tǒng)一運(yùn)維！

收益啟示

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

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

2、無縫融合 ServiceMesh1.0 以及 ServiceMesh2.0 的流量調(diào)配機(jī)制，業(yè)務(wù)不感知流量跨 ServiceMesh。

3、統(tǒng)一了跨環(huán)境的認(rèn)證鑒權(quán)，方便集中管控。

4、通過流量兜底等能力，實(shí)現(xiàn)雙 ServiceMesh 熱備，支持業(yè)務(wù)的高可用。

這里跨環(huán)境的支持，是云內(nèi)云外互訪落地過程中，根據(jù)業(yè)務(wù)的需求反饋進(jìn)行整理抽象得到的，進(jìn)一步擴(kuò)展了網(wǎng)關(guān)的部署架構(gòu)，豐富了網(wǎng)關(guān)體系。

API 網(wǎng)關(guān) 2.0（輕舟 Envoy 網(wǎng)關(guān)）——云原生

網(wǎng)關(guān)選型

上云之初，嚴(yán)選 API 網(wǎng)關(guān)團(tuán)隊(duì)也調(diào)研對比了 Kong、Traefik、Ambassador、Gloo、Istio Gateway 等的特性，目標(biāo)是構(gòu)建一個云原生的 API 網(wǎng)關(guān)。

云原生 API 網(wǎng)關(guān)選型對比

隨著上云的深入，綜合考慮后，決定將云內(nèi)網(wǎng)關(guān)建設(shè)的任務(wù)交給輕舟網(wǎng)關(guān)團(tuán)隊(duì)負(fù)責(zé)，嚴(yán)選則從 API 網(wǎng)關(guān)的需求以及當(dāng)前的工程建設(shè)規(guī)劃出發(fā)，給出設(shè)計(jì)和建議。數(shù)據(jù)面部分，考慮了現(xiàn)有輕舟微服務(wù)體系的無縫融合以及主流的產(chǎn)品實(shí)現(xiàn)，選型采用了 Envoy 進(jìn)行數(shù)據(jù)面的建設(shè)；控制面部分，考慮到嚴(yán)選需要復(fù)用現(xiàn)有管理平臺的功能，則基于現(xiàn)有的 Istio 體系進(jìn)行共建。

部署架構(gòu)

輕舟 Envoy 網(wǎng)關(guān)模塊架構(gòu)圖

如上圖所示，整體分為控制面和數(shù)據(jù)面兩部分。數(shù)據(jù)面由雙方共建設(shè)計(jì)方案，落地交由輕舟負(fù)責(zé)；控制面嚴(yán)選跟輕舟共建，統(tǒng)一到已有嚴(yán)選 API 網(wǎng)關(guān)管理平臺。而具體數(shù)據(jù)面集群的規(guī)劃，沿用了嚴(yán)選 Ianus 網(wǎng)關(guān)的部署方式，在此不再贅述。

數(shù)據(jù)面建設(shè)

基于輕舟的微服務(wù)架構(gòu)

如上圖所示，數(shù)據(jù)面在選型時(shí)，對流量是否要經(jīng)過網(wǎng)關(guān)和 Sidecar 兩層進(jìn)行了權(quán)衡，從簡化調(diào)用鏈路，網(wǎng)關(guān)與 Sidecar 角色差異考慮，采用了繞過 Sidecar 的模式。此時(shí)網(wǎng)關(guān)部分功能與 Sidecar 功能雖有重合，但與 ServiceMesh 保持了獨(dú)立，可各自演進(jìn)。當(dāng)前支持的基礎(chǔ)功能包括：默認(rèn)路由能力、版本分流能力、兜底路由能力等。特別地，對請求流量治理時(shí)，需要同時(shí)考慮 ServiceMesh 跟 API 網(wǎng)關(guān)的控制指令下發(fā)。

控制面建設(shè)

網(wǎng)關(guān)管理平臺配置架構(gòu)

如上圖所示，為了保持嚴(yán)選 API 網(wǎng)關(guān)產(chǎn)品的一致性，輕舟的控制面最終需要跟當(dāng)前嚴(yán)選 API 網(wǎng)關(guān)的管理平臺功能對齊，復(fù)用嚴(yán)選 Ianus 網(wǎng)關(guān)管理平臺的能力，包括配置管理、API 發(fā)布管控等等，確保用戶體驗(yàn)的一致性！

輕舟 Envoy 網(wǎng)關(guān)配置下發(fā)鏈路

如上圖所示，為整個控制面的下發(fā)鏈路，主要組件包括：

API Gateway Admin

嚴(yán)選網(wǎng)關(guān)管理平臺，集成到現(xiàn)有的網(wǎng)關(guān)管理平臺中，通過數(shù)據(jù)中心（嚴(yán)選|輕舟）的切換，實(shí)現(xiàn)兩邊配置的管理，對外展示表現(xiàn)完全一致。

API Plane

輕舟 Envoy 網(wǎng)關(guān)控制面配置適配層，負(fù)責(zé)接收配置數(shù)據(jù)（嚴(yán)選 API 配置模型），轉(zhuǎn)化格式（對應(yīng)到 Istio 模型），并存儲到 K8S Config Store。嚴(yán)選負(fù)責(zé)嚴(yán)選適配組件的擴(kuò)展開發(fā)，輕舟負(fù)責(zé)基礎(chǔ)功能的實(shí)現(xiàn)。主要功能包括，網(wǎng)關(guān)集群獲取、后端服務(wù)列表獲取、插件列表 / 詳情獲取、API 創(chuàng)建 / 刪除等。最終發(fā)布時(shí)，將輕舟側(cè)代碼反向同步到嚴(yán)選側(cè)的 GIT 上，統(tǒng)一到嚴(yán)選的發(fā)布體系中。

Istio Pilot

Pilot 作為 Istio ServiceMesh 方案控制面組件，主要負(fù)責(zé)以下功能：

1、從注冊中心獲取服務(wù)注冊信息，并轉(zhuǎn)換為 CDS，EDS 下發(fā)。

2、從配置中心獲取服務(wù)配置信息，并轉(zhuǎn)換為 LDS，RDS，CDS 下發(fā)。

3、Envoy 靜態(tài)配置的生成以及生命周期的管理。

嚴(yán)選 ServiceMesh2.0 解決方案中，Pilot 分飾兩角，一個作為網(wǎng)格內(nèi)服務(wù)控制面，另一個作為網(wǎng)關(guān)服務(wù)控制面。

插件能力建設(shè)

為支持嚴(yán)選 Ianus 網(wǎng)關(guān)長期的演進(jìn)遷移到輕舟 Envoy 網(wǎng)關(guān)，同時(shí)參考了 Kong 和 Envoy 已有的插件能力進(jìn)行落地。

Envoy 原生插件

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

落地時(shí)，對插件配置的轉(zhuǎn)換進(jìn)行了規(guī)范，歸一到 Schema 上來，后端根據(jù)該 Schema 進(jìn)行統(tǒng)一的 Istio 資源轉(zhuǎn)換，前端管理平臺根據(jù) Schema 進(jìn)行統(tǒng)一的配置頁面渲染。開發(fā)成本縮減到一個模塊，擴(kuò)展優(yōu)勢得到體現(xiàn)。

LUA 擴(kuò)展插件

嚴(yán)選 Ianus 網(wǎng)關(guān)下，基于 Kong 的 LUA 插件擴(kuò)展能力，已經(jīng)實(shí)現(xiàn)了較豐富的功能插件，如果直接切換到輕舟 Envoy 網(wǎng)關(guān)，則原有的插件都需要按照新的規(guī)范重新開發(fā)。

在 Envoy 現(xiàn)有插件的基礎(chǔ)上，擴(kuò)充 LUA 插件開發(fā)的能力。嚴(yán)選側(cè)總結(jié)分享 Kong 現(xiàn)有的插件開發(fā)實(shí)踐，為 Envoy 下 LUA 插件的規(guī)范提供參考，最終保證兩者上手的差異最小化。落地遷移時(shí)，基本復(fù)用了嚴(yán)選 Ianus 網(wǎng)關(guān)的插件代碼，插件遷移代價(jià)（不論是開發(fā)還是測試）非常低，提高了輕舟 Envoy 網(wǎng)關(guān)的插件建設(shè)效率。

收益啟示

通過上述工作，我們實(shí)現(xiàn)了：

1、網(wǎng)關(guān)管理平臺復(fù)用，保證用戶習(xí)慣一致性。

2、LUA 插件復(fù)用，方便擴(kuò)展功能的無縫遷移。

3、函數(shù)級別路由能力的支持，為后續(xù) FaaS 的引流鋪平了道路。

整個控制面共建過程，Kong 與 Envoy 兩個技術(shù)棧取長補(bǔ)短，共同打造了基于云原生的輕舟 Envoy 網(wǎng)關(guān)體系，這也是我們未來的發(fā)展方向。

總結(jié)

API 網(wǎng)關(guān) 1.0（嚴(yán)選 Ianus 網(wǎng)關(guān)）在過去兩年的時(shí)間中發(fā)揮的作用是舉足輕重的，并且在整個嚴(yán)選業(yè)務(wù)遷移上云的過程中也承載著核心流量調(diào)度管控。同時(shí)在 API 網(wǎng)關(guān) 2.0（輕舟 Envoy 網(wǎng)關(guān)）崛起的過程中，Ianus 網(wǎng)關(guān)也給出了有價(jià)值的參考，如插件體系的建設(shè)等。在接下來的道路中，API 網(wǎng)關(guān) 2.0 將持續(xù)跟進(jìn)云原生、Serverless 等的步伐，并不斷輸出反哺業(yè)界和社區(qū)，最終成為網(wǎng)關(guān)的引領(lǐng)者！

作者簡介：

楊文超，2012 年加入網(wǎng)易，資深 JAVA 開發(fā)，致力于服務(wù)端的技術(shù)研發(fā)及方案設(shè)計(jì)工作，目前在數(shù)據(jù)平臺及風(fēng)控部，負(fù)責(zé)嚴(yán)選 FaaS 平臺的建設(shè)。主導(dǎo)了網(wǎng)易嚴(yán)選風(fēng)控系統(tǒng)、網(wǎng)關(guān)系統(tǒng)建設(shè)。