作者 | 孫健波（天元） 阿裡巴巴技術專家
導讀：
OAM 是阿裡巴巴聯合微軟在社群推出的一款用于建構和傳遞雲原生應用的标準規範，旨在通過全新的應用定義、運維、分發與傳遞模型，推動應用管理技術向“輕運維”的方向邁進，全力開啟下一代雲原生 DevOps 的技術革命。背景
OAM 是阿裡巴巴聯合微軟在社群推出的一款用于建構和傳遞雲原生應用的标準規範，之前我們已經釋出過一系列介紹文章，為友善大家查閱，連結和介紹如下：
- 《4 個概念，1 個動作，讓應用管理變得更簡單》 ：具體而詳實的介紹了 OAM 方方面面的細節；
- 《給 K8s API “做減法”：阿裡巴巴雲原生應用管理的挑戰和實踐》 ：介紹了我們在探索出 OAM 之前的一些實踐背景以及為什麼會自然而然地設計出 OAM 這樣的應用模型；
- 《OAM 加持下的 Kubernetes PaaS 應用管理實踐》 ：圍繞目前常見的基于 Kubernetes 建構 PaaS 的各類解決方案，介紹了 OAM 如何将這些方案有機結合并最終統一，然後進一步的通過标準化子產品化的組織，發揮生态的力量，使得彼此協作互惠互利成為可能；
- 《開放應用模型操作指南（一）：雲服務“一鍵接入” OAM 體系》 ：以雲資源為例，介紹了如何介入 OAM 體系的方法和實踐。
在上面的幾篇文章中，我們介紹了為什麼雲原生應用需要标準定義，以及 OAM 模型到底是什麼樣子的。今天則為大家介紹 OAM 本身有哪些價值，即回答為什麼是使用 OAM 來作為應用标準模型。
AWS 建構 ECS CLI v2 的開發原則
本月初（2019 年 12 月），AWS 釋出了
ECS CLI v2，這是自 2015 年釋出 v1 以後，四年來首次釋出的大版本更新，這次釋出的 v2 版本指令行工具将更關注端到端的應用體驗，即管理從源代碼開發到應用部署的全方位應用傳遞流程。他們基于多年來收到的使用者回報總結了四條 CLI 的開發原則：
- 預設建立現代化的應用。建立的現代化應用預設滿足這幾個特征：無服務化 (serverless)，基礎設施即代碼 (infrastructure as code)，可觀測 (observable)，安全 (secure)；
- 使用者應該考慮的是架構，而不是基礎設施。開發者建構微服務的時候，不應該指定 VPC、負載均衡配置亦或是複雜的 Pipeline 流程配置。開發者可以對雲服務一無所知，但是他們應該制定應用到底屬于哪種類型，即應用應該适配哪種架構，基礎設施應該根據應用指定的架構自動比對資源；
- 運維也應該是工作流的一部分。應用的建構、開發、部署隻是應用生命周期中由應用開發者負責的一部分。應用的全生命周期中還應該包含運維的部分，即問題排查和解決；
- 應用傳遞是持續的。應用的更新變更也應該友善地內建到 CI/CD 系統中。
這幾條原則與其說是 ECS CLI 的開發原則，不如說是使用者的訴求，使用者希望他們的應用是現代化的（或者說雲原生化的）；使用者希望他們指定架構，而不是具體的基礎設施資源；使用者希望運維能力也被統一管理進應用的生命周期；使用者希望應用的變更傳遞可以持續、透明、友善的對接并被 CI/CD 系統管理。
OAM 模型的價值
針對上述使用者的訴求，我們一個個來看 OAM 是如何滿足的，同時也能看出 OAM 在其中發揮的價值。
雲原生化
- OAM 應用定義是聲明式的，即面向終态的，它的格式與 K8s 的 API 一緻，可以與 K8s 的 CRD 無縫對接，直接作為 Custom Resource 的 Object 部署到 K8s；
- OAM 應用定義是自包含的，通過 OAM 定義的描述可以找到包含一個應用生命周期中方方面面所有的資訊。
如下圖所示，你可以看到運作 OAM 的一個應用配置，使用 K8s 的 API spec，完整包含了一個應用方方面面的資源。
平台無關、運作時無關
OAM 應用定義并不限定你底層的平台和實際運作時，你完全可以運作在 K8s 以外的平台，不管是 ECS、Docker、又或是 FaaS (Serverless)，自然也不存在廠商鎖定的問題。如果你的應用滿足 Serverless 的條件，那麼針對該應用的 OAM 描述，天然就可以運作在支援 OAM 規範的 Serverless 運作時。
在支援 OAM 的不同環境中，你便可以使用統一的應用描述，打造無差别的應用傳遞。就如下圖所示，對應使用者，他們隻要描述統一的應用配置，便可以在不同的環境達到一緻的應用體驗。
基礎設施即代碼
雲原生的普及很大程度上推動了基礎設施即代碼的實作，K8s 作為一個基礎設施平台，通過聲明式 API，讓使用者習慣了 通過 Yaml 檔案描述需要的資源，這其實就是基礎設施即代碼的實作。 而 OAM 更進一步，還将原生 K8s 中沒有包含的基礎設施資源也統一定義起來，通過配置 OAM 規範的 yaml（代碼）來使用基礎設施。
如今阿裡雲上的
資源編排産品 ROS的 OAM 實作就是這樣一個典範，你完全可以通過 OAM 的配置拉起一個雲上的基礎設施資源。
讓我們來實際看一個例子，為拉起一個 NAS 持久化存儲，其中包含兩個 ROS 的資源，分别為
NAS FileSystem
和
NAS MountTarget
。
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
name: nasFileSystem
annotations:
version: v1.0.0
description: >
component schematic that describes the nas filesystem.
spec:
workloadType: ros.aliyun.com/v1alpha1.NAS_FileSystem
workloadSettings:
ProtocolType: NFS
StorageType: Performance
Description: xxx
expose:
- name: fileSystemOut
---
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
name: nasMountTarget
annotations:
version: v1.0.0
description: >
component schematic that describes the nas filesystem.
spec:
workloadType: ros.aliyun.com/v1alpha1.NAS_MountTarget
workloadSettings:
NetworkType: VPC
AccessGroupName: xxx
FileSystemId: ${fileSystemOut.FileSystemId}
consume:
- name: fileSystemOut
expose:
- name: moutTargetOut
---
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
name: nas-demo
spec:
components:
- componentName: nasMountTarget
traits:
- name: DeletionPolicy
properties: "Retain"
- componentName: nasFileSystem
traits:
- name: DeletionPolicy
properties: "Retain" 在定義中，你可以看到 NAS MountTarget 使用了 NAS FileSystem 輸出的 FileSystemId，最終這個 yaml 會由 ROS 的 OAM Controller 翻譯為 ROS 的資源棧模闆檔案，最終拉起雲上的資源。
關心架構而不是基礎設施
使用者的訴求其實是應用的架構，而不是具體使用哪種基礎設施資源。而 OAM 通過 "WorkloadType" 來解決這個訴求，通過描述一個應用的 WorkloadType 來定義應用的架構，這個 WorkloadType 可以是簡單的無狀态應用 "Server"，表示應用可複制、可通路、并作為守護程序長久運作；也可以是一個資料庫類型的應用 "RDS"，對應啟動一個雲上的 RDS 執行個體。
使用者的元件 "Component" 通過指定 "WorkloadType" 選擇具體的架構模闆，多個 Component 構成了完整的架構。
使用 OAM 應用定義讓使用者真正關心的是架構，而不是具體的基礎設施。
如下圖所示，OAM 的一個應用描述，使用者指定它的應用需要一個外網通路能力，而不是指定一個 SLB，使用者指定它的元件是資料庫的。
運維能力管理
使用者希望運維能力也是應用生命周期的一部分，而 OAM 正是如此，通過綁定 Trait，來定義一個 Component 所使用到的運維能力，進而把運維能力也加入到應用描述中，友善底層基礎設施統一管理。
如下圖所示，一個應用包含兩部分元件，一個 web 服務和一個資料庫， 資料庫元件應該具有資料備份的能力，而 web 服務則可以被通路、可以彈性擴縮容。這些能力由 OAM 的解釋器（即 OAM 的實作層）統一管理，從此運維能力綁定出現沖突也不再是煩惱。
透明化的內建
就像 Docker 鏡像解決了長久以來開發、測試、生産環境不一緻一樣，統一而标準化的 OAM 應用描述也讓不同系統之間的內建變得透明而标準化。
不同的角色關注點分離
OAM 也将原先 K8s All-in-one 的複雜 API 做了一定層次的解耦，分為應用研發（管理 Component）、應用運維（将 Component 組合并綁定 Trait 變成 AppConfig）、以及基礎設施提供方（提供 OAM 的解釋能力映射到實際的基礎設施）三大角色，不同角色分工協作，進而整體簡化單個角色關注的内容。使得不同角色可以更聚焦更專業的做好本角色的工作。
彈性可擴充
OAM 應用定義是彈性、可擴充的，你可以通過擴充 Workload 來定義不同類型的工作負載，你也可以通過自定義的 Trait 來描述你的運維能力，而且都可以與現有的 K8s 體系裡面 CRD+Operator 的擴充方式完美結合。
子產品化協作
OAM 通過關注點分離的思想，将應用分為研發、運維和基礎設施三個層次，同時又為研發的 Workload 和運維的 Trait 提供了子產品化協作的能力，大大提高了複用能力。
當子產品化的 Workload 和 Trait 越來越多，就會形成這些元件的市場，使用者可以在 CRD Registry 這樣的注冊中心，快速找到适合自己的應用的架構（Workload），以及自己需要使用的運維能力（Trait）。建構應用将越來越簡單。
未來
相信應用的建構會越來越簡單，基礎設施的選擇會根據使用者的架構需求自動比對，使用者可以真正享受到雲平台化的紅利，快速複用已有的子產品化能力，而 OAM 也将成為應用雲原生化的必然選擇。
目前，阿裡巴巴團隊正在上遊貢獻和維護這套技術，如果大家有什麼問題或者回報，也非常歡迎與我們在上遊或者釘釘聯系。
參與方式：
- 釘釘掃碼進入 OAM 項目中文讨論群
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”