原創 鄧波(光錐) 淘系技術 2020-11-24
架構演進背景
每年雙十一大促都是對阿裡所有服務最嚴峻的考驗，尤其對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更新改造，可自動化執行故障機置換，機器遷移等操作，降低了運維成本，但上雲最重要的一項能力就是快速彈性，如可以在雙十一峰值大促前快速擴容，大促過後快速縮容，可極大減少為準備大促所保有的機器資源，進而節省巨量的成本。當然其中要解決的問題也很多，如安全性可靠性，彈性的實時性，這都需要配合雲的基礎設施共同建設，真正發揮雲上的優勢。