光錐?

阿里巴巴新零售淘系技術

讀完需要

20

分鐘

速讀僅需 5 分鐘

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升級改造，可自動化執行故障機置換，機器遷移等操作，降低了運維成本，但上云最重要的一項能力就是快速彈性，如可以在雙十一峰值大促前快速擴容，大促過后快速縮容，可極大減少為準備大促所保有的機器資源，從而節省巨量的成本。當然其中要解決的問題也很多，如安全性可靠性，彈性的實時性，這都需要配合云的基礎設施共同建設，真正發揮云上的優勢。

- EOF -

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

阿里技術精彩文章推薦

往期推薦

深度：揭秘阿里巴巴的客群畫像

多隆：從工程師到阿里巴巴合伙人

阿里技術專家楚衡：架構制圖的工具與方法論

螞蟻集團技術專家山丘：性能優化常見壓測模型及優缺點

阿里文娛技術專家戰獒: 領域驅動設計詳解之What, Why, How?

阿里專家馬飛翔：一文讀懂架構整潔之道

阿里專家常昊：新人如何上手項目管理？

螞蟻集團沈凋墨：Kubernetes-微內核的分布式操作系統

阿里合伙人范禹：常掛在阿里技術人嘴邊的四句土話

阿里技術專家都鐸：一文搞懂技術債

支付寶研究員兼OceanBase總架構師楊傳輝：我在數據庫夢之隊的十年成長路

阿里技術專家麒燁：修煉測試基本功

阿里計算平臺掌門人賈揚清：我對人工智能方向的一點淺見

螞蟻資深算法專家周俊：從原理到落地，支付寶如何打造保護隱私的共享智能？

阿里高級技術專家簫逸：如何畫好一張架構圖？

阿里高級技術專家張建飛：應用架構分離業務邏輯和技術細節之道

螞蟻科技 Service Mesh 落地實踐與挑戰 | GIAC 實錄

阿里6年，我的技術蛻變之路！

螞蟻集團涵暢：再啟程，Service Mesh 前路雖長，尤可期許

阿里P9專家右軍：大話軟件質量穩定性

阿里合伙人程立：阿里15年，我撕掉了身上兩個標簽

阿里高工流生 | 云原生時代的 DevOps 之道

阿里高級技術專家邱小俠：微服務架構的理論基礎 - 康威定律

阿里P9專家右軍：以終為始的架構設計

阿里P8架構師：淘寶技術架構從1.0到4.0的架構變遷！12頁PPT詳解

阿里技術：如何畫出一張合格的技術架構圖？

? ?END ? ?? #架構師必備#點分享點點贊點在看

總結

以上是生活随笔為你收集整理的阿里技术专家光锥：亿级长连网关的云原生演进之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。