作者 | 司徒放（姬風） 阿裡巴巴技術專家
本文整理自司徒放（姬風）題目為《開源的黃金時代，阿裡巴巴雲原生開源的探索與實踐》的演講。
關注“阿裡巴巴雲原生”公衆号，回複關鍵詞“開源”即可下載下傳本文 PPT。
導讀：從擁抱開源、貢獻開源、自主開源，到賦能開源，開源已更新為阿裡技術戰略之一，且正為開發者源源不斷地輸送切實可見的價值。雲原生是阿裡開源的重要領域，短短幾年，以 K8s 為核心的雲原生開源生态迅猛發展，這是全世界開發者合作傑出成果，也是開源力量的結晶。
阿裡巴巴的應用架構演進
大家好，我是司徒放，目前在阿裡巴巴負責阿裡雲的應用平台和微服務産品線。在和大家分享我們在雲原生應用方面的探索之前，先和大家介紹一下阿裡巴巴在整個應用架構方面的演進曆程。
今年是阿裡巴巴成立的二十周年，二十年前，阿裡巴巴使用的這個應用的架構，還是單體應用模式，它有很多的業務子產品都在一個應用裡面，各個業務都在一個應用裡面開發，這個架構的一個好處是簡單，也非常容易部署，對小的創業公司來說是很友善的。它的缺點在于團隊變大變多之後，不能滿足快速疊代要求，因為每一個業務它需要去釋出的時候，都需要在同一個應用上做修改、釋出，當這個業務疊代非常快的時候，它同時的一個并發修改就非常多。
是以在 2008 年的時候，阿裡巴巴就引進到了微服務架構，隻是當時并不叫微服務，而是叫服務化架構。各個業務模式就按照服務的邊界來拆分，這是比較松耦合的一種方式，一個微服務應用是無狀态的，可以快速擴充執行個體。而且某個執行個體有異常比如當機時會可以自動下線，不會影響整個服務架構的穩定性。微服務架構也比較容易推動整個網際網路公司的快速疊代需求。
大概三年前，阿裡巴巴就走向了雲原生的架構。這是一個天然适合雲的、能夠充分利用雲的彈性能力和标準雲服務，給整個阿裡巴巴的電商降低機器的準備成本，特别是類似于在大促雙十一需要很多機器去支撐，但是大促結束之後，這些機器有一半以上就可以歸還到雲上。
這個時候，阿裡巴巴就在往雲原生的方向去邁進，而且通過整個雲服務能夠更快地加快整個阿裡巴巴的技術建構。而且雲原生架構，是一個比較開放、标準、沒有侵入性的技術架構。
阿裡巴巴在雲原生的開源程序
在阿裡巴巴進入到了雲原生之後，我們看一下阿裡巴巴在開源方面做了一些什麼樣的事情呢？
運維領域
首先，整個雲原生架構裡面最重要、最關鍵的一個基石就是 Kubernetes。
阿裡巴巴在兩年前，就在大規模的落地 Kubernetes 的整套技術用來做我們機器資源的排程和管理。在内部有數十萬台級别的機器以及上百萬級别的容器規模，直接拿開源的 Kubernetes 到這種生産規模下是用不起來的，是以我們在上面做了很多性能優化，包括針對規模上的改造，使得整個 Kubernetes 在阿裡巴巴内部能夠很順暢地 run 起來，阿裡巴巴也在不斷地向上遊去貢獻我們内部實踐和優化的代碼。
除了 Kubernetes 之外，在整個雲原生生态裡還有像容器、etcd，我們也在不停地優化它的規模能力以及安全隔離方面的一些能力。同時，也開源了内部使用的蜻蜓（Dragonfly）用來做大規模的鏡像快速分發。
開發領域
在開發領域，阿裡巴巴很早就已經使用了微服務架構，也對外進行了開源，比如說 Apache Dubbo，這個是比較知名的 RPC 架構；還有去年開源的 Nacos ，作為阿裡巴巴集團支撐大規模的服務注冊發現、配置推送一個元件；另外，還有 Spring Cloud Alibaba，基于阿裡開源的元件提供了一整套 Spring Cloud 最佳實作；還有像支撐整個阿裡巴巴高可用的 Sentinel、以及 Apache RocketMQ 消息隊列，都是我們在開發領域做的開源。
這些元件其實随着阿裡巴巴進入雲原生時代之後，也在逐漸結合雲原生做一些改進，比如說 Apache Dubbo，會更好地去适配我們未來的微服務 Service Mesh 架構，它會了解 Istio 的 xDS 協定，成為一種資料面；比如 Nacos，它為 Service Mesh 的 Istio 提供 MCP 協定的對接，成為雲原生微服務和傳統微服務互通的橋梁。
應用
在開發領域和運維領域之間，其實我認為還有一個很大的空缺，就是專門用來連接配接整個開發和運維的應用這一塊。
對于開發階段，寫完代碼之後傳遞的是一個應用包，而這個應用包也是整個運維系統上運作的一個基礎顆粒。我們認為現在在雲原生階段，缺少了一個很好的應用傳遞和運維标準，大家在不同的公司會看到每個公司都有不一樣的運維平台，應用的部署和傳遞都沒有辦法被标準化。我們現在進入雲原生時代，推崇的是标準、開放，是以我們認為在這一塊上面還有很大的機會去做進一步的應用标準建設，這是我接下來想要和大家重點分享的一個話題。
雲上應用傳遞和運維的痛點
先看一下雲原生在傳遞和運維方面有哪些痛點呢？
剛剛也講到了，在進入到了微服務之後，我們面臨的一個問題就是應用的執行個體數會越來越多，會到成百上千的規模不斷往上增長；另外還有我們部署的環境也變得越來越多，比如說現在有不同的雲廠商，以及我們有很多專有雲的自建機房的輸出；另外還有很多自建的環境，這些環境多樣化以及我們應用在運作時它會以容器的方式去運作，可能還是以傳統的虛拟機的方式去運作，或者它會以函數的方式去運作，但是運作時也會有很多不一緻，比如不同的環境、或運作時的不一緻，會導緻整個分布式運維體系變得越來越複雜，它的監控、日志采集也是一個很大的挑戰。
當這些應用已經放到雲上去運作的時候，由于很多的雲服務并沒有被标準化，很多這種雲的能力需要內建到應用上的時候，也會有很大內建的困難。而這些雲上應用運維的痛點以前也有類似的，我們可以跟過往的解決方案做一個對比。
過往解決方案
首先，是類似 Ansible、Puppet 這些基礎設施運維自動化的工具。這些工具對整個運維效率起到了很大的提升作用，減輕了運維同學的工作量，但是它使用的是一些自應用的子產品，而且它的概念是偏向于腳本運維的方式，非常的底層。
随後出現了類似 Cloud Foundry 、Heroku 這種比較經典的應用平台，這些應用平台是以應用為中心去做運維和傳遞，往上把運維的工作進行了一個抽象，按照 buildpack 的方式去做運維和傳遞，通過 buildpack 的方式，可以簡化整個應用運維的工作，但是 buildpack 本身覆寫的範圍比較窄，在運維和傳遞方面，缺乏一些運維傳遞的标準，是以它的可擴充性是比較差的。
随着 Docker 容器的橫空出世，打破了傳統基于 buildpack 的應用傳遞模式，是以就出現了新一代的容器管理平台，而 Kubernetes 成為了雲原生時代一個新的容器平台事實标準。Kubernetes 本身提供了很多基礎服務抽象，比如說 Deployment、Service。在社群裡面它有一句很著名的定位：“Kubernetes is the platform for platforms.”也就是說，Kubernetes 定位是建構平台的平台，能夠簡化建構應用平台的複雜度，它不會再去做上層基于應用的抽象。大家可以發現曆史總是那麼相似，從過去的運維工具到後來基于應用的抽象，到現在容器出現打破運維格局，重新對這個領域進行洗牌，自然，在雲原生時代需要一個對應傳遞和運維應用的平台。
從過往解決方案引發的思考
關于雲原生時代的應用抽象，我們要做一個思考：我們需要什麼樣的應用抽象呢？
首先，它需要解決我們運維傳遞的一個複雜度，以及屏蔽底層細節差異。無論什麼時候，都是應用平台需要解決的問題。另外，參考我們過去比較傳統的應用平台的問題，比如說 buildpack 這種方式，它存在不通用/不易于擴充的問題，我們認為接下來的應用抽象，它應該要具備在應用運維方面更加通用、可擴充的描述能力。
除此之外，我們在推廣應用抽象的時候，還是要采用開源和社群的方式去推進，因為未來一定是更加标準和開放的，我們推廣這個應用抽象，就是希望有更多開發和運維工作者，能夠給這個标準提供更多的建議，能夠通過整個社群進一步推動整個應用傳遞和運維标準的發展。
Open Application Model - 開放應用模型
在上個月中旬，阿裡雲和微軟聯合釋出了“Open Application Model（開放應用模型）”這一個開源項目。我們希望通過這個開放應用模型，解決“在雲原生時代缺乏一種應用傳遞标準”的問題。（“Open Application Model -開放應用模型”後面簡稱為“OAM”）
OAM 的三種角色
OAM 裡面有三種不同的角色。
- 首先是應用開發。很明顯，應用開發是負責編寫業務邏輯的。比如說它會寫 Spark、Wordpress、Spring Cloud 等微服務的程式，它寫完這個微服務的程式之後呢，會按照 OAM 标準編寫一段應用定義；
- 第二個是應用運維的角色，就是負責應用的傳遞與運維；
- 第三個角色是基礎設施平台。基礎設施平台在 OAM 裡的一個重要定位，在于它要将自己的基礎服務能力抽象成可被複用、被重用的子產品，并提供給開發和運維人員去使用。
OAM 核心概念解讀
下面為大家解讀以上的三個角色對應的三個核心概念。
- 首先是 Component。它是被開發人員定義的一個可被重用的應用元件，這個應用元件描述的就是這個應用它運作的方式；
- 第二個重要概念是 Trait。它是一種應用的運維特征，是由基礎設施平台這個角色定義的，而這個定義它包含了可組合的應用運維特征，這個特征是其實是這個平台可以提供出來的某種運維能力抽象；
- 最後一個是 ApplicationConfiguration。運維人員負責把 Component 和 Trait 兩個綁定在一起，并且作為一個具體的執行個體化，生成了這個應用配置（ApplicationConfiguration）之後，就可以把應用部署起來。
用 OAM 描述的應用配置示意
接下來是一個具體的用 OAM 描述的應用配置檔案（上圖檔案做了一定内容簡化，具體以下面的 yaml 文本為準）。
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 由運維人員編寫的 ApplicationConfiquration 檔案，它将 Component 和 Trait 兩個概念綁定在一起。首先裡面描述運維要部署一個叫 wordpress-app的應用，它引用了一個叫 wordpress 的 Component。這是開發人員在另一個配置檔案 Component 定義的，他除了定義 wordpress 應如何運作（比如配置鏡像位置）以外，還允許運維配置運作執行個體的副本數以及運作時環境變量
test-key
的值。在 ApplicationConfiquration 裡同時引用了兩個運維特征，運維人員會填寫這個應用需要一個負載均衡，要做外網的端口映射，部署時需要采用金絲雀釋出政策。這個檔案對應到實際上的部署階段會變成如上圖右側所示，上面會有一個負載均衡，比如在雲上運作時，就會使用 SLB 去做負載均衡的自動分發，會給它配置外網 IP 和内外端口映射。
通過這個簡單的 yaml 檔案，大家就可以了解到這個應用怎麼做快速部署，并且描述運維要具備什麼能力。
OAM 的設計理念
給大家總結一下，我所認為的 OAM 的重要的設計理念。
- 首先第一個是配置即代碼。所有的 OAM 上面的運維和傳遞的操作都會使用配置的方式，完全通過 yaml 檔案去完成所有的傳遞運維配置；
- 第二個是依賴倒置。這個依賴倒置有點像 JAVA Spring 開發者使用 IoC 或者 DI 的這種模式，在寫這個應用配置的時候，隻是依賴應用标準抽象，而這個标準抽象背後的實作實際上是由 OAM 的運作時去做“注入”，通過這個方式就使得我們的應用運維不依賴于我們具體的運作環境；
- 第三個是重要的設計理念就是角色關注點分離。剛剛上面講過 OAM 裡的三種不同的重要角色：開發、運維以及基礎設定平台。這三種角色隻需要編寫對應不同的配置檔案，互相解耦。這樣開發不需要關心應用是怎麼運維的，隻需要把運作時需要的配置暴露并描述出來；基礎平台隻需要把平台能力提煉成 Trait；最終由運維人員把開發需要的參數和運維需要的能力進行結合。
- 第四個就是整個 OAM 的設計是一個可組合可擴充的方式。它會通過讓我們剛剛說到的 Traits 能夠按需組合、重用、移植和擴充。
EDAS & OAM
上面我們說了這麼多其實都是比較一些概念性的東西，接下來我們看一下，在阿裡巴巴的雲産品 EDAS 對 OAM 所做一些落地方面的嘗試，這也是第一個在實際生産上面基于 OAM 對外可開放使用的雲産品。
下面會用 EDAS 為例，給大家做一個介紹，講解一下 OAM 具體怎麼運作。
EDAS 是什麼？
首先介紹一下 EDAS 是阿裡雲上面的一個雲産品，它扮演着我剛才講到的類似于一個應用平台的一個角色：
- EDAS 從開發方面就提供了開發架構給我們雲上的開發者去使用；
- 開發者開發完程式之後，會把應用傳遞到 EDAS 上面去進行部署；
- 與此同時 EDAS 會對這個應用進行監控診斷，根據容量情況進行執行個體彈性伸縮；
- EDAS 會對上面的微服務進行注冊發現、服務治理；
- 提供應用的高可用保護，比如限流降級、熔斷等。
這些是 EDAS 作為應用平台在阿裡雲上的産品定位。
EDAS 支援 OAM 的運作示意圖
那麼它在支援 OAM 在運作的時候又是什麼樣的呢？
如圖所示，一個開發人員，他首先需要去編寫一個按照 OAM 标準為參考去定義一個 Component。這個 Component 裡面會定義如開發應用類型是什麼樣子，比如它的鏡像路徑、它需要多大的存儲空間，以及它的環境變量是什麼樣子，這些都是開發人員在開發的時候需要去描述的内容。
對于阿裡雲來說，它是一個基礎設施平台的身份。它在上面其實有很多運維的能力，比如說像監控報警、塊存儲、需要釋出政策和彈性伸縮的政策。EDAS 會把這些平台能力抽象成一個一個獨立的 Trait，開放給運維人員使用。
在需要部署應用的時候，運維人員會選擇 EDAS 上提供的 Trait 并填寫相關參數，同時也設定好開發人員的 Component 的參數，這作為一次應用部署，生成了 ApplicationConfiguration 送出給 EDAS。
EDAS 作為 OAM 的運作時，在讀取到這份部署配置後，它會去實作 Trait 提供相應的運維特征動作，比如說運維描述需要一個塊存儲，那麼 EDAS 會在阿裡雲上面去申請一個具體的塊存儲對象，并綁定到這個應用上面。同時 EDAS 會提供一個容器環境（如 Kubernetes）去運作開發者定義的 Component 的工作負載，比如購買 ECS，配置好容器環境，把環境變量傳給容器，使 Component 能夠正常運作。
以上就是整個 EDAS 支援 OAM 的一個運作示意圖。
EDAS 支援 OAM 的對比
那麼 EDAS 在支援 OAM 之後，它的使用情況又會發生怎樣的變化呢？
在沒有使用 OAM 的時候，客戶需要和系統解釋我要做些什麼事情、我要怎麼做這個事情。比如說，他需要申請 5G NAS 存儲，并且要把它挂載到某個機器的某個目錄上面；或者他還有一個監控的需求，他需要告訴系統現在有一個業務名額檔案，需要被監控采集，他要去設定這個檔案的名額處理規則，最後把這個名額存儲成時間序列資料，并且設定報警門檻值。在使用 OAM 之後，它就變成了描述式，他隻要描述我需要什麼東西就夠了。比如開發者可以說這個目錄上面需要有 5G 的外置可讀寫存儲就夠了，具體這 5G 存儲怎麼申請是由 OAM 運作時去幫助解決的。另外，在監控的時候，他隻需要描述自己的這個應用需要被監控、哪個名額需要被監控并報警就夠了，他不需要了解對接到具體是哪一個監控系統，他不需要去關心這些事情。
原來很多雲産品或者原來很多自定義運維平台都是需要依賴特定的 API 或者 CLI 這種模式去做運維的，這個時候應用要遷移到另外一個運維平台，它的代碼、鏡像、二進制包可以帶走，但是它的很多運維的設施、運維的配置包括監控的配置，這些東西都是隻能留在這個平台上的，沒有辦法很容易地遷移到另外一個平台上面。而通過 OAM，可以将平台所有的運維配置以 yaml 導出，并且能夠很快地導入到另外一個環境、甚至是另一個應用平台上，整個系統會變得更加标準。
在使用 OAM 以前，運維人員需要去學習很多知識，比如使用的是 Kubernetes，他需要去了解整個容器和 Kubernetes 的使用方式，他要做定制和拓展就需要去學習 Kubernetes。如果他是從虛拟機的模式切換到容器的運維模式，這個時候他就需要很多時間去了解容器和虛拟機運維之間的差異。遷移到 OAM 之後，相當于 OAM 屏蔽了整個平台底層的細節，是以使得整個運維平台的 OAM 配置沒有多大差别。
最後一點就是定制的難度上面。剛剛也講到過，這個是 OAM 的一個重要的目标，讓整個運維的擴充能夠更容易的被發現、被組合、被替換。在使用 OAM 之前，運維的邏輯都散落在腳本裡面，或者說都在運維平台内部，這個時候很難去統一管理。而一套 OAM 的運作環境是可以自描述的，可以非常容易把平台提供的 Trait、Component 工作負載羅列出來，使用者可以替換或增加新的 Traits，在運作應用時可以自由選擇群組合這些 Traits。
OAM 後續規劃，歡迎社群貢獻
以上講了 OAM 相關的一些基本内容，實際上 OAM 剛剛開源還有很多需要補充和完善的地方，這裡也列出了 OAM 上最近這半年的計劃，希望大家能夠參與社群，在上面貢獻更多的想法。
主要有幾個規劃：
- 易用性方面
- 提供 Kubernetes 一鍵導入工具；
- 增加應用之間的依賴描述；
- 不斷完善 OAM 的标準定義（Spec）；
- 社群提供更多的 OAM 上的實踐案例；
- OAM 開發方面
- 盡量進一步去做開發的簡化，包括一些字段的校驗工具、編寫 Controller 架構，友善更高效的開發 Trait 等實作；
- 另外，OAM 它本身不僅僅是一個标準，它還提供了一個名為 Rudr 的參考開源實作；
- 功能方面
- 提供新的基礎 Traits 去簡化應用運維管理，比如常見的流量管理、藍綠釋出；
- 能對接更多的應用平台，比如說像 Windows、IoT 這樣的平台。
最後，我的演講就到這裡，謝謝大家！喜歡 OAM 的朋友可以掃描下方二維碼，謝謝！
更多詳細資訊請關注“
阿裡巴巴雲原生”。
“ 阿裡巴巴雲原生微信公衆号（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”