嚴選自2016年誕生以來，不論從業務、技術還是體量，每年都在飛速發展。而作爲嚴選對外服務的總入口，網關承接了主要的業務流量，保障着嚴選業務的穩定運行，並幫助業務進行更好的容災和降級。
隨着服務化、容器化的演進，嚴選API網關也轉變角色，作爲嚴選邊緣網關，協助業務進行無感知的流量遷移。最後，嚴選API網關統一到了基於雲原生的輕舟Envoy 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網關的打怪升級之旅！
部署架構
如上圖所示：
-
Yanxuan-Ianus：數據面組件，承接實際的業務流量。
-
Yanxuan-Ianus-PGProxy：控制面代理組件，對PostgreSQL寫操作進行收斂，而Yanxuan-Ianus只保留只讀權限，消除安全隱患。
-
Yanxuan-Ianus-Admin：控制面組件，提供完整的API配置、插件配置等操作。
如上圖所示，爲數據面的具體部署拓撲，通過合理的集羣規劃，可以做到：
-
物理上對業務進行隔離，避免相互干擾。
-
集羣根據自身業務流量進行容量配比，有利於資源精細化管理。
-
通過集羣方式進行API的配置管理，理解直觀、配置清晰。
數據面建設
如上圖所示，數據面具體技術棧實現爲：
-
Nginx：以Openresty主版本依賴爲準，擴充引入所需的功能模塊，其中consul-module用於集成Consul，統一到嚴選Servicemesh1.0的服務治理體系中；vts-module用於統計監控信息的採集。
-
Openresty：直接引入官方的穩定版本，不做額外變更。
-
Yanxuan-Kong：引入Kong的主幹版本，並進行額外的功能擴展，包括參數路由、集羣管理、租戶管理、灰度發佈等等。
-
Yanxuan-Ianus：所有擴展功能插件均在此管理，適配微服務形態的地址路由等。
控制面建設
Kong原生的配置管理，沒有權限控制，沒有版本記錄，功能缺失較多，無法應用於生產環境。因此，我們對控制面進行了如下增強：
- 版本信息管理
在現有配置基礎之上，包裝了基於MongoDB的配置管理，支持歷史版本的回溯、版本回退、版本比較等功能。有效地避免了配置出錯導致的無法回滾，或回滾不方便等問題。
- 標準化配置流程
接入嚴選工單體系，提供統一的配置申請、審覈、發佈等節點動作，有效地對業務配置需求進行管理，在流程上對配置更新進行管控。
接入嚴選報警體系，在配置變更時，將變更通知到業務負責人、配置人員、網關運維人員，確保實時感知配置變動，預知風險點。
- 灰度發佈功能
將配置下發到指定的網關實例節點，進行灰度驗證，最小化配置出錯的影響範圍。
插件能力建設
Kong在Openresty上做的一項重大改進，就是對插件的規範，支持了熱插拔、配置動態下發等能力。嚴選擴充了頻控插件、路由插件、請求/響應轉換插件等30餘個，同時也爲部分業務定製了功能插件，如AB實驗分流插件、登錄鑑權插件、身份信息提取插件等。
- 容災能力
- 增加了按百分比進行限流的能力，並支持分地域差別處理。
- 熔斷降級能力，按需熔斷部分非重點業務接口，保證業務主體功能的穩定。
- 頻控限流能力，根據服務自身的承載能力，在網關側配置相應閥值，避免業務被突發流量打垮。
-
鏈路跟蹤
基於插件形式擴展，與嚴選APM體系集成，將網關的請求數據採集到全鏈路監控體系中，補齊鏈路節點，消除鏈路追蹤盲點。爲避免引入性能損耗，此處基於日誌進行異步上報，並且採樣率可通過插件配置參數進行調整。 -
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網關的需求以及當前的工程建設規劃出發，給出設計和建議。數據面部分，考慮了現有輕舟微服務體系的無縫融合以及主流的產品實現，選型採用了Envoy進行數據面的建設；控制面部分，考慮到嚴選需要複用現有管理平臺的功能，則基於現有的Istio體系進行共建。
部署架構
如上圖所示，整體分爲控制面和數據面兩部分。數據面由雙方共建設計方案，落地交由輕舟負責；控制面嚴選跟輕舟共建，統一到已有嚴選API網關管理平臺。而具體數據面集羣的規劃，沿用了嚴選Ianus網關的部署方式，在此不再贅述。
數據面建設
如上圖所示，數據面在選型時，對流量是否要經過網關和Sidecar兩層進行了權衡，從簡化調用鏈路，網關與Sidecar角色差異考慮，採用了繞過Sidecar的模式。此時網關部分功能與Sidecar功能雖有重合，但與ServiceMesh保持了獨立，可各自演進。當前支持的基礎功能包括：默認路由能力、版本分流能力、兜底路由能力等。特別地，對請求流量治理時，需要同時考慮ServiceMesh跟API網關的控制指令下發。
控制面建設
如上圖所示，爲了保持嚴選API網關產品的一致性，輕舟的控制面最終需要跟當前嚴選API網關的管理平臺功能對齊，複用嚴選Ianus網關管理平臺的能力，包括配置管理、API發佈管控等等，確保用戶體驗的一致性！
如上圖所示，爲整個控制面的下發鏈路，主要組件包括：
- 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平臺的建設。主導了網易嚴選風控系統、網關係統建設。