溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
作者 | 孫健波（天元）? 阿里巴巴技術專家
導讀：OAM?是阿里巴巴聯合微軟在社區推出的一款用于構建和交付云原生應用的標準規范，旨在通過全新的應用定義、運維、分發與交付模型，推動應用管理技術向“輕運維”的方向邁進，全力開啟下一代云原生 DevOps 的技術革命。
OAM 是阿里巴巴聯合微軟在社區推出的一款用于構建和交付云原生應用的標準規范，之前我們已經發布過一系列介紹文章，為方便大家查閱，鏈接和介紹如下：
在上面的幾篇文章中，我們介紹了為什么云原生應用需要標準定義，以及 OAM 模型到底是什么樣子的。今天則為大家介紹 OAM 本身有哪些價值，即回答為什么是使用 OAM 來作為應用標準模型。
本月初（2019 年 12 月），AWS 發布了 ECS CLI v2，這是自 2015 年發布 v1 以后，四年來首次發布的大版本更新，這次發布的 v2 版本命令行工具將更關注端到端的應用體驗，即管理從源代碼開發到應用部署的全方位應用交付流程。他們基于多年來收到的用戶反饋總結了四條 CLI 的開發原則：
默認創建現代化的應用。創建的現代化應用默認滿足這幾個特征：無服務化 (serverless)，基礎設施即代碼 (infrastructure as code)，可觀測 (observable)，安全 (secure)；
用戶應該考慮的是架構，而不是基礎設施。開發者構建微服務的時候，不應該指定 VPC、負載均衡配置亦或是復雜的 Pipeline 流程配置。開發者可以對云服務一無所知，但是他們應該制定應用到底屬于哪種類型，即應用應該適配哪種架構，基礎設施應該根據應用指定的架構自動匹配資源；
運維也應該是工作流的一部分。應用的構建、開發、部署只是應用生命周期中由應用開發者負責的一部分。應用的全生命周期中還應該包含運維的部分，即問題排查和解決；
這幾條原則與其說是 ECS CLI 的開發原則，不如說是用戶的訴求，用戶希望他們的應用是現代化的（或者說云原生化的）；用戶希望他們指定架構，而不是具體的基礎設施資源；用戶希望運維能力也被統一管理進應用的生命周期；用戶希望應用的變更交付可以持續、透明、方便的對接并被 CI/CD 系統管理。
針對上述用戶的訴求，我們一個個來看 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 也將成為應用云原生化的必然選擇。
目前，阿里巴巴團隊正在上游貢獻和維護這套技術，如果大家有什么問題或者反饋，也非常歡迎與我們在上游或者釘釘聯系。
參與方式：
“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術圈。”
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
