作者丨張瓅玶（谷樸）阿里巴巴研究員
阿里巴巴核心系統作爲全球最大規模、峯值性能要求最高的電商交易系統，在 2018 年之前只通過混合雲彈性上雲方式，爲 雙11 節約大量成本。直到 2019 年，阿里巴巴實現了核心交易系統全面上雲並經歷了 雙11 峯值的考驗。
在今天由極客邦科技舉辦的 ArchSummit 全球架構師峯會 2019 北京站上，阿里巴巴研究員張瓅玶博士作了主題演講《阿里巴巴核心系統上雲：挑戰和架構演進的思考》，以下內容爲演講整理。
核心系統上雲之路
工程師時常把我們的系統用飛機來做比喻，乘客則是上面承載的業務。雲也是一架這樣的載客飛機，作爲基礎平臺承載着千萬家企業的業務。今年阿里巴巴實現了核心系統 100% 上雲，這個過程實際上走了幾年才達到今天的進展，而且這還不是結束，也只是阿里巴巴上雲的一個開始。
阿里巴巴集團自身業務體量巨大，支撐其的互聯網技術體系任務也非常繁重，再加上核心電商業務系統的複雜度，對技術帶來的挑戰可想而知。
用王堅博士的話說，核心系統上雲讓阿里巴巴和客戶真正坐上了同一架飛機。從 in-house 的基礎設施、定製化的平臺能力，到通用的雲平臺，從 cloud hosting 到 cloud native，這個過程面臨着巨大的挑戰，同時也是阿里巴巴自身和阿里雲的架構演進升級的歷程。
阿里巴巴的核心交易系統涉及到包括天貓、淘寶、河馬、菜鳥、聚划算、鹹魚、飛豬等一系列業務，其背後的核心電商系統的架構演進經歷了單機房架構、同城雙機房架構再到目前的中心同城容災，三地多單元多活架構。軟件也分爲應用、微服務/中間件和數據庫。
阿里巴巴的上雲步驟一共分爲三個階段：
- 第一階段：在 2015 年之前未上雲，全部採用內部的基礎設施。
- 第二階段：2015 開始，雙11 期間單元化的交易應用開始通過彈性使用雲資源，實現成本節約的目標（注: 圖中上雲單元規模和實際上雲規模不成比例）。
- 第三階段：2018 年的 12 月，CTO 行癲決定阿里巴巴啓動全面上雲，隨後組建了以畢玄爲上雲總架構師的架構組，確定了上雲的方案和步驟。
2019 年經過 1 年的努力，終於在 雙11 前實現了核心系統的全面上雲。這一年核心電商的中心和單元業務，包括數據庫、中間件等組件，實現了全面上雲和使用雲的服務。通過彈性運化，以及離在線混部（圖中未標識）等能力，使大促成本持續下降，到 2018 年，大促新增成本比前一年下降 17%，比早期方案下降 3/4。
這一年核心電商的中心和單元業務，包括數據庫、中間件等組件，實現了全面上雲和使用雲的服務。全面上雲也不只是將機器搬到雲上，更重要的是 replatforming，集團的技術棧和雲產品融合，應用通過神龍服務器+容器和 K8s 上雲，數據庫接入 PolarDB，中間件採用雲中間件和消息產品，負載均衡採用雲 SLB 產品等。
雲已經成爲了基礎設施，無論是電商公司還是其他行業，都可以用雲去做更多事情。
雲化架構
以全面上雲的 2019 年爲例，2019 年 雙11 的實測，集羣的規模超過百萬容器，單容器集羣節點數量過萬，數據庫的峯值超過 54 萬筆每秒，對應 8700 萬查詢每秒，而實時計算每秒峯值處理消息超過 25 億條，消息系統 RocketMQ 峯值處理了超過每秒 1.5 億條消息。
這些數據背後所代表的，就是上雲過程中形成的巨大挑戰。針對這些挑戰，阿里巴巴集團從服務器、存儲、網絡、數據中心等基礎設施方面做了針對性的應對。
1. 自研神龍服務器
核心系統全面上雲決定採用了神龍服務器。神龍服務器自研了 HyperVisor 虛擬化卡來替代軟件虛擬化，從而實現無性能損耗的虛擬化架構。其特點在於：
- 高性能：去掉了虛擬化帶來的 8% 的性能損耗；
- 支持二次虛擬化：使多樣虛擬化技術 (Kata, Firecracker 等) 的探索和創新成爲可能。
在阿里巴巴上雲過程中，雙11 期間壓力測試顯示，高負載壓力下的電商應用，實現 30% 的 QPS 上升，而 rt 也有明顯下降，長尾 rt 下降尤其明顯。同時，雲化的神龍服務器，促進了運維管理的自動化和在線率水平的提升。阿里巴巴認爲，神龍是容器的最佳載體，神龍+服務是無服務器化基礎設施的最佳載體。
存儲方面，走向了全面雲化存儲，也即全面存儲計算分離。
上雲也帶來了大規模使用雲存儲產品：盤古（盤古 2.0），實現了集團業務的更大規模的存儲計算分離。存儲計算分離即業務邏輯執行在計算集羣上面，存儲部署在存儲集羣上面。計算和存儲集羣之間通過高速網絡連接。
隨着數據處理對存儲需求和計算需求在規模、速度、容量和成本等維度的不斷變化，計算與存儲分離可以最大限度地解耦並使這兩類不同的關鍵資源相對獨立地擴展和演進，獲得更好的彈性、資源效率，同時可以讓應用更容易的獲得分佈式存儲的可靠性。
上雲過程中，盤古 2.0 的升級也帶來更好的 io 長尾延遲的穩定性，通過慢盤黑名單、backup read、動態 timeout 等關鍵技術大幅度的改進了長尾延遲。
2. 網絡：高速混合雲
原有的集團安全域，由現有的集團自建網絡爲主體逐漸轉變爲以雲上集團的虛擬網絡爲主體，以 VPC 的方式實現網絡隔離混合雲網絡：爲了實現集團網絡與雲上 VPC 內業務單元的互通，採用了雲專線產品方案，組成了混合雲網絡。雲專線方案中的虛擬網絡網關（xGW 集羣），採用硬件化 HGW 集羣。
3. 數據中心：自建網絡遷移上雲
數據中心自建網絡遷移到 VPC，在上雲過程中，實現了雲 VPC 最大規模提升 4 倍。安全組性能大幅度優化，企業級安全組最大容量提升 25 倍。
在公司內部，各業務自建的網絡之間是相互獨立的。隨着全站雲化，網絡安全域的形態也隨之發生變化，TB 級別的雲上雲下網絡流量對穿，從軟件實現的 XGW 升級到軟硬結合的 HGW，單節點性能提升 20 倍。
另外，值得指出的是，資源、賬號和權限體系對接互通是上雲的重要環節。
上雲架構未來演進：雲原生
上雲已成爲趨勢，但是核心系統上雲只是下一個開始。
企業上雲今天已經成爲廣泛接受的必然趨勢，Rightscale state of the cloud report 2019 顯示，94% 企業已經在使用雲，其中公有云 91%，on prem 70%。
企業的數字化轉型的過程中，利用雲的能力的過程也分爲不同的階段，一般來說也會是走過和阿里上雲類似的過程：首先是彈性使用雲的資源，實現部分業務上雲，Cloud-hosting。在此過程中，一般是非核心繫統使用雲資源。然後涉及到核心系統的雲化，這裏發生的變化不僅僅是上雲的應用的數量，更是底層基礎設施整體使用雲平臺的能力的過程。
在阿里巴巴看來，未來是雲原生化的。
什麼是雲原生？從技術角度講，雲原生技術是一系列的應用構建和運維最佳實踐的集合。雲原生技術的生命力在於它聚焦於給用戶帶來價值，這些價值分爲幾個方面：
-
容器和資源的編排，如 K8s、Container，帶來的運維效率提升，和資源利用率的提升。中心化的編排可以很好的充分編排資源降低企業成本；
-
分佈式系統的可以彈性擴展的能力 Scalability 以及可靠性。儘管互聯網技術發展了幾十年，到今天，分佈式、可擴展、可靠的系統，仍然是很難構建的。也得益於雲原生領域開放技術和雲的快速發展，一切正在變得越來越容易；
-
開放治理和開放的技術，改變了雲廠商和用戶之間的信賴關係，越來越多的企業信賴開放標準的雲服務。同時雲原生也降低了遷雲的成本；
- 雲原生技術所倡導的持續交付，聚焦於企業真正關注的價值，即迭代創新的速度，time to market。
從上雲視角看，雲原生（Cloud native）化是最大化使用雲的能力，使企業聚焦於業務的實踐。
爲什麼這麼說？我們以阿里核心系統演進爲例說明雲原生化和使用雲的能力的關係。
阿里巴巴的應用上雲前仍然存在應用和基礎設施耦合問題，由於採用自建軟件基礎設施，配置管理、發佈升級、監控觀測、流量治理等與業務應用耦合在一起，對於運維效率、研發演進效率和穩定性都帶來了挑戰。
我們在上雲過程中看到，實現標準的雲基礎設施和業務應用的全面解耦，將會帶來全面的研發運維效率提升。
那麼，**使用 in-house 自建基礎設施就一定不行嗎？**
阿里巴巴集團的基礎設施也是由專門的團隊維護的，也在一定意義上實現了基礎設施和應用的解耦。不是所有的 in-house 的基礎設施就不雲原生。事實上，雲原生技術的很多發源地，比如 Google 內部的基礎設施很好地實現了和應用的解耦並帶來了業界領先的研發運維效率。
但是一般來說，由於內部開發容易忽視基礎設施和應用的邊界而實現了過多的非標功能或者傾向於採用更快速落地的方案，這些容易帶來基礎設施和應用的更多耦合，不利於長期的演進和效率。
例如阿里的容器化雖然帶來了應用發佈的標準化的優勢，但是在容器化過程中我們採用了富容器方案加快容器化進程，使容器支持了很多虛擬機使用模式（啓停、原地更新等），帶來了容器的可遷移性比較差，容器運行生命週期可變帶來運維成本等。因此運維效率、穩定性和業務的演進效率，在這種耦合中，都受到了不同程度損失。
所以雲原生化的關鍵路徑，是實現應用和基礎設施的解耦，並且通過採用標準化的雲產品方式來支持。
那麼基礎設施和業務的邊界應該在哪裏？
阿里巴巴認爲邊界是在不斷的變化過程中，真正的判斷標準是業務關注的邊界而非架構邊界，基礎設施應無須業務持續關注和維護。例如，使用了容器服務，是否能讓業務無須關注底層資源？也未必，取決於資源的彈性能力是否有充分的支持（否則業務仍需時刻關注流量和資源壓力），也取決於可觀測性（否則問題的排查仍需關注底層環境）的能力。因此，能夠讓業務無須持續關注的基礎設施本身是一次重要技術演進。
無服務器化的基礎設施，具有以下三個特點：
阿里核心系統的雲原生化演進
阿里巴巴集團的核心繫統的雲原生架構演進，將繼續朝着基礎設施解耦，業務研發運維效率提升，成本下降的整體目標推進。具體來說，圍繞幾個重點的方向工作正在展開：
1. 節點託管的 K8s 服務
實現節點運行環境全託管的標準 K8s 基礎設施，實現資源和節點運行環境解耦：通過全託管的節點計算資源，業務無須管理服務器降低運維成本。今年 雙11 集團實現了上海單元的 ASI 升級，帶來發布擴容效率提升、運行時更穩定容器自愈率提升的效果。未來一年將實現核心系統整體 ASI 化。
2. Service Mesh 化
實現網絡、流量管理配置下沉基礎設施，與應用充分解耦。Mesh 化帶來的價值：
- 軟件基礎設施和業務解耦，各自獨立演進；
- 全鏈路精準流量控制和資源動態隔離；
- 提供對應用透明的雲安全特性（安全特性解耦）。
3. 應用和基礎設施全面解耦
阿里巴巴集團核心系統通過雲原生化，實現應用基礎設施全面解耦，將有效解決此前存在的運維、研發效率及可遷移性、穩定性風險，這也是雲原生帶來的技術賦能。像下圖所表示的，應用的關注對象，從繁雜的基礎設施耦合組件，到只需要關於業務邏輯本身。
4. 應用交付的標準化：OAM
今天應用的交付仍然面臨挑戰：目前雲上進行應用管理，需要面對的是差異性的雲基礎設施能力和多樣化的運行環境, 需要分別對接和管理，如 SLB、日誌、網絡環境、後端依賴等。
今年，阿里雲和微軟雲 Azure 聯合發佈了一個全新的項目，叫做 Open Application Model OAM：開放應用模型。是業界第一個雲原生應用標準定義與架構模型。在這個模型下，應用的開發人員、運維人員和支持 OAM 模型的平臺層，就可以通過一個標準的 OAM 應用描述來進行協作。
通過上雲，最大化的使阿里巴巴的業務使用雲的技術，通過技術架構的演進使業務更好的聚焦於自身的發展而無須關於通用底層技術，使業務研發效率提升，迭代速度更快是技術人的真正目標。正如阿里巴巴集團上雲項目的代號所說的，“雲創未來”，通過技術創造新的價值和機會，通過技術創新帶來更好的未來。
“阿里巴巴雲原生微信公衆號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆號。”