拐點已至，雲原生引領數字化轉型升級

本文整理自易立在 2019 攜程技術峯會上發表的題目爲《拐點已至，雲原生引領數字化轉型升級》的演講。

今天我跟你們分享的題目是「拐點已至，雲原生引領數字化轉型升級」。先作個簡單的自我介紹，我叫易立，來自於阿里雲容器平臺，從 2015 年開始負責阿里雲容器產品，以前在 IBM 工做 14 年，主要負責企業中間件和雲計算的產品研發。

今天會跟你們分享咱們對雲原生領域的簡單思考，以及咱們對雲原生髮展四個趨勢大概的介紹：

• 擁抱 Serverless – 極致彈性，無需運維；
• 服務網格 – 將服務治理能力與應用解耦，並下沉到基礎設施層；
• 雲原生應用管理標準化 – 構建高效、自動化和可信賴的應用交付體系；
• 計算無邊界 – 實現雲-邊緣-IoT 設備的高效協同。

雲原生基本概念

先簡單介紹雲原生一些基本的概念。

咱們接觸了不少的客戶，對於這些客戶而言，上不上雲已經不是問題，他們關注的是該怎麼上雲？該如何充分利用雲的能力、最大化雲的價值？在 All in Cloud 的時代，企業的技術能力已經成爲核心競爭力，他們很是願意用雲做爲企業 IT 能力的增效器。

雲原生計算是一組最佳實踐和方法論，在公共雲、專有云環境中，構建可伸縮、健壯、鬆耦合的應用，能夠更加快速地創新和低成本試錯；容器、服務網格、無服務計算等新的計算範型不斷涌現。

容器掀開了雲原生技術的序幕：

• Docker 鏡像造成了應用分發和交付的標準，能夠將應用與底層運行環境實現解耦；
• Kubernetes 技術成爲了分佈式資源調度和編排的標準，Kubernetes 屏蔽了底層基礎架構的差別，幫助應用運行在不一樣的基礎設施之中；
• 在此基礎之上，社區開始創建上層的應用抽象。好比服務治理層，Istio 成爲了服務通訊的網絡協議棧，將服務治理能力與應用層實現解耦。

在此之上，面向領域的雲原生框架也在迅速出現，好比面向機器學習的雲原平生臺 Kubeflow 和麪向無服務器的 Knative 等等。經過這樣的架構分層，開發者只需關注自身的業務邏輯，而無需關注底層實現的複雜性。

咱們能夠看到一個雲原生操做系統的雛形開始出現，這是開發者最好的時代，極大地提高了業務創新的速度。

在早期，Kubernetes上主要運行無狀態的 Web 應用，好比基於 Apache Dubbo/Spring Cloud 的微服務應用。而如今，愈來愈多的企業核心業務、數據智能業務以及創新業務也運行在 Kubernetes 之上。

以阿里雲自身的雲產品舉例，如企業級分佈式應用服務 EDAS、實時計算平臺 Flink、彈性 AI 算法服務 EAS 以及區塊鏈平臺 BaaS 也部署在阿里雲 Kubernetes 服務 ACK 之上。

K8s 已經成爲雲時代操做系統，成爲應用使用雲基礎設施能力的界面。阿里雲 ACK 實現了對雲基礎設施的優化集成，提供敏捷、彈性和可移植的雲原生應用平臺；並且能夠在公共雲、專有云、邊緣雲上實現一致的應用部署和管理。

從容器到無服務器

Serverless Kubernetes

下面咱們來談一下，Kubernetes 的 Serverless 進化。

全部人都喜歡 K8s 提供的強大和靈活，可是運維一個 Kubernetes 生產集羣極具挑戰。

阿里雲的 Kubernetes 服務 ACK 簡化了 K8s 集羣的生命週期管理，託管了集羣的 master 節點被，可是用戶依然要保有 worker 節點資源池，還須要維護節點，好比進行升級安全補丁等，並根據本身的使用狀況對資源層進行容量規劃。

針對 K8s 的運維複雜性挑戰，阿里雲推出了 Serverless Kubernetes 容器服務 ASK，徹底兼容現有 K8s 容器應用，可是全部容器基礎設施被阿里雲託管，用戶能夠專一於本身的應用。它具有幾個特色：

• 首先用戶沒有任何預留資源，按照容器應用實際消耗的資源付費；
• 對用戶而言沒有節點的概念，零維護；
• 全部資源按需建立，無需任何容量規劃。

Serverless Kubernetes 極大下降了運維複雜性，並且其自身設計很是適合突發類應用負載，如 CI/CD，批量計算等等。好比一個典型的在線教育客戶，根據教學須要按需部署教學應用，課程結束自動釋放資源，總體計算成本只有使用包月節點的 1/3。

雲規模的 Nodeless 架構 —— Viking

它是怎麼實現的呢？ 在 2017 年末，咱們啓動 Serverless Kubernetes 項目的時候，就一直在思考：若是 Kubernetes 天生長在雲上，它的架構應該如何設計？咱們爲它內部的產品代號爲 Viking，由於古代維京戰船以迅捷和便於操做而著稱。

首先，咱們但願兼容 Kubernetes。用戶能夠直接使用 Kubernetes 的聲明式 API，兼容 Kubernetes 的應用定義，Deployment, StatefulSet, Job, Service 等無需修改。

其次 Kubernetes 底層儘量充分利用雲基礎設施服務的能力和雲服務來實現，好比計算、存儲、網絡、資源的調度等；根本性簡化容器平臺的設計，提高規模，下降用戶運維複雜性。咱們聽從 Kubernetes 控制器設計模式，驅動整個 IaaS 資源狀態不斷地向用戶應用聲明的狀態逼近。

咱們在資源層提供了彈性容器實例 - ECI。與 Azure Container Instance ACI, AWS Fargate 不一樣，ECI 提供 Kubernetes Pod 的原生支持而不是提供單獨 container 實例。ECI 基於輕量虛擬機提供了沙箱環境實現安全隔離，徹底兼容 Pod 的語義、支持多容器進程、健康檢查、啓動順序等能力。這樣使得上層構建 K8s 兼容層，變得很是簡單直接。

在編排調度層，咱們使用了微軟的 Virtual-Kubelet，並對其進行了深度擴展。Virtual-Kubelet 提供了一個抽象的控制器模型來模擬一個 Kubernetes 節點。當一個 Pod 被調度到虛擬節點上，控制器會利用 ECI 服務建立一個 ECI 實例來運行 Pod。同時控制器支持雙向狀態同步，若是一個運行中的 ECI 實例被刪除，控制器會根據應用目標狀態從新恢復一個新的 ECI 實例。

同時咱們基於阿里雲的雲服務實現了 Kube-Proxy、Kube-DNS、Ingress Controller 的行爲，提供了完整的 Kubernetes Service 能力支持：

• 好比利用阿里雲的 DNS 服務 PrivateZone，爲 ECI 實例動態配置 DNS 地址解析，支持了 Headless Service；
• 經過內網 SLB 提供了 Cluster IP，提供負載均衡能力；
• 經過 SLB 提供的 7 層路由來實現 Ingress 的路由規則。

咱們也爲 ECI 提供了端到端可觀測性能力，並與阿里雲日誌服務，雲監控等服務進行了深度集成，也能夠輕鬆支持 HPA 水平擴容。

容器啓動加速——「零秒」鏡像下載

對於 Serverless 容器技術而言，應用啓動速度是一個核心指標。容器對應用啓動速度的影響主要在於：

• 資源的準備：經過端到端管控鏈路的優化和針對容器場景虛擬化和操做系統的剪裁和優化，ECI 能夠將資源準備時間優化到秒級；
• 鏡像下載時間：從 Docker 鏡像倉庫下載鏡像並在本地解壓縮是一個很是耗時的操做。下載時間取決於鏡像大小，一般在 30 秒到數分鐘不等。

在傳統 Kubernetes 中， worker 節點會在本地緩存已下載過的鏡像，這樣下次啓動不會重複下載和解壓。爲了實現極致彈性成本效率，ECI 和 ECS 採用並池的策略，計算存儲分離的架構，這也意味着咱們不可能經過傳統方式利用本地盤來作容器鏡像的緩存。

爲此咱們實現了一個創新的方案：能夠將容器鏡像製做成一個數據盤快照。

當 ECI 啓動時，若是鏡像快照存在，能夠直接基於快照建立一個只讀數據盤，並隨着實例啓動自動掛載，容器應用直接利用掛載數據盤做爲 rootfs 進行啓動。基於盤古 2.0 架構和阿里雲 ESSD 雲盤的極致 I/O 性能，咱們能夠將鏡像加載的時間縮小到 1 秒之內。

爲了簡化用戶操做，咱們在 K8s 中提供了 CRD 可讓用戶指明哪些鏡像須要構建鏡像快照。同時，在 ACR 鏡像倉庫服務的軟件交付流水線上，咱們能夠聲明哪些鏡像須要進行加速，這樣當用戶推送一個新鏡像時，就會自動構建相應的快照緩存。

極致彈性

下面談彈性，對於絕大多數的企業來說，彈性是上雲最重要的一個訴求，雙 11 就是一個典型的脈衝式計算，峯值計算資源會是平時的不少倍。也有不可預期的峯值發生，好比一個爆款遊戲大熱以後，就須要迅速地在雲上擴容。Kubernetes 能夠將雲的彈性能力發揮到極致。

ACK 在資源層和應用層提供了豐富的彈性策略，在資源層目前主流的方案是經過 cluster-autoscaler 進行節點的水平伸縮。當出現 Pod 因爲資源不足形成沒法調度時，cluster-autoscaler 會選擇一個伸縮組中，並自動向組內加入實例。

在彈性伸縮組中，咱們能夠根據應用負載需求選擇 ECS 虛擬機，神龍裸金屬和 GPU 實例進行擴容。值得一提的是 Spot instance，競價實例能夠利用阿里雲的空閒計算資源，成本折扣能夠低至按量付費實例的 90%。

競價實例很是適合無狀態和容錯性好的應用，好比批量數據處理或者視頻渲染等，能夠大大下降計算成本。基於阿里雲強大的彈性計算能力，咱們能夠在分鐘級實現千節點伸縮。

進一步結合上文提到的 ECI，咱們能夠在 ACK 中基於虛擬節點實現彈性伸縮。virtual-kubelet 能夠註冊爲一個虛擬節點，理論上擁有無限大的容量。當 Pod 調度到虛擬節點上時，會利用 ECI 動態建立 Pod，這很是適合大數據離線任務、CI/CD 做業、突發型在線負載等。在一個大型客戶的生產環境中，彈性容器實例能夠在 30 秒內啓動 500 Pod，輕鬆應對突發的請求峯值。

在應用層，Kubernetes 提供了 HPA 的方式進行 Pod 的水平伸縮，和 VPA 進行 Pod 的垂直伸縮。阿里雲提供了 alibaba-cloud-metrics-adapter，能夠提供更加豐富的彈性指標，好比能夠根據 Ingress Gateway 的 QPS 指標、雲監控的指標，動態調整應用 Pod 數量。

另外對不少行業客戶而言，應用負載的資源畫像是具備週期性的。好比，咱們一個證券行業的客戶，每週一到週五，股市開盤時間是交易時間，而其餘的時間，只能查詢不提供交易，峯谷資源需求量高達 20 倍以上的差別。

爲了解決這個場景，阿里雲容器服務提供了定時伸縮組件，專門應對資源畫像存在週期性的場景 ，開發者能夠定義 time schedule，提早擴容好資源，而在波谷到來後定時回收資源；結合底層 cluster-autoscaler 的節點伸縮能力，很好平衡了系統的穩定性和資源成本的節約。

將來咱們會發布一些基於機器學習的彈性伸縮策略，能夠根據歷史資源畫像，實現更好地資源預測，提高彈性的 SLA。

賦能下一代無服務器應用

上文說到了爲何 Serverless 受到愈來愈多開發者的歡迎，由於你們更關注本身的業務，而不是基礎設施的維護。Serverless 化是雲服務發展的必然趨勢，咱們須要將資源調度，系統運維等能力下沉到基礎設施。Google, IBM，CloudFoundry 等共同推出了 Knative 做爲 Serverless 編排框架，能夠很是簡潔、高效地實現無服務器化應用。它提供了幾個核心能力：

• Eventing - 提供了事件驅動的處理模型，咱們針對阿里雲，擴展了豐富的事件源，好比當 OSS 接收到用戶上傳的一個視頻片斷，觸發容器中的應用進行視頻轉碼；
• Serving- 提供了靈活的服務響應能力，能夠根據業務的請求量自動彈性伸縮，甚至支持縮容到零，利用阿里雲彈性基礎設施，能夠大大下降資源成本；
• Tekton - 能夠輕鬆實現從代碼到應用部署的自動化流水線。

結合應用管理能力和應用性能監控服務, 咱們能夠基於 Knative 快速搭建具有領域特點的應用託管服務 (Micro PaaS)，大大下降直接操做 Kubernetes 資源的複雜度，讓開發者更加專一於應用迭代和服務交付效率提高。

安全沙箱容器技術進化

剛纔談完了編程模型，看一下底層實現，全部的 Serverless下面核心實現就是安全容器沙箱。傳統的 Docker RunC 容器與宿主機 Linux 共享內核，經過 CGroup 和 namespace 實現資源隔離。這種方式很是高效，可是因爲操做系統內核的攻擊面比較大，一旦惡意容器利用內核漏洞，能夠影響整個宿主機上全部的容器。

愈來愈多企業客戶關注容器的安全性，爲了提高安全隔離，阿里雲和螞蟻金服團隊合做，引入安全沙箱容器技術。今年 9 月份咱們發佈了基於輕量虛擬化技術的 RunV 安全沙箱。相比於 RunC 容器，每一個 RunV 容器具備獨立內核，即便容器所屬內核被攻破，也不會影響其餘容器，很是適合運行來自第三方不可信應用或者在多租戶場景下進行更好的安全隔離。

通過性能優化，安全沙箱容器如今能夠達到 90% 的原生 RunC 性能，而且 RunV 容器提供了和 RunC 容器徹底一致的用戶體驗，包括日誌、監控、彈性等。同時，ACK 能夠在一臺神龍裸金屬實例上同時混布 RunC 和 RunV 容器，用戶能夠根據本身的業務特性自主選擇。

在財年年末，咱們會推出基於 Intel SGX 可信計算技術的可信容器沙箱 RunE。容器應用運行在 CPU 中被稱爲 enclave 的安全可信執行環境中。一個比喻：咱們把容器放進了保險箱，任何人，包括雲服務供應商，都沒法從外部篡改和截獲之中數據。客戶能夠將高機密應用，好比祕鑰的加簽、驗籤，隱私數據處理等邏輯運行在 RunE 容器中。

從微服務到服務網格

下面談另一個方面——微服務架構的演化。 互聯網應用架構催生了微服務架構的發展。它的核心思想是經過應用功能拆分，將複雜應用拆解爲一組鬆耦合服務，每一個服務遵照單一責任原則（Single Responsibility Principle）。每一個服務能夠獨立部署和交付，大大提高了業務敏捷性；每一個服務能夠獨立橫向擴展/收縮，應對互聯網規模的挑戰。

服務治理能力下沉

微服務框架，好比 HSF/Dubbo 或 Spring Cloud，都提供了強大的服務治理能力，好比服務發現、負載均衡、熔斷降級等。這些服務治理能力以 Fat SDK 的方式與應用程序構建在一塊兒，隨着應用一塊兒發佈和維護，服務治理能力與業務邏輯的生命週期耦合在一塊兒。

微服務框架的升級會致使整個應用的從新構建和部署。此外因爲 Fat SDK 一般與特定語言所綁定，難以支持企業應用的多語言（polyglot）實現。

爲了解決上述挑戰，社區提出了 Service Mesh（服務網格）架構。它將服務治理能力下沉到基礎設施，經過一個獨立的 Sidecar 進程來提供服務治理能力，而應用側只保留協議的編解碼便可。從而實現了服務治理與業務邏輯的解耦，兩者能夠獨立演進不相互干擾，提高了總體架構的靈活性；同時服務網格架構減小了對業務邏輯的侵入性，下降了多語言支持的複雜性。

服務網格

在阿里巴巴經濟體內部，咱們已經開始大規模應用服務網格技術，來提供多語言支持，下降業務對接門檻；提供統一架構模式，提高技術迭代速度。以 Istio 爲表明的服務網格技術具備光明的前途，可是大規模生產落地時仍然存在很是多的挑戰。

• 首先是 Istio 服務網格技術自身的複雜性；

• 其次是規模化帶來的穩定性和性能的挑戰：

  • 在海量服務的狀況下，控制平面是否能夠支持服務配置的高效分發？
  • 數據平面是否能夠儘量下降增長兩跳後的通訊延遲？
  • 下沉可觀測性和策略管理能力到數據平面，避免集中化 Mixer 引入的性能瓶頸等。
• 最後是和現有的微服務架構兼容並存，支持現有微服務的統一配置管理服務和通訊協議。

爲了解決上述挑戰，阿里巴巴和螞蟻金服與 Istio 社區兼容的技術體系上，構建了服務網格能力。在今年 618，螞蟻金服已經完成核心繫統上到 SOFAMosn 的驗證工做，剛剛結束的雙 11，阿里巴巴和螞蟻金服在覈心繫統大規模上線了 Service Mesh。

同時阿里巴巴經濟體會把自身技術演進的結果及時反饋到上游去，與社區共同推動 Service Mesh 發展。好比在阿里巴巴開源的服務發現與配置管理項目 Nacos 最新版本中，就提供了 Istio 對 MCP 協議支持。 晚些時候，阿里雲會推出託管 Service Mesh 服務，幫助雲上的開發者可以便捷地使用服務網格技術。

聚焦應用生命週期

另一個關注的焦點是應用生命週期的自動化、標準化。咱們知道 Kubernetes 的定位是 Platform for Platform，幫助企業實現自動化應用運維、管理。

Kubernetes 爲分佈式應用管理提供了不少基礎的元語抽象，好比面向無狀態應用的 Deployment 和麪向有狀態應用的 StatefulSet。可是在企業生產環境中，面對應用的不一樣需求，現有能力還存在一些不足。參加技術分享咱們常常會聽到每一個企業都在談如何修改 K8s 來解決本身的問題，這裏面不少問題都是類似的。

OpenKruise

做爲雲原生技術的引領者，阿里巴巴將咱們在雲原生計算技術上大規模生產的最佳實踐沉澱下來，以開源項目 OpenKruise 的方式與社區開放、共建。

• 一方面幫助企業客戶在雲原生的探索的過程當中，少走彎路，減小技術碎片；
• 一方面推進上游技術社區，逐漸完善和豐富 Kubernetes 的應用週期自動化能力。

以以下幾個新的控制器爲例：

• Broadcast Job：可讓一次性任務運行在機器上指定的節點，好比咱們要在節點上安裝安全補丁，或者在節點上預先下載一個容器鏡像；
• Sidecar Set：愈來愈多的運維能力以 Sidecare 方式提供，好比日誌、監控、和服務網格中的數據平面組件 Envoy。咱們能夠經過 Sidecar Set 以聲明式方法管理 Sidecar的生命週期；
• Advanced StatefulSet: 支持原地發佈和批量升級，讓你們在更加簡單地支持有狀態服務。

這些控制器解決了不少客戶的真實痛點。

OAM-首個開放應用模型

在 11 月 16 日，微軟和阿里雲共同發佈了 Open Application Model（OAM），但願可以創建起一個標準化的雲原生應用模型，幫助開發者、應用運維和基礎設施運維團隊，進行更加高效的協同。

它採用的關注點設計標準包括不一樣的維度，開發者負責定義應用的組件、依賴與架構；應用運維人員負責定義應用運行時配置與運維需求，好比發佈策略和監控指標，而基礎架構運維團隊能夠針對應用部署環境的不一樣，配置定製化參數。

經過這種關注點分離（Separation of Concerns）的設計，能夠將應用定義、運維能力與基礎設施實現解構。讓應用交付變得更加高效、可靠和自動化。

計算無邊界

最後一個方面，咱們來說一下對將來無邊界雲計算的思考。 隨着 5G 時代的臨近，低延遲網絡、AI 硬件算力提高和智能化應用快速發展，一個萬物智聯的時代必將到來，將計算能力從雲延展到到邊緣側、設備側，並經過雲進行統一應用交付、資源管控，將會是雲計算髮展的必然趨勢。

雲邊端一體協同

基於容器，咱們創建了雲邊端一體協同平臺 —— ACK@Edge。這樣咱們能夠將一些須要低延遲處理的應用部署在邊緣節點實現就近訪問。好比，咱們能夠把 AI 模型預測和實時數據處理放置到邊緣，進行實時智能決策，而將模型訓練，大數據處理等須要海量算力應用放到雲端。

ACK 邊緣版提供了統一管控能力，在 K8s 集羣中能夠同時支持雲端 ECS、邊緣 ENS 節點以及 IoT 設備。而且針對邊緣的特殊性，提供了單元化隔離和斷連自治、自愈能力。咱們已經在阿里雲視頻雲、優酷等場景中開始大規模應用。

優酷筋斗雲

咱們以優酷筋斗雲爲例介紹其計算架構演進。

優酷是國內最大的視頻平臺，隨着優酷業務的快速發展，須要將原來部署在若干 IDC 內的集中式架構，演進到雲+邊緣計算的架構。這時候須要一種方式來統一管理阿里雲十幾個 region 和衆多的邊緣節點。

優酷選擇了 ACK@Edge，能夠統一管理雲與邊緣的節點，並實現了統一的應用發佈和彈性擴縮容。經過彈性能力，節省了機器成本 50%。採用新的架構以後，用戶終端能夠就近訪問邊緣節點，讓端到端網絡延遲下降了 75%。

源於社區，回饋開源

最後，雲原生技術源自於社區的共同的建設。阿里巴巴做爲雲原生的實踐者和引領者，全面擁抱雲原生技術，並將咱們在大規模生產最佳實踐回饋到社區，與社區共同建設更加美好的雲原生技術生態。

---

本文做者： 易立

原文連接

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