今天會跟大家分享我們對云原生領(lǐng)域的簡單思考，以及我們對云原生發(fā)展四個趨勢大概的介紹：
●擁抱 Serverless – 極致彈性，無需運(yùn)維；
●服務(wù)網(wǎng)格 – 將服務(wù)治理能力與應(yīng)用解耦，并下沉到基礎(chǔ)設(shè)施層；
●云原生應(yīng)用管理標(biāo)準(zhǔn)化 – 構(gòu)建高效、自動化和可信賴的應(yīng)用交付體系；
●計(jì)算無邊界 – 實(shí)現(xiàn)云-邊緣-IoT 設(shè)備的高效協(xié)同。
云原生基本概念
先簡單介紹云原生一些基本的概念。
我們接觸了很多的客戶，對于這些客戶而言，上不上云已經(jīng)不是問題，他們關(guān)注的是該怎么上云？該如何充分利用云的能力、最大化云的價(jià)值？在 All in Cloud 的時(shí)代，企業(yè)的技術(shù)能力已經(jīng)成為核心競爭力，他們非常愿意用云作為企業(yè) IT 能力的增效器。
云原生計(jì)算是一組最佳實(shí)踐和方法論，在公共云、專有云環(huán)境中，構(gòu)建可伸縮、健壯、松耦合的應(yīng)用，可以更加快速地創(chuàng)新和低成本試錯；容器、服務(wù)網(wǎng)格、無服務(wù)計(jì)算等新的計(jì)算范型不斷涌現(xiàn)。
容器掀開了云原生技術(shù)的序幕：
●Docker 鏡像形成了應(yīng)用分發(fā)和交付的標(biāo)準(zhǔn)，可以將應(yīng)用與底層運(yùn)行環(huán)境實(shí)現(xiàn)解耦；
●Kubernetes 技術(shù)成為了分布式資源調(diào)度和編排的標(biāo)準(zhǔn)，Kubernetes 屏蔽了底層基礎(chǔ)架構(gòu)的差異，幫助應(yīng)用運(yùn)行在不同的基礎(chǔ)設(shè)施之中；
●在此基礎(chǔ)之上，社區(qū)開始建立上層的應(yīng)用抽象。比如服務(wù)治理層，Istio 成為了服務(wù)通信的網(wǎng)絡(luò)協(xié)議棧，將服務(wù)治理能力與應(yīng)用層實(shí)現(xiàn)解耦。
在此之上，面向領(lǐng)域的云原生框架也在迅速出現(xiàn)，比如面向機(jī)器學(xué)習(xí)的云原生平臺 Kubeflow 和面向無服務(wù)器的 Knative 等等。通過這樣的架構(gòu)分層，開發(fā)者只需關(guān)注自身的業(yè)務(wù)邏輯，而無需關(guān)注底層實(shí)現(xiàn)的復(fù)雜性。
我們可以看到一個云原生操作系統(tǒng)的雛形開始出現(xiàn)，這是開發(fā)者最好的時(shí)代，極大地提升了業(yè)務(wù)創(chuàng)新的速度。
在早期，Kubernetes上主要運(yùn)行無狀態(tài)的 Web 應(yīng)用，比如基于 Apache Dubbo/Spring Cloud 的微服務(wù)應(yīng)用。而現(xiàn)在，越來越多的企業(yè)核心業(yè)務(wù)、數(shù)據(jù)智能業(yè)務(wù)以及創(chuàng)新業(yè)務(wù)也運(yùn)行在 Kubernetes 之上。
以阿里云自身的云產(chǎn)品舉例，如企業(yè)級分布式應(yīng)用服務(wù) EDAS、實(shí)時(shí)計(jì)算平臺 Flink、彈性 AI 算法服務(wù) EAS 以及區(qū)塊鏈平臺 BaaS 也部署在阿里云 Kubernetes 服務(wù) ACK 之上。
K8s 已經(jīng)成為云時(shí)代操作系統(tǒng)，成為應(yīng)用使用云基礎(chǔ)設(shè)施能力的界面。阿里云 ACK 實(shí)現(xiàn)了對云基礎(chǔ)設(shè)施的優(yōu)化集成，提供敏捷、彈性和可移植的云原生應(yīng)用平臺；而且可以在公共云、專有云、邊緣云上實(shí)現(xiàn)一致的應(yīng)用部署和管理。
從容器到無服務(wù)器
Serverless Kubernetes
下面我們來談一下，Kubernetes 的 Serverless 進(jìn)化。
所有人都喜歡 K8s 提供的強(qiáng)大和靈活，但是運(yùn)維一個 Kubernetes 生產(chǎn)集群極具挑戰(zhàn)。
阿里云的 Kubernetes 服務(wù) ACK 簡化了 K8s 集群的生命周期管理，托管了集群的 master 節(jié)點(diǎn)被，但是用戶依然要保有 worker 節(jié)點(diǎn)資源池，還需要維護(hù)節(jié)點(diǎn)，比如進(jìn)行升級安全補(bǔ)丁等，并根據(jù)自己的使用情況對資源層進(jìn)行容量規(guī)劃。
針對 K8s 的運(yùn)維復(fù)雜性挑戰(zhàn)，阿里云推出了 Serverless Kubernetes 容器服務(wù) ASK，完全兼容現(xiàn)有 K8s 容器應(yīng)用，但是所有容器基礎(chǔ)設(shè)施被阿里云托管，用戶可以專注于自己的應(yīng)用。它具備幾個特點(diǎn)：
●首先用戶沒有任何預(yù)留資源，按照容器應(yīng)用實(shí)際消耗的資源付費(fèi)；
●對用戶而言沒有節(jié)點(diǎn)的概念，零維護(hù)；
●所有資源按需創(chuàng)建，無需任何容量規(guī)劃。
Serverless Kubernetes 極大降低了運(yùn)維復(fù)雜性，而且其自身設(shè)計(jì)非常適合突發(fā)類應(yīng)用負(fù)載，如 CI/CD，批量計(jì)算等等。比如一個典型的在線教育客戶，根據(jù)教學(xué)需要按需部署教學(xué)應(yīng)用，課程結(jié)束自動釋放資源，整體計(jì)算成本只有使用包月節(jié)點(diǎn)的 1/3。
云規(guī)模的 Nodeless 架構(gòu) —— Viking
它是怎么實(shí)現(xiàn)的呢？
在 2017 年底，我們啟動 Serverless Kubernetes 項(xiàng)目的時(shí)候，就一直在思考：如果 Kubernetes 天生長在云上，它的架構(gòu)應(yīng)該如何設(shè)計(jì)？我們?yōu)樗鼉?nèi)部的產(chǎn)品代號為 Viking，因?yàn)楣糯S京戰(zhàn)船以迅捷和便于操作而著稱。
首先，我們希望兼容 Kubernetes。用戶可以直接使用 Kubernetes 的聲明式 API，兼容 Kubernetes 的應(yīng)用定義，Deployment, StatefulSet, Job, Service 等無需修改。
其次 Kubernetes 底層盡可能充分利用云基礎(chǔ)設(shè)施服務(wù)的能力和云服務(wù)來實(shí)現(xiàn)，比如計(jì)算、存儲、網(wǎng)絡(luò)、資源的調(diào)度等；根本性簡化容器平臺的設(shè)計(jì)，提升規(guī)模，降低用戶運(yùn)維復(fù)雜性。我們遵從 Kubernetes 控制器設(shè)計(jì)模式，驅(qū)動整個 IaaS 資源狀態(tài)不斷地向用戶應(yīng)用聲明的狀態(tài)逼近。
我們在資源層提供了彈性容器實(shí)例 - ECI。與 Azure Container Instance ACI, AWS Fargate 不同，ECI 提供 Kubernetes Pod 的原生支持而不是提供單獨(dú) container 實(shí)例。ECI 基于輕量虛擬機(jī)提供了沙箱環(huán)境實(shí)現(xiàn)安全隔離，完全兼容 Pod 的語義、支持多容器進(jìn)程、健康檢查、啟動順序等能力。這樣使得上層構(gòu)建 K8s 兼容層，變得非常簡單直接。
在編排調(diào)度層，我們使用了微軟的 Virtual-Kubelet，并對其進(jìn)行了深度擴(kuò)展。Virtual-Kubelet 提供了一個抽象的控制器模型來模擬一個 Kubernetes 節(jié)點(diǎn)。當(dāng)一個 Pod 被調(diào)度到虛擬節(jié)點(diǎn)上，控制器會利用 ECI 服務(wù)創(chuàng)建一個 ECI 實(shí)例來運(yùn)行 Pod。同時(shí)控制器支持雙向狀態(tài)同步，如果一個運(yùn)行中的 ECI 實(shí)例被刪除，控制器會根據(jù)應(yīng)用目標(biāo)狀態(tài)重新恢復(fù)一個新的 ECI 實(shí)例。
同時(shí)我們基于阿里云的云服務(wù)實(shí)現(xiàn)了 Kube-Proxy、Kube-DNS、Ingress Controller 的行為，提供了完整的 Kubernetes Service 能力支持：
比如利用阿里云的 DNS 服務(wù) PrivateZone，為 ECI 實(shí)例動態(tài)配置 DNS 地址解析，支持了 Headless Service；
通過內(nèi)網(wǎng) SLB 提供了 Cluster IP，提供負(fù)載均衡能力；
通過 SLB 提供的 7 層路由來實(shí)現(xiàn) Ingress 的路由規(guī)則。
我們也為 ECI 提供了端到端可觀測性能力，并與阿里云日志服務(wù)，云監(jiān)控等服務(wù)進(jìn)行了深度集成，也可以輕松支持 HPA 水平擴(kuò)容。
容器啟動加速——“零秒”鏡像下載
對于 Serverless 容器技術(shù)而言，應(yīng)用啟動速度是一個核心指標(biāo)。容器對應(yīng)用啟動速度的影響主要在于：
資源的準(zhǔn)備：通過端到端管控鏈路的優(yōu)化和針對容器場景虛擬化和操作系統(tǒng)的剪裁和優(yōu)化，ECI 可以將資源準(zhǔn)備時(shí)間優(yōu)化到秒級；
鏡像下載時(shí)間：從 Docker 鏡像倉庫下載鏡像并在本地解壓縮是一個非常耗時(shí)的操作。下載時(shí)間取決于鏡像大小，通常在 30 秒到數(shù)分鐘不等。
在傳統(tǒng) Kubernetes 中， worker 節(jié)點(diǎn)會在本地緩存已下載過的鏡像，這樣下次啟動不會重復(fù)下載和解壓。為了實(shí)現(xiàn)極致彈性成本效率，ECI 和 ECS 采用并池的策略，計(jì)算存儲分離的架構(gòu)，這也意味著我們不可能通過傳統(tǒng)方式利用本地盤來做容器鏡像的緩存。
為此我們實(shí)現(xiàn)了一個創(chuàng)新的方案：可以將容器鏡像制作成一個數(shù)據(jù)盤快照。
當(dāng) ECI 啟動時(shí)，如果鏡像快照存在，可以直接基于快照創(chuàng)建一個只讀數(shù)據(jù)盤，并隨著實(shí)例啟動自動掛載，容器應(yīng)用直接利用掛載數(shù)據(jù)盤作為 rootfs 進(jìn)行啟動?；诒P古 2.0 架構(gòu)和阿里云 ESSD 云盤的極致 I/O 性能，我們可以將鏡像加載的時(shí)間縮小到 1 秒以內(nèi)。
為了簡化用戶操作，我們在 K8s 中提供了 CRD 可以讓用戶指明哪些鏡像需要構(gòu)建鏡像快照。同時(shí)，在 ACR 鏡像倉庫服務(wù)的軟件交付流水線上，我們可以聲明哪些鏡像需要進(jìn)行加速，這樣當(dāng)用戶推送一個新鏡像時(shí)，就會自動構(gòu)建相應(yīng)的快照緩存。
極致彈性
下面談彈性，對于絕大多數(shù)的企業(yè)來講，彈性是上云最重要的一個訴求，雙 11 就是一個典型的脈沖式計(jì)算，峰值計(jì)算資源會是平時(shí)的很多倍。也有不可預(yù)期的峰值發(fā)生，比如一個爆款游戲大熱之后，就需要迅速地在云上擴(kuò)容。Kubernetes 可以將云的彈性能力發(fā)揮到極致。
ACK 在資源層和應(yīng)用層提供了豐富的彈性策略，在資源層目前主流的方案是通過 cluster-autoscaler 進(jìn)行節(jié)點(diǎn)的水平伸縮。當(dāng)出現(xiàn) Pod 由于資源不足造成無法調(diào)度時(shí)，cluster-autoscaler 會選擇一個伸縮組中，并自動向組內(nèi)加入實(shí)例。
在彈性伸縮組中，我們可以根據(jù)應(yīng)用負(fù)載需求選擇 ECS 虛擬機(jī)，神龍裸金屬和 GPU 實(shí)例進(jìn)行擴(kuò)容。值得一提的是 Spot instance，競價(jià)實(shí)例可以利用阿里云的空閑計(jì)算資源，成本折扣可以低至按量付費(fèi)實(shí)例的 90%。
競價(jià)實(shí)例非常適合無狀態(tài)和容錯性好的應(yīng)用，比如批量數(shù)據(jù)處理或者視頻渲染等，可以大大降低計(jì)算成本。基于阿里云強(qiáng)大的彈性計(jì)算能力，我們可以在分鐘級實(shí)現(xiàn)千節(jié)點(diǎn)伸縮。
進(jìn)一步結(jié)合上文提到的 ECI，我們可以在 ACK 中基于虛擬節(jié)點(diǎn)實(shí)現(xiàn)彈性伸縮。virtual-kubelet 可以注冊為一個虛擬節(jié)點(diǎn)，理論上擁有無限大的容量。當(dāng) Pod 調(diào)度到虛擬節(jié)點(diǎn)上時(shí)，會利用 ECI 動態(tài)創(chuàng)建 Pod，這非常適合大數(shù)據(jù)離線任務(wù)、CI/CD 作業(yè)、突發(fā)型在線負(fù)載等。在一個大型客戶的生產(chǎn)環(huán)境中，彈性容器實(shí)例可以在 30 秒內(nèi)啟動 500 Pod，輕松應(yīng)對突發(fā)的請求峰值。
在應(yīng)用層，Kubernetes 提供了 HPA 的方式進(jìn)行 Pod 的水平伸縮，和 VPA 進(jìn)行 Pod 的垂直伸縮。阿里云提供了 alibaba-cloud-metrics-adapter，可以提供更加豐富的彈性指標(biāo)，比如可以根據(jù) Ingress Gateway 的 QPS 指標(biāo)、云監(jiān)控的指標(biāo)，動態(tài)調(diào)整應(yīng)用 Pod 數(shù)量。
另外對很多行業(yè)客戶而言，應(yīng)用負(fù)載的資源畫像是具有周期性的。比如，我們一個證券行業(yè)的客戶，每周一到周五，股市開盤時(shí)間是交易時(shí)間，而其他的時(shí)間，只能查詢不提供交易，峰谷資源需求量高達(dá) 20 倍以上的差異。
為了解決這個場景，阿里云容器服務(wù)提供了定時(shí)伸縮組件，專門應(yīng)對資源畫像存在周期性的場景 ，開發(fā)者可以定義 time schedule，提前擴(kuò)容好資源，而在波谷到來后定時(shí)回收資源；結(jié)合底層 cluster-autoscaler 的節(jié)點(diǎn)伸縮能力，很好平衡了系統(tǒng)的穩(wěn)定性和資源成本的節(jié)約。
未來我們會發(fā)布一些基于機(jī)器學(xué)習(xí)的彈性伸縮策略，可以根據(jù)歷史資源畫像，實(shí)現(xiàn)更好地資源預(yù)測，提升彈性的 SLA。
賦能下一代無服務(wù)器應(yīng)用
上文說到了為什么 Serverless 受到越來越多開發(fā)者的歡迎，因?yàn)榇蠹腋P(guān)注自己的業(yè)務(wù)，而不是基礎(chǔ)設(shè)施的維護(hù)。Serverless 化是云服務(wù)發(fā)展的必然趨勢，我們需要將資源調(diào)度，系統(tǒng)運(yùn)維等能力下沉到基礎(chǔ)設(shè)施。
Google, IBM，CloudFoundry 等共同推出了 Knative 作為 Serverless 編排框架，可以非常簡潔、高效地實(shí)現(xiàn)無服務(wù)器化應(yīng)用。它提供了幾個核心能力：
Eventing - 提供了事件驅(qū)動的處理模型，我們針對阿里云，擴(kuò)展了豐富的事件源，比如當(dāng) OSS 接收到用戶上傳的一個視頻片段，觸發(fā)容器中的應(yīng)用進(jìn)行視頻轉(zhuǎn)碼；
Serving- 提供了靈活的服務(wù)響應(yīng)能力，可以根據(jù)業(yè)務(wù)的請求量自動彈性伸縮，甚至支持縮容到零，利用阿里云彈性基礎(chǔ)設(shè)施，可以大大降低資源成本；
Tekton - 可以輕松實(shí)現(xiàn)從代碼到應(yīng)用部署的自動化流水線。
結(jié)合應(yīng)用管理能力和應(yīng)用性能監(jiān)控服務(wù), 我們可以基于 Knative 快速搭建具備領(lǐng)域特色的應(yīng)用托管服務(wù) (Micro PaaS)，大大降低直接操作 Kubernetes 資源的復(fù)雜度，讓開發(fā)者更加專注于應(yīng)用迭代和服務(wù)交付效率提升。
安全沙箱容器技術(shù)進(jìn)化
剛才談完了編程模型，看一下底層實(shí)現(xiàn)，所有的 Serverless下面核心實(shí)現(xiàn)就是安全容器沙箱。
傳統(tǒng)的 Docker RunC 容器與宿主機(jī) Linux 共享內(nèi)核，通過 CGroup 和 namespace 實(shí)現(xiàn)資源隔離。這種方式非常高效，但是由于操作系統(tǒng)內(nèi)核的攻擊面比較大，一旦惡意容器利用內(nèi)核漏洞，可以影響整個宿主機(jī)上所有的容器。
越來越多企業(yè)客戶關(guān)注容器的安全性，為了提升安全隔離，阿里云和螞蟻金服團(tuán)隊(duì)合作，引入安全沙箱容器技術(shù)。
今年 9 月份我們發(fā)布了基于輕量虛擬化技術(shù)的 RunV 安全沙箱。相比于 RunC 容器，每個 RunV 容器具有獨(dú)立內(nèi)核，即使容器所屬內(nèi)核被攻破，也不會影響其他容器，非常適合運(yùn)行來自第三方不可信應(yīng)用或者在多租戶場景下進(jìn)行更好的安全隔離。
經(jīng)過性能優(yōu)化，安全沙箱容器現(xiàn)在可以達(dá)到 90% 的原生 RunC 性能，并且 RunV 容器提供了和 RunC 容器完全一致的用戶體驗(yàn)，包括日志、監(jiān)控、彈性等。同時(shí)，ACK 可以在一臺神龍裸金屬實(shí)例上同時(shí)混布 RunC 和 RunV 容器，用戶可以根據(jù)自己的業(yè)務(wù)特性自主選擇。
在財(cái)年年底，我們會推出基于 Intel SGX 可信計(jì)算技術(shù)的可信容器沙箱 RunE。容器應(yīng)用運(yùn)行在 CPU 中被稱為 enclave 的安全可信執(zhí)行環(huán)境中。一個比喻：我們把容器放進(jìn)了保險(xiǎn)箱，任何人，包括云服務(wù)供應(yīng)商，都無法從外部篡改和截獲之中數(shù)據(jù)?？蛻艨梢詫⒏邫C(jī)密應(yīng)用，比如秘鑰的加簽、驗(yàn)簽，隱私數(shù)據(jù)處理等邏輯運(yùn)行在 RunE 容器中。
從微服務(wù)到服務(wù)網(wǎng)格
下面談另外一個方面——微服務(wù)架構(gòu)的演化。
互聯(lián)網(wǎng)應(yīng)用架構(gòu)催生了微服務(wù)架構(gòu)的發(fā)展。它的核心思想是通過應(yīng)用功能拆分，將復(fù)雜應(yīng)用拆解為一組松耦合服務(wù)，每個服務(wù)遵守單一責(zé)任原則（Single Responsibility Principle）。每個服務(wù)可以獨(dú)立部署和交付，大大提升了業(yè)務(wù)敏捷性；每個服務(wù)可以獨(dú)立橫向擴(kuò)展/收縮，應(yīng)對互聯(lián)網(wǎng)規(guī)模的挑戰(zhàn)。
服務(wù)治理能力下沉
微服務(wù)框架，比如 HSF/Dubbo 或 Spring Cloud，都提供了強(qiáng)大的服務(wù)治理能力，比如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、熔斷降級等。這些服務(wù)治理能力以 Fat SDK 的方式與應(yīng)用程序構(gòu)建在一起，隨著應(yīng)用一起發(fā)布和維護(hù)，服務(wù)治理能力與業(yè)務(wù)邏輯的生命周期耦合在一起。
微服務(wù)框架的升級會導(dǎo)致整個應(yīng)用的重新構(gòu)建和部署。此外由于 Fat SDK 通常與特定語言所綁定，難以支持企業(yè)應(yīng)用的多語言（polyglot）實(shí)現(xiàn)。
為了解決上述挑戰(zhàn)，社區(qū)提出了 Service Mesh（服務(wù)網(wǎng)格）架構(gòu)。它將服務(wù)治理能力下沉到基礎(chǔ)設(shè)施，通過一個獨(dú)立的 Sidecar 進(jìn)程來提供服務(wù)治理能力，而應(yīng)用側(cè)只保留協(xié)議的編解碼即可。
從而實(shí)現(xiàn)了服務(wù)治理與業(yè)務(wù)邏輯的解耦，二者可以獨(dú)立演進(jìn)不相互干擾，提升了整體架構(gòu)的靈活性；同時(shí)服務(wù)網(wǎng)格架構(gòu)減少了對業(yè)務(wù)邏輯的侵入性，降低了多語言支持的復(fù)雜性。
服務(wù)網(wǎng)格
在阿里巴巴經(jīng)濟(jì)體內(nèi)部，我們已經(jīng)開始大規(guī)模應(yīng)用服務(wù)網(wǎng)格技術(shù)，來提供多語言支持，降低業(yè)務(wù)對接門檻；提供統(tǒng)一架構(gòu)模式，提升技術(shù)迭代速度。以 Istio 為代表的服務(wù)網(wǎng)格技術(shù)具有光明的前途，但是大規(guī)模生產(chǎn)落地時(shí)仍然存在非常多的挑戰(zhàn)。
●首先是 Istio 服務(wù)網(wǎng)格技術(shù)自身的復(fù)雜性；
●其次是規(guī)?；瘞淼姆€(wěn)定性和性能的挑戰(zhàn)：
●在海量服務(wù)的情況下，控制平面是否可以支持服務(wù)配置的高效分發(fā)？
●數(shù)據(jù)平面是否可以盡可能降低增加兩跳后的通信延遲？
●下沉可觀測性和策略管理能力到數(shù)據(jù)平面，避免集中化 Mixer 引入的性能瓶頸等。
●最后是和現(xiàn)有的微服務(wù)架構(gòu)兼容并存，支持現(xiàn)有微服務(wù)的統(tǒng)一配置管理服務(wù)和通信協(xié)議。
為了解決上述挑戰(zhàn)，阿里巴巴和螞蟻金服與 Istio 社區(qū)兼容的技術(shù)體系上，構(gòu)建了服務(wù)網(wǎng)格能力。在今年 618，螞蟻金服已經(jīng)完成核心系統(tǒng)上到 SOFAMosn 的驗(yàn)證工作，剛剛結(jié)束的雙 11，阿里巴巴和螞蟻金服在核心系統(tǒng)大規(guī)模上線了 Service Mesh。
同時(shí)阿里巴巴經(jīng)濟(jì)體會把自身技術(shù)演進(jìn)的結(jié)果及時(shí)反饋到上游去，與社區(qū)共同推進(jìn) Service Mesh 發(fā)展。比如在阿里巴巴開源的服務(wù)發(fā)現(xiàn)與配置管理項(xiàng)目 Nacos 最新版本中，就提供了 Istio 對 MCP 協(xié)議支持。
晚些時(shí)候，阿里云會推出托管 Service Mesh 服務(wù)，幫助云上的開發(fā)者能夠便捷地使用服務(wù)網(wǎng)格技術(shù)。
聚焦應(yīng)用生命周期
另外一個關(guān)注的焦點(diǎn)是應(yīng)用生命周期的自動化、標(biāo)準(zhǔn)化。我們知道 Kubernetes 的定位是 Platform for Platform，幫助企業(yè)實(shí)現(xiàn)自動化應(yīng)用運(yùn)維、管理。
Kubernetes 為分布式應(yīng)用管理提供了很多基礎(chǔ)的元語抽象，比如面向無狀態(tài)應(yīng)用的 Deployment 和面向有狀態(tài)應(yīng)用的 StatefulSet。
但是在企業(yè)生產(chǎn)環(huán)境中，面對應(yīng)用的不同需求，現(xiàn)有能力還存在一些不足。參加技術(shù)分享我們經(jīng)常會聽到每個企業(yè)都在談如何修改 K8s 來解決自己的問題，這里面很多問題都是相似的。
OpenKruise
作為云原生技術(shù)的引領(lǐng)者，阿里巴巴將我們在云原生計(jì)算技術(shù)上大規(guī)模生產(chǎn)的最佳實(shí)踐沉淀下來，以開源項(xiàng)目 OpenKruise 的方式與社區(qū)開放、共建。
一方面幫助企業(yè)客戶在云原生的探索的過程中，少走彎路，減少技術(shù)碎片；
一方面推動上游技術(shù)社區(qū)，逐漸完善和豐富 Kubernetes 的應(yīng)用周期自動化能力。
以如下幾個新的控制器為例：
●Broadcast Job：可以讓一次性任務(wù)運(yùn)行在機(jī)器上指定的節(jié)點(diǎn)，比如我們要在節(jié)點(diǎn)上安裝安全補(bǔ)丁，或者在節(jié)點(diǎn)上預(yù)先下載一個容器鏡像；
●Sidecar Set：越來越多的運(yùn)維能力以 Sidecare 方式提供，比如日志、監(jiān)控、和服務(wù)網(wǎng)格中的數(shù)據(jù)平面組件 Envoy。我們可以通過 Sidecar Set 以聲明式方法管理 Sidecar的生命周期；
●Advanced StatefulSet: 支持原地發(fā)布和批量升級，讓大家在更加簡單地支持有狀態(tài)服務(wù)。
●這些控制器解決了很多客戶的真實(shí)痛點(diǎn)。
OAM-首個開放應(yīng)用模型
在 11 月 16 日，微軟和阿里云共同發(fā)布了 Open Application Model（OAM），希望能夠建立起一個標(biāo)準(zhǔn)化的云原生應(yīng)用模型，幫助開發(fā)者、應(yīng)用運(yùn)維和基礎(chǔ)設(shè)施運(yùn)維團(tuán)隊(duì)，進(jìn)行更加高效的協(xié)同。
它采用的關(guān)注點(diǎn)設(shè)計(jì)標(biāo)準(zhǔn)包括不同的維度，開發(fā)者負(fù)責(zé)定義應(yīng)用的組件、依賴與架構(gòu)；應(yīng)用運(yùn)維人員負(fù)責(zé)定義應(yīng)用運(yùn)行時(shí)配置與運(yùn)維需求，比如發(fā)布策略和監(jiān)控指標(biāo)，而基礎(chǔ)架構(gòu)運(yùn)維團(tuán)隊(duì)可以針對應(yīng)用部署環(huán)境的不同，配置定制化參數(shù)。
通過這種關(guān)注點(diǎn)分離（Separation of Concerns）的設(shè)計(jì)，可以將應(yīng)用定義、運(yùn)維能力與基礎(chǔ)設(shè)施實(shí)現(xiàn)解構(gòu)。讓應(yīng)用交付變得更加高效、可靠和自動化。
計(jì)算無邊界
最后一個方面，我們來講一下對未來無邊界云計(jì)算的思考。
隨著 5G 時(shí)代的臨近，低延遲網(wǎng)絡(luò)、AI 硬件算力提升和智能化應(yīng)用快速發(fā)展，一個萬物智聯(lián)的時(shí)代必將到來，將計(jì)算能力從云延展到到邊緣側(cè)、設(shè)備側(cè)，并通過云進(jìn)行統(tǒng)一應(yīng)用交付、資源管控，將會是云計(jì)算發(fā)展的必然趨勢。
云邊端一體協(xié)同
基于容器，我們建立了云邊端一體協(xié)同平臺 —— ACK@Edge。這樣我們可以將一些需要低延遲處理的應(yīng)用部署在邊緣節(jié)點(diǎn)實(shí)現(xiàn)就近訪問。比如，我們可以把 AI 模型預(yù)測和實(shí)時(shí)數(shù)據(jù)處理放置到邊緣，進(jìn)行實(shí)時(shí)智能決策，而將模型訓(xùn)練，大數(shù)據(jù)處理等需要海量算力應(yīng)用放到云端。
ACK 邊緣版提供了統(tǒng)一管控能力，在 K8s 集群中可以同時(shí)支持云端 ECS、邊緣 ENS 節(jié)點(diǎn)以及 IoT 設(shè)備。并且針對邊緣的特殊性，提供了單元化隔離和斷連自治、自愈能力。我們已經(jīng)在阿里云視頻云、優(yōu)酷等場景中開始大規(guī)模應(yīng)用。
優(yōu)酷筋斗云
我們以優(yōu)酷筋斗云為例介紹其計(jì)算架構(gòu)演進(jìn)。
優(yōu)酷是國內(nèi)最大的視頻平臺，隨著優(yōu)酷業(yè)務(wù)的快速發(fā)展，需要將原來部署在若干 IDC 內(nèi)的集中式架構(gòu)，演進(jìn)到云+邊緣計(jì)算的架構(gòu)。這時(shí)候需要一種方式來統(tǒng)一管理阿里云十幾個 region 和眾多的邊緣節(jié)點(diǎn)。
優(yōu)酷選擇了 ACK@Edge，可以統(tǒng)一管理云與邊緣的節(jié)點(diǎn)，并實(shí)現(xiàn)了統(tǒng)一的應(yīng)用發(fā)布和彈性擴(kuò)縮容。通過彈性能力，節(jié)省了機(jī)器成本 50%。采用新的架構(gòu)之后，用戶終端可以就近訪問邊緣節(jié)點(diǎn)，讓端到端網(wǎng)絡(luò)延遲降低了 75%。
源于社區(qū)，回饋開源
最后，云原生技術(shù)源自于社區(qū)的共同的建設(shè)。阿里巴巴作為云原生的實(shí)踐者和引領(lǐng)者，全面擁抱云原生技術(shù)，并將我們在大規(guī)模生產(chǎn)最佳實(shí)踐回饋到社區(qū)，與社區(qū)共同建設(shè)更加美好的云原生技術(shù)生態(tài)。
