作者 | 孫健波（天元）? 阿里巴巴技術(shù)專家
導讀：OAM?是阿里巴巴聯(lián)合微軟在社區(qū)推出的一款用于構(gòu)建和交付云原生應用的標準規(guī)范，旨在通過全新的應用定義、運維、分發(fā)與交付模型，推動應用管理技術(shù)向“輕運維”的方向邁進，全力開啟下一代云原生 DevOps 的技術(shù)革命。
OAM 是阿里巴巴聯(lián)合微軟在社區(qū)推出的一款用于構(gòu)建和交付云原生應用的標準規(guī)范，之前我們已經(jīng)發(fā)布過一系列介紹文章，為方便大家查閱，鏈接和介紹如下：
在上面的幾篇文章中，我們介紹了為什么云原生應用需要標準定義，以及 OAM 模型到底是什么樣子的。今天則為大家介紹 OAM 本身有哪些價值，即回答為什么是使用 OAM 來作為應用標準模型。
本月初（2019 年 12 月），AWS 發(fā)布了 ECS CLI v2，這是自 2015 年發(fā)布 v1 以后，四年來首次發(fā)布的大版本更新，這次發(fā)布的 v2 版本命令行工具將更關(guān)注端到端的應用體驗，即管理從源代碼開發(fā)到應用部署的全方位應用交付流程。他們基于多年來收到的用戶反饋總結(jié)了四條 CLI 的開發(fā)原則：
默認創(chuàng)建現(xiàn)代化的應用。創(chuàng)建的現(xiàn)代化應用默認滿足這幾個特征：無服務化 (serverless)，基礎(chǔ)設(shè)施即代碼 (infrastructure as code)，可觀測 (observable)，安全 (secure)；
用戶應該考慮的是架構(gòu)，而不是基礎(chǔ)設(shè)施。開發(fā)者構(gòu)建微服務的時候，不應該指定 VPC、負載均衡配置亦或是復雜的 Pipeline 流程配置。開發(fā)者可以對云服務一無所知，但是他們應該制定應用到底屬于哪種類型，即應用應該適配哪種架構(gòu)，基礎(chǔ)設(shè)施應該根據(jù)應用指定的架構(gòu)自動匹配資源；
運維也應該是工作流的一部分。應用的構(gòu)建、開發(fā)、部署只是應用生命周期中由應用開發(fā)者負責的一部分。應用的全生命周期中還應該包含運維的部分，即問題排查和解決；
這幾條原則與其說是 ECS CLI 的開發(fā)原則，不如說是用戶的訴求，用戶希望他們的應用是現(xiàn)代化的（或者說云原生化的）；用戶希望他們指定架構(gòu)，而不是具體的基礎(chǔ)設(shè)施資源；用戶希望運維能力也被統(tǒng)一管理進應用的生命周期；用戶希望應用的變更交付可以持續(xù)、透明、方便的對接并被 CI/CD 系統(tǒng)管理。
針對上述用戶的訴求，我們一個個來看 OAM 是如何滿足的，同時也能看出 OAM 在其中發(fā)揮的價值。
如下圖所示，你可以看到運行 OAM 的一個應用配置，使用 K8s 的 API spec，完整包含了一個應用方方面面的資源。
OAM 應用定義并不限定你底層的平臺和實際運行時，你完全可以運行在 K8s 以外的平臺，不管是 ECS、Docker、又或是 FaaS (Serverless)，自然也不存在廠商鎖定的問題。如果你的應用滿足 Serverless 的條件，那么針對該應用的 OAM 描述，天然就可以運行在支持 OAM 規(guī)范的 Serverless 運行時。
在支持 OAM 的不同環(huán)境中，你便可以使用統(tǒng)一的應用描述，打造無差別的應用交付。就如下圖所示，對應用戶，他們只要描述統(tǒng)一的應用配置，便可以在不同的環(huán)境達到一致的應用體驗。
云原生的普及很大程度上推動了基礎(chǔ)設(shè)施即代碼的實現(xiàn)，K8s 作為一個基礎(chǔ)設(shè)施平臺，通過聲明式 API，讓用戶習慣了 通過 Yaml 文件描述需要的資源，這其實就是基礎(chǔ)設(shè)施即代碼的實現(xiàn)。 而 OAM 更進一步，還將原生 K8s 中沒有包含的基礎(chǔ)設(shè)施資源也統(tǒng)一定義起來，通過配置 OAM 規(guī)范的 yaml（代碼）來使用基礎(chǔ)設(shè)施。
如今阿里云上的資源編排產(chǎn)品 ROS 的 OAM 實現(xiàn)就是這樣一個典范，你完全可以通過 OAM 的配置拉起一個云上的基礎(chǔ)設(shè)施資源。
讓我們來實際看一個例子，為拉起一個 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 的資源棧模板文件，最終拉起云上的資源。
用戶的訴求其實是應用的架構(gòu)，而不是具體使用哪種基礎(chǔ)設(shè)施資源。而 OAM 通過 "WorkloadType" 來解決這個訴求，通過描述一個應用的 WorkloadType 來定義應用的架構(gòu)，這個 WorkloadType 可以是簡單的無狀態(tài)應用 "Server"，表示應用可復制、可訪問、并作為守護進程長久運行；也可以是一個數(shù)據(jù)庫類型的應用 "RDS"，對應啟動一個云上的 RDS 實例。
用戶的組件 "Component" 通過指定 "WorkloadType" 選擇具體的架構(gòu)模板，多個 Component 構(gòu)成了完整的架構(gòu)。
使用 OAM 應用定義讓用戶真正關(guān)心的是架構(gòu)，而不是具體的基礎(chǔ)設(shè)施。
如下圖所示，OAM 的一個應用描述，用戶指定它的應用需要一個外網(wǎng)訪問能力，而不是指定一個 SLB，用戶指定它的組件是數(shù)據(jù)庫的。
用戶希望運維能力也是應用生命周期的一部分，而 OAM 正是如此，通過綁定 Trait，來定義一個 Component 所使用到的運維能力，從而把運維能力也加入到應用描述中，方便底層基礎(chǔ)設(shè)施統(tǒng)一管理。
如下圖所示，一個應用包含兩部分組件，一個 web 服務和一個數(shù)據(jù)庫， 數(shù)據(jù)庫組件應該具有數(shù)據(jù)備份的能力，而 web 服務則可以被訪問、可以彈性擴縮容。這些能力由 OAM 的解釋器（即 OAM 的實現(xiàn)層）統(tǒng)一管理，從此運維能力綁定出現(xiàn)沖突也不再是煩惱。
就像 Docker 鏡像解決了長久以來開發(fā)、測試、生產(chǎn)環(huán)境不一致一樣，統(tǒng)一而標準化的 OAM 應用描述也讓不同系統(tǒng)之間的集成變得透明而標準化。
OAM 也將原先 K8s All-in-one 的復雜 API 做了一定層次的解耦，分為應用研發(fā)（管理 Component）、應用運維（將 Component 組合并綁定 Trait 變成 AppConfig）、以及基礎(chǔ)設(shè)施提供方（提供 OAM 的解釋能力映射到實際的基礎(chǔ)設(shè)施）三大角色，不同角色分工協(xié)作，從而整體簡化單個角色關(guān)注的內(nèi)容。使得不同角色可以更聚焦更專業(yè)的做好本角色的工作。
OAM 應用定義是彈性、可擴展的，你可以通過擴展 Workload 來定義不同類型的工作負載，你也可以通過自定義的 Trait 來描述你的運維能力，而且都可以與現(xiàn)有的 K8s 體系里面 CRD+Operator 的擴展方式完美結(jié)合。
OAM 通過關(guān)注點分離的思想，將應用分為研發(fā)、運維和基礎(chǔ)設(shè)施三個層次，同時又為研發(fā)的 Workload 和運維的 Trait 提供了模塊化協(xié)作的能力，大大提高了復用能力。
當模塊化的 Workload 和 Trait 越來越多，就會形成這些組件的市場，用戶可以在 CRD Registry 這樣的注冊中心，快速找到適合自己的應用的架構(gòu)（Workload），以及自己需要使用的運維能力（Trait）。構(gòu)建應用將越來越簡單。
相信應用的構(gòu)建會越來越簡單，基礎(chǔ)設(shè)施的選擇會根據(jù)用戶的架構(gòu)需求自動匹配，用戶可以真正享受到云平臺化的紅利，快速復用已有的模塊化能力，而 OAM 也將成為應用云原生化的必然選擇。
目前，阿里巴巴團隊正在上游貢獻和維護這套技術(shù)，如果大家有什么問題或者反饋，也非常歡迎與我們在上游或者釘釘聯(lián)系。
參與方式：
“阿里巴巴云原生關(guān)注微服務、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術(shù)圈?！?/p>
另外有需要云服務器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。
