作者：光錐
AServer接入閘道器承載整個阿里集團的入口流量，負責億級使用者的長鏈保活，支援上萬路由策略轉發，是連線上億使用者與後端幾十萬服務節點的橋樑，在去年雙十一需要支撐億級線上使用者、千萬級QPS、生效上萬條API管控策略，做到了安全可靠的轉發路由，並保障了使用者體驗如絲般順滑。
在大規模業務流量與管控支撐的背後，需要對系統每一個細節的精確把控，消除每一個潛在的風險點。
藉助雲原生架構可以極大地簡化運維操作，降低了潛在的風險，去年雙十一阿里AServer接入閘道器上千臺規模的Pod平穩扛過峰值。本文主要介紹阿里AServer接入閘道器如何從上一代架構擁抱變化，全面雲原生的演進之路。
架構演進背景
每年雙十一大促都是對阿里所有服務最嚴峻的考驗，尤其對AServer接入閘道器來說，作為阿里集團第一道門戶，需要抵禦大促峰值帶來的流量洪峰，清洗攻擊流量，所需叢集規模巨大。
巨大叢集規模，以及對機器效能極致要求，導致了運維上的複雜性；隨著接入業務的增多，所支援的業務場景擴寬，業務對路由策略的靈活性、生效的實時性要求變高，對路由策略的動態編排能力有著強烈訴求；由於業務的多樣性，業務線不同封網節奏，以及故障隔離性，衍生出對流量隔離的穩定性訴求。
運維的複雜性、動態編排的訴求、流量隔離以及對效能的極致要求，推動著AServer接入閘道器不斷演變和成長，緊跟業務的發展步伐的同時，逐步降低運維成本的，增強系統穩定性，能夠一次又一次經受住雙十一的考驗。
業務背景
作為阿里集團AServer接入閘道器，承載整個阿里集團入口流量，最開始支援域名轉發策略的tengine閘道器，根據域名 轉發到後端不同服務，業務形態相對簡潔。
來到All in無線時代，為優化手機端側的使用者體驗，同時降級服務端人員的開發成本，集團自研了MTOP（Mobile Taobao Open Platform）API閘道器，為客戶端和服務端提供了一致的API平臺，相同的域名，僅通過URI攜帶的API資訊轉發到對應業務，接入閘道器需要支援按照API（通過URI區分）的路由轉發能力，幾年時間迅速增加到數萬規則。
隨著業務發展越來越精細化，期望對同一API下的不同業務場景進行細分，如針對雙十一大促會場的來源，手淘、支付寶、其他外投頁面等場景進行更精細化控制，為適應業務發展，閘道器需要支援精細化的管控能力，根據業務請求引數、請求頭進行管控和分流。每一個請求都要從上萬靈活的配置規則中匹配出唯一的路徑，同時又要保持極高的效能，是一件極具挑戰性的事情。
運維體系背景
最開始基礎配套的基礎設施並不完善，閘道器層基於tengine搭建，最簡單快速的方案便是使用物理機，部署程式和配置即可完成服務搭建。隨著業務增長，配置管理就成為瓶頸，閘道器層需要一個強有力的配置管理平臺，通過標準化的方式生成業務配置，配套自研的配置管理平臺把配置劃分為應用配置、公共配置管理、證書配置三部分。
- 公共配置：通過Git版本管理方式生成tengine執行的基本配置，如啟用模組配置，tengine執行邏輯配置
- 應用配置：通過標準的模板生成業務所需的tengine配置
- 證書配置：由於證書存在有效期，為了防止過期時忘記更新，還承擔了證書自動更新任務
最初的系統部署架構：
該方案可以實現業務自助接入，通過配置管理平臺的模板生成 tengine 配置，再由定時推送到閘道器機器並進行程式的reload，生效配置。
通過這種運維方式，不依賴基礎設施，可以快速演進，但隨著業務增長以及叢集規模的上漲，物理機的運維方式弊端逐步顯現，野蠻生長的時代過去，作為阿里服務入口，穩定性成為了重中之重，物理機的二進位制釋出依賴人工部署，需批量執行命令安裝rpm包，並且分批restart程式，這一切都是黑屏操作完成。
此種運維方式顯然無法滿足現在的穩定性需求，通過手工釋出，極易出現誤操作導致系統性故障。另外物理機運維很難進行一致性保障，包括二進位制的一致性，機器本身環境的一致性檢查（如核心引數等），過去的手工運維方式顯然已經跟不上時代的步伐。
解決釋出和環境一致性問題的最優方案便是容器化技術，隨著集團基礎設施的完善，接入閘道器容器化改造掃除了障礙，把不變數（系統配置、二進位制）打包成一體進行釋出，把變數（應用配置、公共配置、證書）繼續沿用配置管理平臺進行管理，配合容器化技術進行調整。
容器化改造後的釋出和配置變更流程：
容器化架構，簡化了建站、擴縮容操作，釋出效率有了極大的提升，增加審批流程，系統化卡點，避免了人為操作可能導致故障，釋出流程還可對接監控系統，自動告警並暫停釋出。
核心問題
隨著電商業務發展越來越快，規模化達到瓶頸以後，業務就會有更多的橫向擴充套件，精細化程度越來越高，迭代速度也隨之變高，閘道器層適應業務的變化的成本也來越高，由此帶來的核心問題：
- 運維操作複雜性：由於對效能的極致要求，閘道器叢集對機器有著特殊的要求；由於閘道器配置管理的特殊性，導致了運維操作的複雜性；特殊性的存在無法很好對接集團現有運維體系，需要進行運維體系的升級；
- 動態編排能力不足：隨著接入業務的增多，所支援的業務場景擴寬，業務對路由策略的靈活性、實時性要求越來越高，靜態配置不論生效的實時性還是策略靈活性都難以滿足業務發展需求，需要支援路由策略的動態編排能力；
- 流量隔離成本較高：缺乏輕量級業務範圍隔離能力，通過新建叢集實現的成本過高，為支援業務線不同封網節奏，以及支援故障隔離性，需要輕量級的多叢集流量隔離方案。
雲原生近年來的飛速發展，也為閘道器層提供了更好的架構選擇。
雲原生架構
為解決接入閘道器現存問題，結合集團業務場景以及雲原生的開源體系，開啟了AServer接入閘道器的雲原生演進之路，為了分步驗證，分解三個階段逐步實現：運維體系升級，服務治理&閘道器Mesh化，南北向架構拆分。接下來對每一個步驟進行詳細的演進說明。
運維體系升級
待解決問題
通過容器化升級部署，極大的簡化了部署運維方式，能夠解決當時最突出的問題，但僅僅改造部署方式還遠遠不夠：
- 由於接入閘道器有著特殊性（如需要對接配置管理平臺，有著大量的VIP需求），無法直接對接集團的基礎設施，開發了獨立的定製化化的運維工具，擴縮容流程需要多個基礎元件通過非標介面配合進行，極大的影響了運維產品的迭代效率
- 故障機置換機器等操作，依賴外部系統輪詢檢測，並且集團基礎設定系統跟定製運維平臺對接才能處理，有較大時延
- 運維操作脫離集團運維體系
演進思路
隨著集團內針對雲原生應用設計的統一基礎設施ASI（Alibaba Serverless infrastructure）的逐步完善，提供了基於原生K8S API的完整雲原生技術棧支援。
雲原生方案可編排能力很強，通過自定義實現k8s擴充套件，非常容易抹平閘道器層的特殊性，ASI 原有的自動化運維手段，可直接應用於閘道器層。
閘道器層對機型的特殊性，可以通過節點池劃分來實現，閘道器機器節點池可自定義機型以及核心引數，消除閘道器運維上的特殊性，統一管理運維。
演進方案
通過 k8s 自身的 Controller 擴充套件能力，自定義容器編排，在擴縮容時可以監聽Pod變更事件對配置管理平臺進行機器增刪操作，同時也可以掛載/解除安裝VIP，抹平運維上的特殊性，並且所有資源都通過宣告式API定義，方便運維。
對於閘道器運維，還需要保留一個非常簡單的運維平臺，僅做建站之用，對比普通應用，閘道器建站需要在對應區域建立VIP，進行域名繫結等操作，輕量且易維護：
通過進行ASI化改造，使得接入閘道器的運維融入集團ASI雲原生體系（提升交付效率，去除特殊化運維），通用能力下沉至ASI和基礎系統，同時具備了風險隔離、自恢復、彈效能力
- 風險隔離：使用Sidecar能力隔離安全和工程能力，避免二者的互相干擾，安全能力出現異常，隻影響流量清洗，降級安全能力後，不至於服務整體不可用；
- 自恢復：對於容器自愈能力，原有容器化方式依賴外部應用的輪詢檢測，不論是準確性和實時性達都有所欠缺，升級ASI後，通過容器自身的檢測，可在3-5分鐘內識別並置換故障容器；
- 彈效能力：自動彈效能力，通過ASI的改造，各系統的對接方式可以使用標準的宣告式API，整合集團內各元件，極大的簡化了擴縮容操作，為自動彈性提供了支援；
- 遮蔽機型差異：通過節點池劃分，針對閘道器應用可使用特殊的機型，底層配置遮蔽差異，無需特殊操作。
服務治理&閘道器Mesh化
待解決問題
隨著閘道器層接入的業務型別增多，需要支援上萬條API路由規則，而且路由策略也越來越精細化，使用tengine原生能力無法滿足業務需求。通過定製開發tengine模組，非標的定義方式，過去幾年中可以很好適應業務的發展，但隨著業務訴求愈發精細化，定製開發tengine模組的成本也逐步變大
原有架構
- 路由配置通過模組配置+原生配置組合而成，多個模組配置共同決定路由策略，分散的配置無法對一個請求完整的路由路徑的識別；
- 通過功能模組劃分，想要按照業務粒度的進行增量更新較難實現；
- 基於tengine架構，動態變更能力不足，域名變更每日定時推送配置並生效，無法滿足業務快速迭代需求；
- 非標準協議直接跟不同管控平臺直接對接，對接成本較高，並且不容易收口管控；
- 對於不同業務線（如淘系、優酷），要做到資源隔離，由於多數模組配置使用靜態的公共配置，建站成本較高。
演進思路
如何動態編排、精細化的控制路由策略，是在雲原生體系下首要考慮的問題。參考對比業界閘道器層做法，如Kong，Ambassador等，主流閘道器資料面實現都是基於nginx或者envoy，不同產品的擴充套件性、動態編排能力、成熟度的對比情況：
從動態性、標準性、效能方面綜合考慮，使用envoy作為資料面更適合雲原生演進方向：
動態性和靈活性
- envoy實現的標準xDS協議足夠靈活，並且可全部動態配置和變更
- envoy擴充套件性足夠好，可通過實現filter擴充套件實現集團內特有的路由邏輯
標準性
- istio標準元件，社群支援力度大，發展迅速
- 阿里集團mesh化使用istio技術方案，使用envoy作為資料面選項能夠跟集團業務管控的統一化
效能
- C++實現，效能足夠好，而開發效率比tengine高
而envoy不足之處在於作為istio標準元件，東西向路由能力較強，作為南北向需要進行一定效能和穩定性優化，但長遠來看，動態性和標準性更為重要。
演進方案
複用集團Pilot作為統一的控制面元件，實現閘道器自身的Mesh化：
控制面為提供各透出的業務產品寫入，需提供一層管控邏輯進行許可權的收口，各產品通過k8s宣告式api寫入路由策略，再由Pilot控制面轉換為xDS資料面協議，實時同步給資料面Envoy，南向路由閘道器的實現架構：
由於集團的配置規模較大，數十萬的路由規則和數千應用，幾十萬業務節點，開源體系鮮有如此規模。Pilot + Envoy方案應用於南北向閘道器後，需要對原生元件做一定的優化和定製，以解決規模化引起的效能和穩定性問題：
- Pilot支援SRDS協議：解決大規模API配置導致的線性匹配效能問題
- 增量配置更新：實現並完善控制面增量更新能力，避免全量更新導致變更半徑擴大風險
- 節點變更優化：解決幾十萬業務節點的狀態變更對控制面和資料面效能影響
- 擴充套件定製：針對集團特有的路由規則，定製filter實現
通過對開源體系進行定製和優化，可以很好的對接集團內的需求，通過靈活的配置組合，通過快速迭代控制面透傳的能力，實現集團內不同業務的特殊需求。
南北向拆分
待解決問題
閘道器作為使用者跟業務的橋樑，對使用者端保活長鏈，協議優化，讓使用者儘可能快速穩定的連到集團；對業務支援靈活的路由和熔斷限流策略，負載均衡。雖然連線保活跟路由轉發作為閘道器的整體能力透出，但二者的迭代效率的訴求，以及業務特點都有較大差異。
在一些大促活動場景，即使有預期外的流量洪峰，閘道器層作為保護業務服務的屏障，仍然可以做到穩如磐石，依賴於高效能和水位的預留。考慮到保活長鏈，協議優化有這較長的迭代週期，效能極高；路由轉發和流量清洗由於策略靈活複雜，資源消耗自然相對較高，如把二者進行架構拆分，可以極大的提升整體資源的使用率。
演進思路和方案
把協議解除安裝、長鏈保活等跟客戶端互動，並且能夠保有極高效能的模組，單獨拆分為北向叢集，由於效能很好，只需要少量的機器，便可築高壩擋洪流；對於跟業務路由策略相關，以及安全清洗能力，消耗效能較多，拆分到南向叢集，通過北向的高壩保護南向叢集不會過載，南向叢集可減少預留水位，進而提升整體的資源利用率，如此可做到即能夠提升資源利用率，又可進行靈活配置適應業務快速發展的需求。
整體架構
通過三個階段演進，終局架構圖如下：
AServer接入閘道器雲原生架構
- 統一控制面：通過集團統一控制面進行服務接入、服務發現、熔斷限流控制，起到變更收口統一處理的作用；
- 北向連線層：基於tengine承載億級線上使用者和流量洪峰，起到高水壩作用，提升南向路由層資源利用率；
- 南向路由層：基於Envoy通過Pilot轉換xDS協議動態下發路由策略，實現動態編排路由、輕量級流量隔離方案；
- 雲原生基座：運維操作建立在集團統一基礎設施ASI，遮蔽閘道器差異性，降低運維複雜性。
未來
阿里AServer接入閘道器一步步向雲原生演進，每次演進都是基於長久以來困擾我們的問題，但又不僅僅止步於解決問題，同時基於當前時代的解決方案，雲原生架構改造也遠不是終點，雲原生的優勢也尚未完全發揮。技術的升級最終是為產品服務，雲原生升級之後，讓我們有了一個強有力的引擎，接下來需要做的就是利用這個引擎改造產品形態，讓基於閘道器之上的開發者最終受益。
產品整合
什麼樣的狀態才是一個閘道器產品最好的狀態呢？開發者每天都在使用，但又無需關心閘道器的存在，這樣存在感最低的狀態或許就是最優的狀態。當前接入閘道器從產品形態上暴露了一些實現細節，一個入口應用上線需要通過若干不同系統互動才能完成接入，在雲原生改造完成後，可以更好的實現All in One，產品上做到一體化和閉環。
快速彈性
雖完成ASI Pod升級改造，可自動化執行故障機置換，機器遷移等操作，降低了運維成本，但上雲最重要的一項能力就是快速彈性，如可以在雙十一峰值大促前快速擴容，大促過後快速縮容，可極大減少為準備大促所保有的機器資源，從而節省巨量的成本。當然其中要解決的問題也很多，如安全性可靠性，彈性的實時性，這都需要配合雲的基礎設施共同建設，真正發揮雲上的優勢。
關注我們，每週 3 篇移動技術實踐&乾貨給你思考！