作者 | 張磊 阿裡雲進階技術專家、CNCF 官方大使，CNCF 應用傳遞領域 co-chair，Kubernetes 項目資深維護者
美國西部時間 2020 年 5 月 27 日，阿裡雲和微軟雲共同宣布，Open Application Model （OAM） 社群攜手知名混合雲管理項目 Crossplane，聯合釋出了 OAM 在 Kubernetes 平台上的标準實作與核心依賴庫項目。新版的 OAM 核心依賴庫以 Go 語言編寫，由來自阿裡、微軟和 Crossplane 三方的工程師共同維護，能夠以 Kubernetes 插件或者 Go 語言依賴庫的方式被社群所使用。在内置了 OAM 核心依賴庫之後，Crossplane 項目也實作了“華麗更新”，從原先的混合雲管理項目一躍成為了一個能夠面向所有雲環境、提供“應用 + 雲服務”一站式管理與傳遞體驗的 OAM 标準實作平台。
- OAM 核心依賴庫項目： https://github.com/crossplane/oam-kubernetes-runtime
- Crossplane 項目： https://github.com/crossplane/crossplane
OAM 是阿裡雲與微軟雲在 2019 年末聯合推出的标準化雲原生應用管理模型。相比于傳統 PaaS 封閉、不能同“以 Operator 為基礎的雲原生生态”銜接的現狀，基于 OAM 和 Kubernetes 建構的現代雲原生應用管理平台，本質上是一個“以應用為中心”的 Kubernetes ，保證了這個應用平台在能夠無縫接入整個雲原生生态。同時，OAM 可以進一步屏蔽掉容器基礎設施的複雜性和差異性，為平台的使用者帶來低心智負擔的、标準化的、一緻的應用管理與傳遞體驗。
OAM 項目：
https://github.com/oam-dev/spec“Cloud 2.0”時代的應用定義模型
應用容器技術自誕生開始，就以“徹底改變了軟體打包與分發方式”的魅力迅速征服了幾乎所有的雲廠商與資料中心。 不過，軟體打包與分發方式的革新，并沒有能夠讓軟體本身的定義與描述發生本質的變化，基于 K8s 的應用管理體驗，也沒有讓業務研發與運維的工作變得更簡單。
實際上，Kubernetes 帶來的雲原生技術革命，在于實作了基礎設施層的标準化和抽象，但這一層抽象距離業務研發與運維還是太過遙遠了。一個最典型的例子，直到今天，Kubernetes 裡面始終都沒有“應用”這個概念，它提供的是更細粒度的“工作負載”原語，比如 Deployment 或者 DaemonSet。而在實際環境中，一個應用往往是由一系列獨立元件的組合，比如一個“PHP 應用容器”和一個“資料庫執行個體”組成的電商網站；一個“參數服務節點”和一個“工作節點”組成的機器學習訓練任務；一個由“Deployment + StatefulSet + HPA + Service + Ingress”組成的 Kubernetes 應用。
而 OAM 項目，是一個基于 Kubernetes API 資源模型（Kubernetes Resource Model）的标準應用定義規範。在 OAM 中，它強調一個現代應用是多個元件的集合，而非一個簡單的工作負載或者 K8s Operator。是以在 OAM 的語境中，一個 PHP 容器和它所依賴的資料庫，以及它所需要使用的各種雲服務，都是一個“電商網站”應用的組成部分。更進一步的，OAM 把這個應用所需的“運維政策”也認為是一個應用的一部分，比如這個 PHP 容器所需的 HPA（水準自動擴充政策）：
與此同時，OAM 模型依據“關注點分離”的思想，對上述應用的組成部分進行了分類。其中，應用研發所關注的部分被稱作“Component”，應用運維所關注的運維政策等被稱作“Traits” 和 “Scope”，如下所示：
自釋出 6 個月以來，OAM 模型正在迅速成為了阿裡和微軟内部進行應用定義的事實标準，并且已經成為了阿裡雲企業級分布式應用服務 EDAS 等雲端應用管理産品的核心架構。在 2020 年 4 月，國外知名技術媒體 TheNewStack 提出了一個
《為什麼 Kubernetes 時代的應用如此與衆不同》的疑問，引發了巨大的反響。TheNewStack 在文中把 OAM 稱作“Cloud 2.0 時代的應用定義模型”，并在最後講到：
“OAM 的核心思想是，業務研發人員的工作以從編寫源代碼開始，到建構完容器鏡像結束。而應用運維人員或者應用管理平台會負責将這個應用所需的所有元件配置和部署為一個完整的應用程式。而我們已經能夠看到，在以 Kubernetes 為代表的 Cloud 2.0 時代，一個現代化應用程式是由許多對象組成的，其中一些對象已經超出了業務研發人員的認知範圍。 這可能是網際網路曆史上第一次研發人員不再完全控制自己開發制品的完整生命周期。”
解讀：OAM Kubernetes 核心依賴庫
社群在落地 OAM 模型的過程中，提出了很多關于 OAM 統一實作庫的訴求。一方面，一個統一的實作庫能夠更好的對規範進行诠釋，增強複用性；另一方面，大量共性需求比如依賴管理、參數傳遞、沖突管理、編排等，也可以在這個核心依賴庫建構。
是以在本次釋出中，三方工程師使用 Go 語言開發了一個 OAM Kubernetes 核心依賴庫。這個項目的名字叫做
oam-kubernetes-runtime，它的主要功能包括：
- 穩定且統一的 OAM 核心：所有基于 OAM 的應用傳遞平台的建構者都将基于這個依賴庫開始建構，OAM 核心将會是統一的。同時該依賴庫也由三方的頂級工程師共同維護，確定其具備生産級的穩定性。
- 可漂移的 Workload/Trait 能力：基于這個依賴庫建構的 OAM 平台，上面新增的所有 Workload 和 Trait，都可以複用和漂移到其他同樣基于該依賴庫的平台，像插件一樣可以輕松插拔，不需要做代碼的變動。
- 通用邏輯内置：所有公共的邏輯，如依賴管理等，也将内置到這個依賴庫中，使得大家使用 OAM 基于 K8s 建構以“應用為中心”的管理平台更加容易。
而 OAM 核心依賴庫最大的使用場景，就是建構開放、使用者友好、标準化的應用管理平台。這樣一個管理平台的核心架構如下圖所示。
在這樣的平台中，平台建構者可以基于 OAM 子產品化添加 Workload 和 Trait，而這些子產品也可以在不同的 OAM 平台複用。比如，Workload 可以包括函數、容器、雲資源、虛拟機等多種不同形态的工作負載；Trait 則可以包含流量管理、釋出政策、彈性政策、可觀測性政策等多種不同的運維能力。最終，平台本身可以通過不同 Workload 和 Trait 組合，來對最終使用者提供差異化的場景。
使用起來非常便利，可以直接按照
樣例代碼中所描述的那樣，通過一個 main 函數把這個依賴庫運作起來。OAM Kubernetes 核心依賴庫本身是一個 Kubernetes Controller ，通過響應 ApplicationConfiguration 的變化來建立和管理 Workload 和 Trait。具體來說，OAM Kubernetes 核心依賴庫會提供兩個非常重要的功能：
功能一：無縫對接現有 K8s API 資源
oam-kubernetes-runtime 支援将任何現有的 CRD 被聲明為 Workload 或者 Trait 而不需要做任何改動。當然，這也意味着任何 K8s 原生的 API 資源也可以被聲明為 Workload 或者 Trait。通過這種設計，現有 Kubernetes 叢集裡的所有能力進行 OAM 化變得就”易如反掌“了。這也使得 OAM 成為了結構化管理目前叢集中的各種 Operator 的不二之選。
功能二：Workload 與 Trait 标準化互動機制
前面的例子告訴我們，OAM 可以子產品式的接入、部署和管理任何 Kubernetes 工作負載和運維能力。而這些工作負載和運維能力之間的互動，則需要通過第二個功能來實作标準化和統一化。
這個互動關系在 Kubernetes 裡非常常見，比如一個 Deployment 和 HPA（自動水準擴充控制器） 的協作關系。這裡 Deployment 在 OAM 模型中就屬于 Workload，而 HPA 則屬于 Trait。是以說在 OAM 當中，一個 ApplicationConfiguration 裡引用的 Workload 和 Trait 也必須通過協作的方式來操作具體的 k8s 資源。舉個例子，一個 HPA Trait 該如何去水準擴充上述 OpenFaaS 的 Function Workload 呢？這個協作關系就得依靠 OAM 插件來去管理了。
在 OAM Kubernetes 核心依賴庫中，它會通過一種叫做
DuckTyping（鴨子類型）的機制，在 Trait 對象上自動記錄與之綁定的 Workload 關系，進而實作了工作負載（Workload）和運維能力（Trait）之間的雙向記錄關系：
- 給定任何一工作負載（Workload） ，系統可以直接擷取到同它綁定的所有運維能力（Trait）；
- 給定任何一個運維能力（Trait），系統可以直接擷取到它所要作用于的所有工作負載（Workload）。
這種雙向記錄關系，對于在一個大規模的生産環境中保證運維能力的可管理性、可發現性和應用的穩定性，是至關重要的。
除此之外，OAM 社群還 Kubernetes 核心依賴庫中目前還有幾個非常重要的基礎功能同大家見面，包括：
- Component 版本管理 ：對于任何一次 Component 的變更，OAM 平台都可以記錄下來它對于的變更曆史，進而允許運維通過 Trait 來進行復原、藍綠釋出等運維操作。
- Component 間依賴關系與參數傳遞 ：該功能将解決大家亟需的元件間依賴問題，包括 Component 之間的依賴和傳輸傳遞，以及 Trait 與 Component 之間的依賴和參數傳遞。
- Component 運維政策 ：該功能将允許研發在 Component 中聲明對運維能力的訴求，指導運維人員或者系統給這個 Component 綁定和配置合理的運維能力。
OAM + Crossplane：定義雲原生應用的下一階段
可能大家會有這樣一個疑問，為什麼這一次 OAM 會選擇 Crossplane 社群來作為 OAM Kubernetes 核心依賴庫的合作團隊呢？
我們知道，OAM 的主要思想是以 Kubernetes API 資源模型為核心、以結構化和平台無關的方式，對應用進行定義和管理。這裡的“應用”，既包括待運作的程式本身（比如一個容器），也包括它需要的所有其他依賴（比如雲資源和運維能力的描述）。而如果你熟悉 Kubernetes 生态的話，就會知道這種通過 Kubernetes API 模型“定義一切”的思想，也正是 Crossplane 項目的設計理念。
隻不過，作為 Kubernetes 混合雲場景中的佼佼者，Crossplane 項目以前的關注點是以結構化和平台無關的方式對雲服務進行定義和管理而已。而在經過 OAM 化之後，今天的 Crossplane 項目，已經成為了 OAM 的标準實作，使用 OAM 作為其應用定義的入口，并且直接通過 OAM Component 的方式來為使用者暴露出平台無關的雲服務定義。這樣，一個符合 OAM 規範的待運作程式、運維能力和它所依賴的雲服務，就可以組成一個整體，在不同的平台之間無縫漂移了。
這種平台無關的應用定義範式，使得應用研發人員隻需要通過 OAM 規範來描述他們的應用程式，那麼該應用程式就可以在任何 Kubernetes 群集或者 Serverless 應用平台甚至邊緣環境上運作而無需對應用描述做任何修改。 這種體驗，一直是阿裡雲和微軟雲在努力的建構“雲、邊、端”一緻性體驗的核心思想。 而此次 OAM 與 Crossplane 的深度協作，也終于将标準應用定義和标準化的雲服務管理能力統一起來，進而使“雲端應用傳遞”的故事真正成為了現實。
在未來，這兩個社群将進一步緊密協作，在 OAM Kubernetes 标準實作中提供更好的 Component 和 Trait 可移植性、互操作性，在 OAM 生态中上線更加豐富的應用運維能力，共同建立一個專注于标準應用程式與基礎設施管理的開放社群。
如果你有任何想法，非常歡迎釘釘掃碼加群同我們交流！
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公衆号。”