阿里億級長連網關的雲原生演進之路（2020最新沉澱）

時間 2020-11-26

標籤 nginx 後端 api 安全網絡架構負載均衡 less 運維 ide 欄目阿里巴巴简体版

原文原文鏈接

導讀

AServer接入網關承載整個阿里集團的入口流量，負責億級用戶的長鏈保活，支持上萬路由策略轉發，是鏈接上億用戶與後端幾十萬服務節點的橋樑，在今年雙十一須要支撐億級在線用戶、千萬級QPS、生效上萬條API管控策略，作到了安全可靠的轉發路由，並保障了用戶體驗如絲般順滑。nginx

在大規模業務流量與管控支撐的背後，須要對系統每個細節的精確把控，消除每個潛在的風險點。後端

藉助雲原生架構能夠極大地簡化運維操做，下降了潛在的風險，今年雙十一阿里AServer接入網關上千臺規模的Pod平穩扛過峯值。本文主要介紹阿里AServer接入網關如何從上一代架構擁抱變化，全面雲原生的演進之路。api

（更多幹貨請關注【淘系技術】公衆號）

1、架構演進背景

每一年雙十一大促都是對阿里全部服務最嚴峻的考驗，尤爲對AServer接入網關來講，做爲阿里集團第一道門戶，須要抵禦大促峯值帶來的流量洪峯，清洗攻擊流量，所需集羣規模巨大。安全

巨大集羣規模，以及對機器性能極致要求，致使了運維上的複雜性；隨着接入業務的增多，所支持的業務場景擴寬，業務對路由策略的靈活性、生效的實時性要求變高，對路由策略的動態編排能力有着強烈訴求；因爲業務的多樣性，業務線不一樣封網節奏，以及故障隔離性，衍生出對流量隔離的穩定性訴求。網絡

運維的複雜性、動態編排的訴求、流量隔離以及對性能的極致要求，推進着AServer接入網關不斷演變和成長，緊跟業務的發展步伐的同時，逐步下降運維成本的，加強系統穩定性，可以一次又一次經受住雙十一的考驗。架構

1.業務背景

做爲阿里集團AServer接入網關，承載整個阿里集團入口流量，最開始支持域名轉發策略的tengine網關，根據域名轉發到後端不一樣服務，業務形態相對簡潔。負載均衡

來到All in無線時代，爲優化手機端側的用戶體驗，同時降級服務端人員的開發成本，集團自研了MTOP（Mobile Taobao Open Platform）API網關，爲客戶端和服務端提供了一致的API平臺，相同的域名，僅經過URI攜帶的API信息轉發到對應業務，接入網關須要支持按照API（經過URI區分）的路由轉發能力，幾年時間迅速增長到數萬規則。less

隨着業務發展愈來愈精細化，指望對同一API下的不一樣業務場景進行細分，如針對雙十一大促會場的來源，手淘、支付寶、其餘外投頁面等場景進行更精細化控制，爲適應業務發展，網關須要支持精細化的管控能力，根據業務請求參數、請求頭進行管控和分流。每個請求都要從上萬靈活的配置規則中匹配出惟一的路徑，同時又要保持極高的性能，是一件極具挑戰性的事情。運維

（業務模型圖）ide

2.運維體系背景

最開始基礎配套的基礎設施並不完善，網關層基於tengine搭建，最簡單快速的方案即是使用物理機，部署進程和配置便可完成服務搭建。隨着業務增加，配置管理就成爲瓶頸，網關層須要一個強有力的配置管理平臺，經過標準化的方式生成業務配置，配套自研的配置管理平臺把配置劃分爲應用配置、公共配置管理、證書配置三部分。

公共配置：經過Git版本管理方式生成tengine運行的基本配置，如啓用模塊配置，tengine運行邏輯配置
應用配置：經過標準的模板生成業務所需的tengine配置
證書配置：因爲證書存在有效期，爲了防止過時時忘記更新，還承擔了證書自動更新任務

最初的系統部署架構：

該方案能夠實現業務自助接入，經過配置管理平臺的模板生成 tengine 配置，再由定時推送到網關機器並進行進程的reload，生效配置。

經過這種運維方式，不依賴基礎設施，能夠快速演進，但隨着業務增加以及集羣規模的上漲，物理機的運維方式弊端逐步顯現，野蠻生長的時代過去，做爲阿里服務入口，穩定性成爲了重中之重，物理機的二進制發佈依賴人工部署，需批量執行命令安裝rpm包，而且分批restart進程，這一切都是黑屏操做完成。

此種運維方式顯然沒法知足如今的穩定性需求，經過手工發佈，極易出現誤操做致使系統性故障。另外物理機運維很難進行一致性保障，包括二進制的一致性，機器自己環境的一致性檢查（如內核參數等），過去的手工運維方式顯然已經跟不上時代的步伐。

解決發佈和環境一致性問題的最優方案即是容器化技術，隨着集團基礎設施的完善，接入網關容器化改造掃除了障礙，把不變量（系統配置、二進制）打包成一體進行發佈，把變量（應用配置、公共配置、證書）繼續沿用配置管理平臺進行管理，配合容器化技術進行調整。

容器化改造後的發佈和配置變動流程：

容器化架構，簡化了建站、擴縮容操做，發佈效率有了極大的提高，增長審批流程，系統化卡點，避免了人爲操做可能致使故障，發佈流程還可對接監控系統，自動告警並暫停發佈。

3.核心問題

隨着電商業務發展愈來愈快，規模化達到瓶頸之後，業務就會有更多的橫向擴展，精細化程度愈來愈高，迭代速度也隨之變高，網關層適應業務的變化的成本也來越高，由此帶來的核心問題：

運維操做複雜性：因爲對性能的極致要求，網關集羣對機器有着特殊的要求；因爲網關配置管理的特殊性，致使了運維操做的複雜性；特殊性的存在沒法很好對接集團現有運維體系，須要進行運維體系的升級；
動態編排能力不足：隨着接入業務的增多，所支持的業務場景擴寬，業務對路由策略的靈活性、實時性要求愈來愈高，靜態配置不論生效的實時性仍是策略靈活性都難以知足業務發展需求，須要支持路由策略的動態編排能力；
流量隔離成本較高：缺少輕量級業務範圍隔離能力，經過新建集羣實現的成本太高，爲支持業務線不一樣封網節奏，以及支持故障隔離性，須要輕量級的多集羣流量隔離方案。

雲原生近年來的飛速發展，也爲網關層提供了更好的架構選擇。

2、雲原生架構

爲解決接入網關現存問題，結合集團業務場景以及雲原生的開源體系，開啓了AServer接入網關的雲原生演進之路，爲了分步驗證，分解三個階段逐步實現：運維體系升級，服務治理&網關Mesh化，南北向架構拆分。接下來對每個步驟進行詳細的演進說明。

1. 運維體系升級

1.1 待解決問題

經過容器化升級部署，極大的簡化了部署運維方式，可以解決當時最突出的問題，但僅僅改造部署方式還遠遠不夠：

因爲接入網關有着特殊性（如須要對接配置管理平臺，有着大量的VIP需求），沒法直接對接集團的基礎設施，開發了獨立的定製化化的運維工具，擴縮容流程須要多個基礎組件經過非標接口配合進行，極大的影響了運維產品的迭代效率
故障機置換機器等操做，依賴外部系統輪詢檢測，而且集團基礎設置系統跟定製運維平臺對接才能處理，有較大時延
運維操做脫離集團運維體系

1.2 演進思路

隨着集團內針對雲原生應用設計的統一基礎設施ASI（Alibaba Serverless infrastructure）的逐步完善，提供了基於原生K8S API的完整雲原生技術棧支持。

雲原生方案可編排能力很強，經過自定義實現k8s擴展，很是容易抹平網關層的特殊性，ASI 原有的自動化運維手段，可直接應用於網關層。

網關層對機型的特殊性，能夠經過節點池劃分來實現，網關機器節點池可自定義機型以及內核參數，消除網關運維上的特殊性，統一管理運維。

1.3 演進方案

經過 k8s 自身的 Controller 擴展能力，自定義容器編排，在擴縮容時能夠監聽Pod變動事件對配置管理平臺進行機器增刪操做，同時也能夠掛載/卸載VIP，抹平運維上的特殊性，而且全部資源都經過聲明式API定義，方便運維。

對於網關運維，還須要保留一個很是簡單的運維平臺，僅作建站之用，對比普通應用，網關建站須要在對應區域建立VIP，進行域名綁定等操做，輕量且易維護：

經過進行ASI化改造，使得接入網關的運維融入集團ASI雲原生體系（提高交付效率，去除特殊化運維），通用能力下沉至ASI和基礎系統，同時具有了風險隔離、自恢復、彈性能力

風險隔離：使用Sidecar能力隔離安全和工程能力，避免兩者的互相干擾，安全能力出現異常，隻影響流量清洗，降級安全能力後，不至於服務總體不可用；
自恢復：對於容器自愈能力，原有容器化方式依賴外部應用的輪詢檢測，不管是準確性和實時性達都有所欠缺，升級ASI後，經過容器自身的檢測，可在3-5分鐘內識別並置換故障容器；
彈性能力：自動彈性能力，經過ASI的改造，各系統的對接方式可使用標準的聲明式API，整合集團內各組件，極大的簡化了擴縮容操做，爲自動彈性提供了支持；
屏蔽機型差別：經過節點池劃分，針對網關應用可以使用特殊的機型，底層配置屏蔽差別，無需特殊操做。

2.服務治理&網關Mesh化

2.1 待解決問題

隨着網關層接入的業務類型增多，須要支持上萬條API路由規則，並且路由策略也愈來愈精細化，使用tengine原生能力沒法知足業務需求。經過定製開發tengine模塊，非標的定義方式，過去幾年中能夠很好適應業務的發展，但隨着業務訴求愈發精細化，定製開發tengine模塊的成本也逐步變大

原有架構

路由配置經過模塊配置+原生配置組合而成，多個模塊配置共同決定路由策略，分散的配置沒法對一個請求完整的路由路徑的識別；
經過功能模塊劃分，想要按照業務粒度的進行增量更新較難實現；
基於tengine架構，動態變動能力不足，域名變動每日定時推送配置並生效，沒法知足業務快速迭代需求；
非標準協議直接跟不一樣管控平臺直接對接，對接成本較高，而且不容易收口管控；
對於不一樣業務線（如淘系、優酷），要作到資源隔離，因爲多數模塊配置使用靜態的公共配置，建站成本較高。

2.2 演進思路

如何動態編排、精細化的控制路由策略，是在雲原生體系下首要考慮的問題。參考對比業界網關層作法，如Kong，Ambassador等，主流網關數據面實現都是基於nginx或者envoy，不一樣產品的擴展性、動態編排能力、成熟度的對比狀況：

從動態性、標準性、性能方面綜合考慮，使用envoy做爲數據面更適合雲原生演進方向：

動態性和靈活性
envoy實現的標準xDS協議足夠靈活，而且可所有動態配置和變動
envoy擴展性足夠好，可經過實現filter擴展實現集團內特有的路由邏輯
標準性
istio標準組件，社區支持力度大，發展迅速
阿里集團mesh化使用istio技術方案，使用envoy做爲數據面選項可以跟集團業務管控的統一化
性能
C++實現，性能足夠好，而開發效率比tengine高

而envoy不足之處在於做爲istio標準組件，東西向路由能力較強，做爲南北向須要進行必定性能和穩定性優化，但長遠來看，動態性和標準性更爲重要。

2.3 演進方案

複用集團Pilot做爲統一的控制面組件，實現網關自身的Mesh化：

控制面爲提供各透出的業務產品寫入，需提供一層管控邏輯進行權限的收口，各產品經過k8s聲明式api寫入路由策略，再由Pilot控制面轉換爲xDS數據面協議，實時同步給數據面Envoy，南向路由網關的實現架構：

因爲集團的配置規模較大，數十萬的路由規則和數千應用，幾十萬業務節點，開源體系鮮有如此規模。Pilot + Envoy方案應用於南北向網關後，須要對原生組件作必定的優化和定製，以解決規模化引發的性能和穩定性問題：

Pilot支持SRDS協議：解決大規模API配置致使的線性匹配性能問題
增量配置更新：實現並完善控制面增量更新能力，避免全量更新致使變動半徑擴大風險
節點變動優化：解決幾十萬業務節點的狀態變動對控制面和數據面性能影響
擴展定製：針對集團特有的路由規則，定製filter實現

經過對開源體系進行定製和優化，能夠很好的對接集團內的需求，經過靈活的配置組合，經過快速迭代控制面透傳的能力，實現集團內不一樣業務的特殊需求。

3.南北向拆分

3.1 待解決問題

網關做爲用戶跟業務的橋樑，對用戶端保活長鏈，協議優化，讓用戶儘量快速穩定的連到集團；對業務支持靈活的路由和熔斷限流策略，負載均衡。雖然鏈接保活跟路由轉發做爲網關的總體能力透出，但兩者的迭代效率的訴求，以及業務特色都有較大差別。

在一些大促活動場景，即便有預期外的流量洪峯，網關層做爲保護業務服務的屏障，仍然能夠作到穩如磐石，依賴於高性能和水位的預留。考慮到保活長鏈，協議優化有這較長的迭代週期，性能極高；路由轉發和流量清洗因爲策略靈活複雜，資源消耗天然相對較高，如把兩者進行架構拆分，能夠極大的提高總體資源的使用率。

3.2 演進思路和方案

把協議卸載、長鏈保活等跟客戶端交互，而且可以保有極高性能的模塊，單獨拆分爲北向集羣，因爲性能很好，只須要少許的機器，即可築高壩擋洪流；對於跟業務路由策略相關，以及安全清洗能力，消耗性能較多，拆分到南向集羣，經過北向的高壩保護南向集羣不會過載，南向集羣可減小預留水位，進而提高總體的資源利用率，如此可作到即可以提高資源利用率，又可進行靈活配置適應業務快速發展的需求。

4.總體架構

經過三個階段演進，終局架構圖以下：

AServer接入網關雲原生架構

統一控制面：經過集團統一控制面進行服務接入、服務發現、熔斷限流控制，起到變動收口統一處理的做用；
北向鏈接層：基於tengine承載億級在線用戶和流量洪峯，起到高水壩做用，提高南向路由層資源利用率；
南向路由層：基於Envoy經過Pilot轉換xDS協議動態下發路由策略，實現動態編排路由、輕量級流量隔離方案；
雲原生基座：運維操做創建在集團統一基礎設施ASI，屏蔽網關差別性，下降運維複雜性。

3、將來

阿里AServer接入網關一步步向雲原生演進，每次演進都是基於長久以來困擾咱們的問題，但又不只僅止步於解決問題，同時基於當前時代的解決方案，雲原生架構改造也遠不是終點，雲原生的優點也還沒有徹底發揮。技術的升級最終是爲產品服務，雲原生升級以後，讓咱們有了一個強有力的引擎，接下來須要作的就是利用這個引擎改造產品形態，讓基於網關之上的開發者最終受益。

1.產品整合

什麼樣的狀態纔是一個網關產品最好的狀態呢？開發者天天都在使用，但又無需關心網關的存在，這樣存在感最低的狀態或許就是最優的狀態。當前接入網關從產品形態上暴露了一些實現細節，一個入口應用上線須要經過若干不一樣系統交互才能完成接入，在雲原生改造完成後，能夠更好的實現All in One，產品上作到一體化和閉環。

2.快速彈性

雖完成ASI Pod升級改造，可自動化執行故障機置換，機器遷移等操做，下降了運維成本，但上雲最重要的一項能力就是快速彈性，如能夠在雙十一峯值大促前快速擴容，大促事後快速縮容，可極大減小爲準備大促所保有的機器資源，從而節省巨量的成本。固然其中要解決的問題也不少，如安全性可靠性，彈性的實時性，這都須要配合雲的基礎設施共同建設，真正發揮雲上的優點。