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