本文整理自司徒放（姬風(fēng)）題目為《開源的黃金時(shí)代，阿里巴巴云原生開源的探索與實(shí)踐》的演講。
關(guān)注“阿里巴巴云原生”公眾號，回復(fù)關(guān)鍵詞“開源”即可下載本文 PPT。

導(dǎo)讀：從擁抱開源、貢獻(xiàn)開源、自主開源，到賦能開源，開源已升級為阿里技術(shù)戰(zhàn)略之一，且正為開發(fā)者源源不斷地輸送切實(shí)可見的價(jià)值。云原生是阿里開源的重要領(lǐng)域，短短幾年，以 K8s 為核心的云原生開源生態(tài)迅猛發(fā)展，這是全世界開發(fā)者合作杰出成果，也是開源力量的結(jié)晶。

阿里巴巴的應(yīng)用架構(gòu)演進(jìn)

大家好，我是司徒放，目前在阿里巴巴負(fù)責(zé)阿里云的應(yīng)用平臺和微服務(wù)產(chǎn)品線。在和大家分享我們在云原生應(yīng)用方面的探索之前，先和大家介紹一下阿里巴巴在整個(gè)應(yīng)用架構(gòu)方面的演進(jìn)歷程。

今年是阿里巴巴成立的二十周年，二十年前，阿里巴巴使用的這個(gè)應(yīng)用的架構(gòu)，還是單體應(yīng)用模式，它有很多的業(yè)務(wù)模塊都在一個(gè)應(yīng)用里面，各個(gè)業(yè)務(wù)都在一個(gè)應(yīng)用里面開發(fā)，這個(gè)架構(gòu)的一個(gè)好處是簡單，也非常容易部署，對小的創(chuàng)業(yè)公司來說是很方便的。它的缺點(diǎn)在于團(tuán)隊(duì)變大變多之后，不能滿足快速迭代要求，因?yàn)槊恳粋€(gè)業(yè)務(wù)它需要去發(fā)布的時(shí)候，都需要在同一個(gè)應(yīng)用上做修改、發(fā)布，當(dāng)這個(gè)業(yè)務(wù)迭代非?？斓臅r(shí)候，它同時(shí)的一個(gè)并發(fā)修改就非常多。

所以在 2008 年的時(shí)候，阿里巴巴就引進(jìn)到了微服務(wù)架構(gòu)，只是當(dāng)時(shí)并不叫微服務(wù)，而是叫服務(wù)化架構(gòu)。各個(gè)業(yè)務(wù)模式就按照服務(wù)的邊界來拆分，這是比較松耦合的一種方式，一個(gè)微服務(wù)應(yīng)用是無狀態(tài)的，可以快速擴(kuò)展實(shí)例。而且某個(gè)實(shí)例有異常比如宕機(jī)時(shí)會可以自動下線，不會影響整個(gè)服務(wù)架構(gòu)的穩(wěn)定性。微服務(wù)架構(gòu)也比較容易推動整個(gè)互聯(lián)網(wǎng)公司的快速迭代需求。

大概三年前，阿里巴巴就走向了云原生的架構(gòu)。這是一個(gè)天然適合云的、能夠充分利用云的彈性能力和標(biāo)準(zhǔn)云服務(wù)，給整個(gè)阿里巴巴的電商降低機(jī)器的準(zhǔn)備成本，特別是類似于在大促雙十一需要很多機(jī)器去支撐，但是大促結(jié)束之后，這些機(jī)器有一半以上就可以歸還到云上。

這個(gè)時(shí)候，阿里巴巴就在往云原生的方向去邁進(jìn)，而且通過整個(gè)云服務(wù)能夠更快地加快整個(gè)阿里巴巴的技術(shù)構(gòu)建。而且云原生架構(gòu)，是一個(gè)比較開放、標(biāo)準(zhǔn)、沒有侵入性的技術(shù)架構(gòu)。

阿里巴巴在云原生的開源進(jìn)程

在阿里巴巴進(jìn)入到了云原生之后，我們看一下阿里巴巴在開源方面做了一些什么樣的事情呢？

運(yùn)維領(lǐng)域

首先，整個(gè)云原生架構(gòu)里面最重要、最關(guān)鍵的一個(gè)基石就是 Kubernetes。
阿里巴巴在兩年前，就在大規(guī)模的落地 Kubernetes 的整套技術(shù)用來做我們機(jī)器資源的調(diào)度和管理。在內(nèi)部有數(shù)十萬臺級別的機(jī)器以及上百萬級別的容器規(guī)模，直接拿開源的 Kubernetes 到這種生產(chǎn)規(guī)模下是用不起來的，所以我們在上面做了很多性能優(yōu)化，包括針對規(guī)模上的改造，使得整個(gè) Kubernetes 在阿里巴巴內(nèi)部能夠很順暢地 run 起來，阿里巴巴也在不斷地向上游去貢獻(xiàn)我們內(nèi)部實(shí)踐和優(yōu)化的代碼。
除了 Kubernetes 之外，在整個(gè)云原生生態(tài)里還有像容器、etcd，我們也在不停地優(yōu)化它的規(guī)模能力以及安全隔離方面的一些能力。同時(shí)，也開源了內(nèi)部使用的蜻蜓（Dragonfly）用來做大規(guī)模的鏡像快速分發(fā)。

開發(fā)領(lǐng)域

在開發(fā)領(lǐng)域，阿里巴巴很早就已經(jīng)使用了微服務(wù)架構(gòu)，也對外進(jìn)行了開源，比如說 Apache Dubbo，這個(gè)是比較知名的 RPC 框架；還有去年開源的 Nacos ，作為阿里巴巴集團(tuán)支撐大規(guī)模的服務(wù)注冊發(fā)現(xiàn)、配置推送一個(gè)組件；另外，還有 Spring Cloud Alibaba，基于阿里開源的組件提供了一整套 Spring Cloud 最佳實(shí)現(xiàn)；還有像支撐整個(gè)阿里巴巴高可用的 Sentinel、以及 Apache RocketMQ 消息隊(duì)列，都是我們在開發(fā)領(lǐng)域做的開源。

這些組件其實(shí)隨著阿里巴巴進(jìn)入云原生時(shí)代之后，也在逐步結(jié)合云原生做一些改進(jìn)，比如說 Apache Dubbo，會更好地去適配我們未來的微服務(wù) Service Mesh 架構(gòu)，它會理解 Istio 的 xDS 協(xié)議，成為一種數(shù)據(jù)面；比如 Nacos，它為 Service Mesh 的 Istio 提供 MCP 協(xié)議的對接，成為云原生微服務(wù)和傳統(tǒng)微服務(wù)互通的橋梁。

應(yīng)用

在開發(fā)領(lǐng)域和運(yùn)維領(lǐng)域之間，其實(shí)我認(rèn)為還有一個(gè)很大的空缺，就是專門用來連接整個(gè)開發(fā)和運(yùn)維的應(yīng)用這一塊。

對于開發(fā)階段，寫完代碼之后交付的是一個(gè)應(yīng)用包，而這個(gè)應(yīng)用包也是整個(gè)運(yùn)維系統(tǒng)上運(yùn)行的一個(gè)基礎(chǔ)顆粒。我們認(rèn)為現(xiàn)在在云原生階段，缺少了一個(gè)很好的應(yīng)用交付和運(yùn)維標(biāo)準(zhǔn)，大家在不同的公司會看到每個(gè)公司都有不一樣的運(yùn)維平臺，應(yīng)用的部署和交付都沒有辦法被標(biāo)準(zhǔn)化。我們現(xiàn)在進(jìn)入云原生時(shí)代，推崇的是標(biāo)準(zhǔn)、開放，所以我們認(rèn)為在這一塊上面還有很大的機(jī)會去做進(jìn)一步的應(yīng)用標(biāo)準(zhǔn)建設(shè)，這是我接下來想要和大家重點(diǎn)分享的一個(gè)話題。

云上應(yīng)用交付和運(yùn)維的痛點(diǎn)

先看一下云原生在交付和運(yùn)維方面有哪些痛點(diǎn)呢？

剛剛也講到了，在進(jìn)入到了微服務(wù)之后，我們面臨的一個(gè)問題就是應(yīng)用的實(shí)例數(shù)會越來越多，會到成百上千的規(guī)模不斷往上增長；另外還有我們部署的環(huán)境也變得越來越多，比如說現(xiàn)在有不同的云廠商，以及我們有很多專有云的自建機(jī)房的輸出；另外還有很多自建的環(huán)境，這些環(huán)境多樣化以及我們應(yīng)用在運(yùn)行時(shí)它會以容器的方式去運(yùn)行，可能還是以傳統(tǒng)的虛擬機(jī)的方式去運(yùn)行，或者它會以函數(shù)的方式去運(yùn)行，但是運(yùn)行時(shí)也會有很多不一致，比如不同的環(huán)境、或運(yùn)行時(shí)的不一致，會導(dǎo)致整個(gè)分布式運(yùn)維體系變得越來越復(fù)雜，它的監(jiān)控、日志采集也是一個(gè)很大的挑戰(zhàn)。

當(dāng)這些應(yīng)用已經(jīng)放到云上去運(yùn)行的時(shí)候，由于很多的云服務(wù)并沒有被標(biāo)準(zhǔn)化，很多這種云的能力需要集成到應(yīng)用上的時(shí)候，也會有很大集成的困難。而這些云上應(yīng)用運(yùn)維的痛點(diǎn)以前也有類似的，我們可以跟過往的解決方案做一個(gè)對比。

過往解決方案

首先，是類似 Ansible、Puppet 這些基礎(chǔ)設(shè)施運(yùn)維自動化的工具。這些工具對整個(gè)運(yùn)維效率起到了很大的提升作用，減輕了運(yùn)維同學(xué)的工作量，但是它使用的是一些自應(yīng)用的模塊，而且它的概念是偏向于腳本運(yùn)維的方式，非常的底層。

隨后出現(xiàn)了類似 Cloud Foundry 、Heroku 這種比較經(jīng)典的應(yīng)用平臺，這些應(yīng)用平臺是以應(yīng)用為中心去做運(yùn)維和交付，往上把運(yùn)維的工作進(jìn)行了一個(gè)抽象，按照 buildpack 的方式去做運(yùn)維和交付，通過 buildpack 的方式，可以簡化整個(gè)應(yīng)用運(yùn)維的工作，但是 buildpack 本身覆蓋的范圍比較窄，在運(yùn)維和交付方面，缺乏一些運(yùn)維交付的標(biāo)準(zhǔn)，所以它的可擴(kuò)展性是比較差的。

隨著 Docker 容器的橫空出世，打破了傳統(tǒng)基于 buildpack 的應(yīng)用交付模式，所以就出現(xiàn)了新一代的容器管理平臺，而 Kubernetes 成為了云原生時(shí)代一個(gè)新的容器平臺事實(shí)標(biāo)準(zhǔn)。Kubernetes 本身提供了很多基礎(chǔ)服務(wù)抽象，比如說 Deployment、Service。在社區(qū)里面它有一句很著名的定位：“Kubernetes is the platform for platforms.”也就是說，Kubernetes 定位是構(gòu)建平臺的平臺，能夠簡化構(gòu)建應(yīng)用平臺的復(fù)雜度，它不會再去做上層基于應(yīng)用的抽象。大家可以發(fā)現(xiàn)歷史總是那么相似，從過去的運(yùn)維工具到后來基于應(yīng)用的抽象，到現(xiàn)在容器出現(xiàn)打破運(yùn)維格局，重新對這個(gè)領(lǐng)域進(jìn)行洗牌，自然，在云原生時(shí)代需要一個(gè)對應(yīng)交付和運(yùn)維應(yīng)用的平臺。

從過往解決方案引發(fā)的思考

關(guān)于云原生時(shí)代的應(yīng)用抽象，我們要做一個(gè)思考：我們需要什么樣的應(yīng)用抽象呢？

首先，它需要解決我們運(yùn)維交付的一個(gè)復(fù)雜度，以及屏蔽底層細(xì)節(jié)差異。無論什么時(shí)候，都是應(yīng)用平臺需要解決的問題。另外，參考我們過去比較傳統(tǒng)的應(yīng)用平臺的問題，比如說 buildpack 這種方式，它存在不通用/不易于擴(kuò)展的問題，我們認(rèn)為接下來的應(yīng)用抽象，它應(yīng)該要具備在應(yīng)用運(yùn)維方面更加通用、可擴(kuò)展的描述能力。

除此之外，我們在推廣應(yīng)用抽象的時(shí)候，還是要采用開源和社區(qū)的方式去推進(jìn)，因?yàn)槲磥硪欢ㄊ歉訕?biāo)準(zhǔn)和開放的，我們推廣這個(gè)應(yīng)用抽象，就是希望有更多開發(fā)和運(yùn)維工作者，能夠給這個(gè)標(biāo)準(zhǔn)提供更多的建議，能夠通過整個(gè)社區(qū)進(jìn)一步推動整個(gè)應(yīng)用交付和運(yùn)維標(biāo)準(zhǔn)的發(fā)展。

Open Application Model - 開放應(yīng)用模型

在上個(gè)月中旬，阿里云和微軟聯(lián)合發(fā)布了“Open Application Model（開放應(yīng)用模型）”這一個(gè)開源項(xiàng)目。我們希望通過這個(gè)開放應(yīng)用模型，解決“在云原生時(shí)代缺乏一種應(yīng)用交付標(biāo)準(zhǔn)”的問題。（“Open Application Model -開放應(yīng)用模型”后面簡稱為“OAM”）

OAM 的三種角色

OAM 里面有三種不同的角色。

• 首先是應(yīng)用開發(fā)。很明顯，應(yīng)用開發(fā)是負(fù)責(zé)編寫業(yè)務(wù)邏輯的。比如說它會寫 Spark、Wordpress、Spring Cloud 等微服務(wù)的程序，它寫完這個(gè)微服務(wù)的程序之后呢，會按照 OAM 標(biāo)準(zhǔn)編寫一段應(yīng)用定義；
• 第二個(gè)是應(yīng)用運(yùn)維的角色，就是負(fù)責(zé)應(yīng)用的交付與運(yùn)維；
• 第三個(gè)角色是基礎(chǔ)設(shè)施平臺?；A(chǔ)設(shè)施平臺在 OAM 里的一個(gè)重要定位，在于它要將自己的基礎(chǔ)服務(wù)能力抽象成可被復(fù)用、被重用的模塊，并提供給開發(fā)和運(yùn)維人員去使用。

OAM 核心概念解讀

下面為大家解讀以上的三個(gè)角色對應(yīng)的三個(gè)核心概念。

• 首先是 Component。它是被開發(fā)人員定義的一個(gè)可被重用的應(yīng)用組件，這個(gè)應(yīng)用組件描述的就是這個(gè)應(yīng)用它運(yùn)行的方式；
• 第二個(gè)重要概念是 Trait。它是一種應(yīng)用的運(yùn)維特征，是由基礎(chǔ)設(shè)施平臺這個(gè)角色定義的，而這個(gè)定義它包含了可組合的應(yīng)用運(yùn)維特征，這個(gè)特征是其實(shí)是這個(gè)平臺可以提供出來的某種運(yùn)維能力抽象；
• 最后一個(gè)是 ApplicationConfiguration。運(yùn)維人員負(fù)責(zé)把 Component 和 Trait 兩個(gè)綁定在一起，并且作為一個(gè)具體的實(shí)例化，生成了這個(gè)應(yīng)用配置（ApplicationConfiguration）之后，就可以把應(yīng)用部署起來。

用 OAM 描述的應(yīng)用配置示意

接下來是一個(gè)具體的用 OAM 描述的應(yīng)用配置文件（上圖文件做了一定內(nèi)容簡化，具體以下面的 yaml 文本為準(zhǔn)）。

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
 name: wordpress
spec:
 workloadType: core.oam.dev/v1alpha1.Server
 containers:
 - name: test
 image: docker/wordpress:latest
 env:
 - name: key1
 fromParam: test-key
 ports:
 - type: tcp
 containerPort: 9999
 name: http
 parameters:
 - name: test-key
 type: string
---
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
 name: wordpress-app
spec:
 components:
 - name: wordpress
 instanceName: wordpress-instance
 parameterValues:
 - name: replicas
 value: 3
 - name: test-key
 value: value-from-ops
 traits:
 - name: service
 parameterValues:
 - name: portMapping
 value: 
 - protocol: "TCP"
 port: 52014
 targetPort: 9999
 - name: rollout
 parameterValues:
 - name: canaryReplicas
 value: 1

由運(yùn)維人員編寫的 ApplicationConfiquration 文件，它將 Component 和 Trait 兩個(gè)概念綁定在一起。首先里面描述運(yùn)維要部署一個(gè)叫 wordpress-app的應(yīng)用，它引用了一個(gè)叫 wordpress 的 Component。這是開發(fā)人員在另一個(gè)配置文件 Component 定義的，他除了定義 wordpress 應(yīng)如何運(yùn)行（比如配置鏡像位置）以外，還允許運(yùn)維配置運(yùn)行實(shí)例的副本數(shù)以及運(yùn)行時(shí)環(huán)境變量 test-key 的值。在 ApplicationConfiquration 里同時(shí)引用了兩個(gè)運(yùn)維特征，運(yùn)維人員會填寫這個(gè)應(yīng)用需要一個(gè)負(fù)載均衡，要做外網(wǎng)的端口映射，部署時(shí)需要采用金絲雀發(fā)布策略。這個(gè)文件對應(yīng)到實(shí)際上的部署階段會變成如上圖右側(cè)所示，上面會有一個(gè)負(fù)載均衡，比如在云上運(yùn)行時(shí)，就會使用 SLB 去做負(fù)載均衡的自動分發(fā)，會給它配置外網(wǎng) IP 和內(nèi)外端口映射。

通過這個(gè)簡單的 yaml 文件，大家就可以了解到這個(gè)應(yīng)用怎么做快速部署，并且描述運(yùn)維要具備什么能力。

OAM 的設(shè)計(jì)理念

給大家總結(jié)一下，我所認(rèn)為的 OAM 的重要的設(shè)計(jì)理念。

• 首先第一個(gè)是配置即代碼。所有的 OAM 上面的運(yùn)維和交付的操作都會使用配置的方式，完全通過 yaml 文件去完成所有的交付運(yùn)維配置；
• 第二個(gè)是依賴倒置。這個(gè)依賴倒置有點(diǎn)像 JAVA Spring 開發(fā)者使用 IoC 或者 DI 的這種模式，在寫這個(gè)應(yīng)用配置的時(shí)候，只是依賴應(yīng)用標(biāo)準(zhǔn)抽象，而這個(gè)標(biāo)準(zhǔn)抽象背后的實(shí)現(xiàn)實(shí)際上是由 OAM 的運(yùn)行時(shí)去做“注入”，通過這個(gè)方式就使得我們的應(yīng)用運(yùn)維不依賴于我們具體的運(yùn)行環(huán)境；
• 第三個(gè)是重要的設(shè)計(jì)理念就是角色關(guān)注點(diǎn)分離。剛剛上面講過 OAM 里的三種不同的重要角色：開發(fā)、運(yùn)維以及基礎(chǔ)設(shè)置平臺。這三種角色只需要編寫對應(yīng)不同的配置文件，互相解耦。這樣開發(fā)不需要關(guān)心應(yīng)用是怎么運(yùn)維的，只需要把運(yùn)行時(shí)需要的配置暴露并描述出來；基礎(chǔ)平臺只需要把平臺能力提煉成 Trait；最終由運(yùn)維人員把開發(fā)需要的參數(shù)和運(yùn)維需要的能力進(jìn)行結(jié)合。
• 第四個(gè)就是整個(gè) OAM 的設(shè)計(jì)是一個(gè)可組合可擴(kuò)展的方式。它會通過讓我們剛剛說到的 Traits 能夠按需組合、重用、移植和擴(kuò)展。

EDAS & OAM

上面我們說了這么多其實(shí)都是比較一些概念性的東西，接下來我們看一下，在阿里巴巴的云產(chǎn)品 EDAS 對 OAM 所做一些落地方面的嘗試，這也是第一個(gè)在實(shí)際生產(chǎn)上面基于 OAM 對外可開放使用的云產(chǎn)品。

下面會用 EDAS 為例，給大家做一個(gè)介紹，講解一下 OAM 具體怎么運(yùn)作。

EDAS 是什么？

首先介紹一下 EDAS 是阿里云上面的一個(gè)云產(chǎn)品，它扮演著我剛才講到的類似于一個(gè)應(yīng)用平臺的一個(gè)角色：

• EDAS 從開發(fā)方面就提供了開發(fā)框架給我們云上的開發(fā)者去使用；
• 開發(fā)者開發(fā)完程序之后，會把應(yīng)用交付到 EDAS 上面去進(jìn)行部署；
• 與此同時(shí) EDAS 會對這個(gè)應(yīng)用進(jìn)行監(jiān)控診斷，根據(jù)容量情況進(jìn)行實(shí)例彈性伸縮；
• EDAS 會對上面的微服務(wù)進(jìn)行注冊發(fā)現(xiàn)、服務(wù)治理；
• 提供應(yīng)用的高可用保護(hù)，比如限流降級、熔斷等。

這些是 EDAS 作為應(yīng)用平臺在阿里云上的產(chǎn)品定位。

EDAS 支持 OAM 的運(yùn)行示意圖

那么它在支持 OAM 在運(yùn)行的時(shí)候又是什么樣的呢？

如圖所示，一個(gè)開發(fā)人員，他首先需要去編寫一個(gè)按照 OAM 標(biāo)準(zhǔn)為參考去定義一個(gè) Component。這個(gè) Component 里面會定義如開發(fā)應(yīng)用類型是什么樣子，比如它的鏡像路徑、它需要多大的存儲空間，以及它的環(huán)境變量是什么樣子，這些都是開發(fā)人員在開發(fā)的時(shí)候需要去描述的內(nèi)容。

對于阿里云來說，它是一個(gè)基礎(chǔ)設(shè)施平臺的身份。它在上面其實(shí)有很多運(yùn)維的能力，比如說像監(jiān)控報(bào)警、塊存儲、需要發(fā)布策略和彈性伸縮的策略。EDAS 會把這些平臺能力抽象成一個(gè)一個(gè)獨(dú)立的 Trait，開放給運(yùn)維人員使用。

在需要部署應(yīng)用的時(shí)候，運(yùn)維人員會選擇 EDAS 上提供的 Trait 并填寫相關(guān)參數(shù)，同時(shí)也設(shè)置好開發(fā)人員的 Component 的參數(shù)，這作為一次應(yīng)用部署，生成了 ApplicationConfiguration 提交給 EDAS。

EDAS 作為 OAM 的運(yùn)行時(shí)，在讀取到這份部署配置后，它會去實(shí)現(xiàn) Trait 提供相應(yīng)的運(yùn)維特征動作，比如說運(yùn)維描述需要一個(gè)塊存儲，那么 EDAS 會在阿里云上面去申請一個(gè)具體的塊存儲對象，并綁定到這個(gè)應(yīng)用上面。同時(shí) EDAS 會提供一個(gè)容器環(huán)境（如 Kubernetes）去運(yùn)行開發(fā)者定義的 Component 的工作負(fù)載，比如購買 ECS，配置好容器環(huán)境，把環(huán)境變量傳給容器，使 Component 能夠正常運(yùn)行。

以上就是整個(gè) EDAS 支持 OAM 的一個(gè)運(yùn)行示意圖。

EDAS 支持 OAM 的對比

那么 EDAS 在支持 OAM 之后，它的使用情況又會發(fā)生怎樣的變化呢？

在沒有使用 OAM 的時(shí)候，客戶需要和系統(tǒng)解釋我要做些什么事情、我要怎么做這個(gè)事情。比如說，他需要申請 5G NAS 存儲，并且要把它掛載到某個(gè)機(jī)器的某個(gè)目錄上面；或者他還有一個(gè)監(jiān)控的需求，他需要告訴系統(tǒng)現(xiàn)在有一個(gè)業(yè)務(wù)指標(biāo)文件，需要被監(jiān)控采集，他要去設(shè)置這個(gè)文件的指標(biāo)處理規(guī)則，最后把這個(gè)指標(biāo)存儲成時(shí)間序列數(shù)據(jù)，并且設(shè)置報(bào)警閾值。在使用 OAM 之后，它就變成了描述式，他只要描述我需要什么東西就夠了。比如開發(fā)者可以說這個(gè)目錄上面需要有 5G 的外置可讀寫存儲就夠了，具體這 5G 存儲怎么申請是由 OAM 運(yùn)行時(shí)去幫助解決的。另外，在監(jiān)控的時(shí)候，他只需要描述自己的這個(gè)應(yīng)用需要被監(jiān)控、哪個(gè)指標(biāo)需要被監(jiān)控并報(bào)警就夠了，他不需要了解對接到具體是哪一個(gè)監(jiān)控系統(tǒng)，他不需要去關(guān)心這些事情。

原來很多云產(chǎn)品或者原來很多自定義運(yùn)維平臺都是需要依賴特定的 API 或者 CLI 這種模式去做運(yùn)維的，這個(gè)時(shí)候應(yīng)用要遷移到另外一個(gè)運(yùn)維平臺，它的代碼、鏡像、二進(jìn)制包可以帶走，但是它的很多運(yùn)維的設(shè)施、運(yùn)維的配置包括監(jiān)控的配置，這些東西都是只能留在這個(gè)平臺上的，沒有辦法很容易地遷移到另外一個(gè)平臺上面。而通過 OAM，可以將平臺所有的運(yùn)維配置以 yaml 導(dǎo)出，并且能夠很快地導(dǎo)入到另外一個(gè)環(huán)境、甚至是另一個(gè)應(yīng)用平臺上，整個(gè)系統(tǒng)會變得更加標(biāo)準(zhǔn)。

在使用 OAM 以前，運(yùn)維人員需要去學(xué)習(xí)很多知識，比如使用的是 Kubernetes，他需要去了解整個(gè)容器和 Kubernetes 的使用方式，他要做定制和拓展就需要去學(xué)習(xí) Kubernetes。如果他是從虛擬機(jī)的模式切換到容器的運(yùn)維模式，這個(gè)時(shí)候他就需要很多時(shí)間去理解容器和虛擬機(jī)運(yùn)維之間的差異。遷移到 OAM 之后，相當(dāng)于 OAM 屏蔽了整個(gè)平臺底層的細(xì)節(jié)，所以使得整個(gè)運(yùn)維平臺的 OAM 配置沒有多大差別。

最后一點(diǎn)就是定制的難度上面。剛剛也講到過，這個(gè)是 OAM 的一個(gè)重要的目標(biāo)，讓整個(gè)運(yùn)維的擴(kuò)展能夠更容易的被發(fā)現(xiàn)、被組合、被替換。在使用 OAM 之前，運(yùn)維的邏輯都散落在腳本里面，或者說都在運(yùn)維平臺內(nèi)部，這個(gè)時(shí)候很難去統(tǒng)一管理。而一套 OAM 的運(yùn)行環(huán)境是可以自描述的，可以非常容易把平臺提供的 Trait、Component 工作負(fù)載羅列出來，使用者可以替換或增加新的 Traits，在運(yùn)行應(yīng)用時(shí)可以自由選擇和組合這些 Traits。

OAM 后續(xù)規(guī)劃，歡迎社區(qū)貢獻(xiàn)

以上講了 OAM 相關(guān)的一些基本內(nèi)容，實(shí)際上 OAM 剛剛開源還有很多需要補(bǔ)充和完善的地方，這里也列出了 OAM 上最近這半年的計(jì)劃，希望大家能夠參與社區(qū)，在上面貢獻(xiàn)更多的想法。

主要有幾個(gè)規(guī)劃：

• 易用性方面 提供 Kubernetes 一鍵導(dǎo)入工具； 增加應(yīng)用之間的依賴描述； 不斷完善 OAM 的標(biāo)準(zhǔn)定義（Spec）； 社區(qū)提供更多的 OAM 上的實(shí)踐案例；
• OAM 開發(fā)方面 盡量進(jìn)一步去做開發(fā)的簡化，包括一些字段的校驗(yàn)工具、編寫 Controller 框架，方便更高效的開發(fā) Trait 等實(shí)現(xiàn)； 另外，OAM 它本身不僅僅是一個(gè)標(biāo)準(zhǔn)，它還提供了一個(gè)名為 Rudr 的參考開源實(shí)現(xiàn)；
• 功能方面 提供新的基礎(chǔ) Traits 去簡化應(yīng)用運(yùn)維管理，比如常見的流量管理、藍(lán)綠發(fā)布； 能對接更多的應(yīng)用平臺，比如說像 Windows、IoT 這樣的平臺。

最后，我的演講就到這里，謝謝大家！喜歡 OAM 的朋友可以掃描下方二維碼，謝謝！

更多詳細(xì)信息請關(guān)注“阿里巴巴云原生”。

“ 阿里巴巴云原生微信公眾號（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)公眾號?！?/p>

作者：司徒放（姬風(fēng)） 阿里巴巴技術(shù)專家

本文為云棲社區(qū)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。