雲原生引領數字化轉型更新

今天我跟大家分享的題目是“拐點已至，雲原生引領數字化轉型更新”。先做個簡單的自我介紹，我叫易立，來自于阿裡雲容器平台，從 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 硬體算力提升和智能化應用快速發展，一個萬物智聯的時代必将到來，将計算能力從雲延展到到邊緣側、裝置側，并通過雲進行統一應用傳遞、資源管控，将會是雲計算發展的必然趨勢。

雲邊端一體協同

基于容器，我們建立了雲邊端一體協同平台 —— [email protected]。這樣我們可以将一些需要低延遲處理的應用部署在邊緣節點實作就近通路。比如，我們可以把 AI 模型預測和實時資料處理放置到邊緣，進行實時智能決策，而将模型訓練，大資料處理等需要海量算力應用放到雲端。

ACK 邊緣版提供了統一管控能力，在 K8s 叢集中可以同時支援雲端 ECS、邊緣 ENS 節點以及 IoT 裝置。并且針對邊緣的特殊性，提供了單元化隔離和斷連自治、自愈能力。我們已經在阿裡雲視訊雲、優酷等場景中開始大規模應用。

優酷筋鬥雲

我們以優酷筋鬥雲為例介紹其計算架構演進。

優酷是國内最大的視訊平台，随着優酷業務的快速發展，需要将原來部署在若幹 IDC 内的集中式架構，演進到雲+邊緣計算的架構。這時候需要一種方式來統一管理阿裡雲十幾個 region 和衆多的邊緣節點。

優酷選擇了 [email protected]，可以統一管理雲與邊緣的節點，并實作了統一的應用釋出和彈性擴縮容。通過彈性能力，節省了機器成本 50%。采用新的架構之後，使用者終端可以就近通路邊緣節點，讓端到端網絡延遲降低了 75%。

源于社群，回饋開源

最後，雲原生技術源自于社群的共同的建設。阿裡巴巴作為雲原生的實踐者和引領者，全面擁抱雲原生技術，并将我們在大規模生産最佳實踐回饋到社群，與社群共同建設更加美好的雲原生技術生态。