堅持探索與落地並重，阿里巴巴雲原生之路全景揭祕

阿里妹導讀：阿里雲已經成功地規模化落地雲原生，26日的 KubeCon 大會上，CNCF TOC 和阿里雲資深技術專家李響發表主題演講，分享了阿里巴巴在規模擴展、可靠性、開發效率、遷移策略等方面的經驗，並探討雲原生的落地及應對若干技術挑戰。

爲何要作雲原生？雲原生究竟能帶來什麼價值？從最初的獨自摸索到現在擁抱開源回饋社區，阿里巴巴走過了怎樣的雲原生旅程？又有哪些技術心得？今天，將所有分享出來。

多年沉澱，堅持探索與落地並重

阿里巴巴從2011年開始經過容器實踐雲原生技術體系，在整個業界都尚未任何範例可供參考的大背境下，逐漸摸索出了一套比肩全球一線技術公司而且服務於整個阿里集團的容器化基礎設施架構。這個探索歷程雖然孤獨，但卻被始終如一的堅持至今。這正是在這個背注一擲的技術探索與奮進的過程當中，阿里巴巴的技術團隊完整的經歷了雲原生技術浪潮裏的全部關鍵節點，不只成爲了此次技術革命的重要見證者，也逐漸成爲中國雲原生技術體系當之無愧的推進者與引領者之一。

阿里的體量大、業務複雜，推進雲原生要找到合適的切入點。在雙十一成本壓力的推進下，資源成本與效率優化成了阿里雲原生的起點。

阿里從容器入手，研究低成本虛擬化與調度技術：提供靈活、標準的部署單元；將靜態資源分配更換爲動態按需調度，進一步提高部署效率，解決資源碎片化問題，提升部署密度；經過存儲網絡虛擬化和存儲計算分離等技術，加強任務的可遷移性，進一步提升了資源的可靠性，下降了資源成本。

在資源成本的推進下，阿里完成了全面容器化，資源分配也被高效調度平臺接管。阿里的雲原生並未止步於此。提升研發效率與加快迭代週期是推進阿里業務加強的祕密武器。阿里但願經過雲原生讓開發者效率更高。

爲了下降應用部署難度，提升部署自動化程度，阿里開始採用 Kubernetes 做爲容器編排平臺，而且持續推進 Kubernetes 的性能與可擴展性。具體 Kubernetes，阿里持續對研發、部署流程進行改進。爲了構建更雲原生化的 CI/CD，進一步作到標準化和自動化，從研發到上線流程，阿里引入了諸如 Helm 的應用標準化管理，也嘗試了 GitOps 這樣的部署流程，還推進了 PaaS 層的面向終態自動化改造。於此同時，阿里也開始探索服務網格，致力於進一步提升服務治理的普適性與標準性，下降開發者採用門檻，進一步推進微服務在多語言和多環境下的普及。

今年，阿里也展開了全站上雲。通過雲原生的探索與改造，阿里基礎架構體系是現代化和標準化的。利用容器技術，應用與宿主機運行時完成了解耦；利用 Kubernetes 對 Pod 與 Volume 等的抽象，完成了對多種資源實現的統一化；經過智能調度與 PaaS 平臺，讓自動遷移應用，修復不穩定因素成爲了可能，阿里經過雲原生技術大大下降了上雲的難度。

在這個提升資源和人員效率的過程當中，阿里巴巴的整個基礎設施也變得更加開放，連通開源生態，在交流互動中不斷吸取和貢獻好的理念、技術、思想。現在，阿里雲不只支撐着中國最大的雲原生應用雙11，並且擁有國內最大的公共雲集羣和鏡像倉庫。做爲惟一入選 Gartner 的公有云容器服務競爭格局的廠商，阿里雲也積累了最爲豐富和寶貴的客戶實踐。

追求極致，優化擴展性和規模性

彈性和規模性，這是支撐阿里巴巴各類類型的複雜場景以及流量高峯的關鍵因素。

通過不斷打磨，阿里巴巴在 Kubernetes 規模與性能上取得了顯著的成果：將存儲object 的數量提高25倍，支持的節點數從5000提高到上萬，在端到端調度延遲從5s變爲100ms等等。其中有很多工做在阿里巴巴和社區中共同開展，而這些研發成果都已經貢獻給社區，咱們指望其餘企業及開發者也能夠享受阿里巴巴規模所帶來的技術紅利。

阿里巴巴持續優化性能，能夠分爲如下四個維度：工做負載追蹤、性能分析、定製化調度、大規模鏡像分發。首先對工做負載調度有完整的追蹤、重放機制，其次將全部性能問題的進行細緻分析，逐一攻克技術瓶頸。Kubernetes 自己的可定製性很強，阿里巴巴針對自身業務場景沉澱了定製化的調度能力和鏡像分發系統。開源Dragonfly 項目脫胎於雙十一，具有極強的鏡像分發能力。數十個超級集羣，每一個超級集羣具備數萬節點，數百萬的容器。

阿里巴巴落地 Kubernetes 能夠分爲三個階段：首先經過 Kubernetes 提供資源供給，可是不過多幹擾運維流程，這系統容器是富容器，將鏡像標準化與輕量級虛擬化能力帶給了上面的 PaaS 平臺。第二步，經過 Kubernetes controller 的形式改造PaaS 平臺的運維流程，給 PaaS 帶來更強的面向終態的自動化能力。最後把運行環境等傳統重模式改爲原生容器與 pod 的輕量模式，同時將 PaaS 能力徹底移交給Kubernetes controller，從而造成一個徹底雲原生的架構體系。

如何解決雲原生的關鍵難點

阿里巴巴雲原生的探索，起步於自研容器和調度系統，到現在擁抱開源的標準化技術。對於當下開發者的建議是：若是想構建雲原生架構，建議直接從 Kubernetes 入手便可。一方面，Kubernetes 爲平臺建設者而生，已經成爲雲原生生態的中流砥柱，它不只向下屏蔽了底層細節，並且向上支撐各類周邊業務生態；另外一方面，更重要的是社區中有着愈來愈多圍繞 Kubernetes 構建的開源項目，好比Service Mesh、Kubeflow。

那麼做爲過來人，阿里有哪些「避坑指南」呢？

雲原生技術架構演進中最爲艱難的挑戰，其實來自於 Kubernetes 自己的管理。由於 Kubernetes 相對年輕，其自身的運維管理系統生態尚不完善。對於阿里而言，數以萬計的集羣管理相當重要，咱們探索並總結了四個方法：Kubernetes on Kubernetes，利用 K8s 來管理 K8s 自身；節點發布回滾策略，按規則要求灰度發佈；將環境進行鏡像切分，分爲模擬環境和生產環境；而且在監控側下足功夫，將Kubernetes 變得更白盒化和透明化，及早發現問題、預防問題、解決問題。

另一個關鍵技術問題是 Kubernetes 的多租戶管理。相比於 namespace 擴展性差和命名衝突等限制，能夠在 Kubernetes 之上創建虛擬集羣。在提升擴展性的同時，可以作到 API 層面的強隔離，經過 syncer 連接虛擬集羣和真實集羣，在 node添加 agent，達到更好的多租管理和更好的利用。

這次 KubeCon 大會上，阿里雲重磅公佈了兩個項目：Cloud Native App Hub —— 面向全部開發者的 Kubernetes 應用管理中心，OpenKruise —— 源自全球頂級互聯網場景的 Kubernetes 自動化開源項目集。

雲原生應用中心（Cloud Native App Hub），能夠簡單理解爲 Helm 應用中國鏡像站，方便用戶得到應用資源，並大大簡化了 Kubernetes 部署安裝一個應用的步驟；OpenKruise/Kruise 項目致力於成爲「雲原生應用自動化引擎」，解決大規模應用場景下的諸多運維痛點。此次沙龍首秀，開發者們體驗了從雲原生應用中心快速下載應用，並經過帶狀態pod 原地升級、sidecar 容器注入、節點鏡像預熱等三個場景，實際體驗了 Kruise 強大的自動化運維能力。

值得一提的是，OpenKruise 項目源自於阿里巴巴經濟體過去多年的大規模應用部署、發佈與管理的最佳實踐；源於容器平臺團隊對集團應用規模化運維，規模化建站的能力；源於阿里雲 Kubernetes 服務數千客戶的需求沉澱。從不一樣維度解決了 Kubernetes 之上應用的自動化問題，包括部署、升級、彈性擴縮容、QoS 調節、健康檢查，遷移修復等等。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。