本周六在攜程技術大會上分享了一篇 “拐點已至，雲原生引領數字化轉型更新”的演講，整理記錄如下。
- 擁抱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實作了對雲基礎設施的優化內建，提供了現靈活、彈性和可移植的雲原生應用平台。
下面我們來談一下，Kubernetes的Serverless進化。所有人都喜歡K8s提供的強大和靈活，但是運維一個Kubernetes生産叢集極具挑戰。
阿裡雲的Kubernetes服務ACK簡化了K8s叢集的生命周期管理，托管了叢集的master節點被，但是使用者依然要保有worker節點資源池，還需要維護節點，比如進行更新安全更新檔等，并根據自己的使用情況對資源層進行容量規劃。
針對K8s的運維複雜性挑戰，阿裡雲推出了Serverless Kubernetes容器服務 ASK，完全相容現有K8s容器應用，但是所有容器基礎設施被阿裡雲托管，使用者可以專注于自己的應用。它具備幾個特點：
- 首先使用者沒有任何預留資源，按照容器應用實際消耗的資源付費
- 對使用者而言沒有節點的概念，零維護
- 所有資源按需建立，無需任何容量規劃。
Serverless Kubernetes極大降低了運維複雜性，而且其自身設計非常适合突發類應用負載，如CI/CD，批量計算等等。比如一個典型的線上教育客戶，根據教學需要按需部署教學應用，課程結束自動釋放資源，整體計算成本隻有使用包月節點的 1/3。
在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鏡像倉庫服務的軟體傳遞流水線上，我們可以聲明哪些鏡像需要進行加速。這樣當使用者推送一個新鏡像時，就會自動建構相應的快照緩存。
彈性是雲最核心的能力之一，像雙十一這樣的典型脈沖應用場景，或者像爆款遊戲背後都需要雲提供的強大算力來支撐，而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數量。
另外對很多行業客戶而言，應用負載的資源畫像是具有周期性的。比如，我們一個證券行業的客戶，每周一到周五，上午9:30-11:30，下午13:00-15:00為交易時間。其他的時間，隻能查詢不提供交易。峰谷資源需求量高達20倍以上的差異，為了解決這個場景，阿裡雲容器服務提供了定時伸縮元件，專門應對資源畫像存在周期性的場景 ，開發者可以定義 time schedule，提前擴容好資源，而在波谷到來後定時回收資源；。結合底層 cluster-autoscaler 的節點伸縮能力，很好平衡了系統的穩定性和資源成本的節約。
未來我們會釋出一些基于機器學習的彈性伸縮政策，可以根據曆史資源畫像，實作更好地資源預測，提升彈性的SLA。
Serverless化是雲服務發展的必然趨勢，讓業務應用更加關注自己業務邏輯，而将資源排程，系統運維的能力下沉到基礎設施。
Google, IBM，CloudFoundry等共同推出了Knative作為Serverless 編排架構，可以非常簡潔、高效地實作無伺服器化應用。它提供了幾個核心能力
- Eventing - 提供了事件驅動的處理模型，我們針對阿裡雲，擴充了豐富的事件源，比如當OSS接收到使用者上傳的一個視訊片段，觸發容器中的應用進行視訊轉碼。
- Serving- 提供了靈活的服務響應能力，可以根據業務的請求量自動彈性伸縮，甚至支援縮容到零。利用阿裡雲彈性基礎設施，可以大大降低資源成本。
- Tekton - 可以輕松實作從代碼到應用部署的自動化流水線，
結合應用管理能力和應用性能監控服務, 我們可以基于Knative快速地搭建具備領域特色的應用托管服務 (Micro PaaS)，大大降低直接操作 Kubernetes 資源的複雜度，讓開發者更加專注于應用疊代和服務傳遞效率提升。
傳統的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服務網格技術自身的複雜性
- 其次是規模化帶來的穩定性和性能的挑戰挑戰：在海量的服務的情況下，控制平面是否可以支援服務配置的高效分發；資料平面是否可以盡可能降低增加兩跳後的通信延遲；下沉可觀測性和政策管理能力到資料平面，避免集中化Mixer引入的性能瓶頸等。
- 最後是和現有的微服務架構相容并存，支援現有微服務的統一配置管理服務和通信協定。
為了解決上述挑戰，阿裡巴巴和螞蟻金服與Istio社群相容的技術體系上，建構了服務網格能力。在今年 618 螞蟻金服已經完成核心系統上到 SOFAMosn 的驗證工作，在馬上來臨的今年的雙 11，阿裡巴巴和螞蟻金服将會在核心系統大規模上線 Service Mesh。同時阿裡經濟體會把自身技術演進的結果及時回報到上遊去，與社群共同推進Service Mesh發展。比如在阿裡開源的服務發現與配置管理項目Nacos最新版本中，就提供了Istio對 MCP協定支援。
晚些時候，阿裡雲會推出托管 Service Mesh 服務，幫助雲上的開發者能夠便捷地使用服務網格技術。
Kubernetes為分布式應用管理提供了很多基礎的元語抽象，比如面向無狀态應用的Deployment和面向有狀态應用的StatefulSet。但是在企業生産環境中，面對應用的不同需求，現有能力還存在一些不足。參加技術分享我們經常會聽到每個企業都在談如何修改K8s來解決自己的問題，這裡面很多問題都是相似的。
作為雲原生技術的引領者，阿裡巴巴将我們在雲原生計算技術上大規模生産的最佳實踐沉澱下來，以開源項目OpenKruise的方式與社群開放、共建。一方面幫助企業客戶在雲原生的探索的過程中，少走彎路，減少技術碎片；一方面推動上遊技術社群，逐漸完善和豐富Kubernetes的應用周期自動化能力
比如，以如下幾個新的控制器為例
- Broadcast Job，可以讓任務運作在機器上指定的節點，比如我們要在節點上安裝安全更新檔。或者在節點上預先下載下傳一個容器鏡像。
- Sidecar Set：越來越多的運維能力，以sidecare方式提供，比如日志、監控、和服務網格中的資料平面元件Envoy；我們可以通過Sidecar Set以聲明式方法管理sidecar的生命周期
- Advanced StatefulSet: 支援原地釋出和并行更新，
這些控制器解決了很多客戶的真實痛點。
此外，在10月，阿裡雲聯合了微軟一起釋出了開放應用模型 Open Application Model（OAM）
OAM 是一個專注于描述應用生命周期的标準規範，可以幫助應用開發者、應用運維人員和基礎架構運維團隊更好地進行協同。在這個模型裡，開發人員負責定義應用組成、依賴與架構；應用運維人員負責定義應用運作時配置與運維需求，比如釋出政策和監控名額，而基礎架構運維團隊可以針對應用部署環境的不同，配置定制化參數。
通過這種關注點分離（Separation of Concerns）的設計，可以将應用定義、運維能力與基礎設施實作解構。讓應用傳遞變得更加高效、可靠和自動化。
随着5G時代的臨近，低延遲網絡、AI硬體算力提升、和智能化應用快速發展，一個萬物智聯的時代必将到來。将計算能力從雲延展到到邊緣側、裝置側，并通過雲進行統一應用傳遞、資源管控，将會是雲計算發展的必然趨勢。
基于容器，我們建立了雲邊端一體協同平台，ACK@Edge這樣我們可以将一些需要低延遲處理的應用部署在邊緣節點實作就近通路，比如，我們可以把AI模型預測和實時資料處理放置到邊緣，進行實時智能決策；而将模型訓練，大資料處理等需要海量算力應用放到雲端。
ACK邊緣版提供了統一管控能力，在K8s叢集中可以同時支援雲端ECS和邊緣ENS節點、以及IoT裝置。并且針對邊緣的特殊性，提供了單元化隔離和斷連自治、自愈能力。我們已經在阿裡雲視訊雲、優酷等場景中開始大規模應用。
我們以優酷筋鬥雲為例介紹其計算架構演進。優酷是國内最大的視訊平台，随着優酷業務的快速發展，需要将原來部署在若幹IDC内的集中式架構，演進到雲+邊緣計算的架構。這時候需要一種方式來統一管理阿裡雲十幾個region和衆多的邊緣節點。優酷選擇了ACK@Edge，可以統一管理雲與邊緣的節點，并實作了統一的應用釋出和彈性擴縮容。
通過彈性能力，節省了機器成本50%。采用新的架構之後，使用者終端可以就近通路邊緣節點，讓端到端網絡延遲降低了75%。
雲原生技術的發展離不開社群的成長和壯大，阿裡巴巴全面擁抱雲原生技術，并将我們在大規模生産最佳實踐回饋到社群，與社群共同建設更加美好的雲原生計算。