作者 | 孫健波（天元）  阿里巴巴技術專家

**導讀**：[OAM](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487043&idx=1&sn=088457a1dccd6578290c9291a968bf16&chksm=fae5058ccd928c9a618c2763c8dcf74348e2198ba532a1095f0d9292da44f8d1b2a9f8cf4342&scene=21#wechat_redirect) 是阿里巴巴聯合微軟在社群推出的一款用於構建和交付雲原生應用的標準規範，旨在透過全新的應用定義、運維、分發與交付模型，推動應用管理技術向“輕運維”的方向邁進，全力開啟下一代雲原生 DevOps 的技術革命。

# 背景
OAM 是阿里巴巴聯合微軟在社群推出的一款用於構建和交付雲原生應用的標準規範，之前我們已經發布過一系列介紹文章，為方便大家查閱，連結和介紹如下：

- [《4 個概念，1 個動作，讓應用管理變得更簡單》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487823&idx=1&sn=d7423bb8184832333dd780359fa74fe6&chksm=fae51a80cd929396fc10b7491ca3d57530719151652448a45a59317cec15c211b8d73c8119ef&token=1751791050&lang=zh_CN#rd)：具體而詳實的介紹了 OAM 方方面面的細節；
- [《給 K8s API “做減法”：阿里巴巴雲原生應用管理的挑戰和實踐》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487713&idx=1&sn=ef0745dbea7e3d0966f1098192f54abc&chksm=fae51b2ecd929238471aabcc0708e29ff03ebd0c374b9e46d565339284f5bc48461c788700ad&token=1751791050&lang=zh_CN#rd)：介紹了我們在探索出 OAM 之前的一些實踐背景以及為什麼會自然而然地設計出 OAM 這樣的應用模型；
- [《OAM 加持下的 Kubernetes PaaS 應用管理實踐》](https://mp.weixin.qq.com/s/csBteKivJnDc1Zndl24fvw)：圍繞目前常見的基於 Kubernetes 構建 PaaS 的各類解決方案，介紹了 OAM 如何將這些方案有機結合並最終統一，然後進一步的透過標準化模組化的組織，發揮生態的力量，使得彼此協作互惠互利成為可能；
- [《開放應用模型操作指南（一）：雲服務“一鍵接入” OAM 體系》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247488401&idx=1&sn=f14de7dafcf48204356d66125f951b0b&chksm=fae5185ecd929148b7dce5f3ae5bbf1e2d31c368ca9420a0ed8fa1a30d33b11c992621583f21&token=1751791050&lang=zh_CN#rd)：以雲資源為例，介紹瞭如何介入 OAM 體系的方法和實踐。

在上面的幾篇文章中，我們介紹了為什麼雲原生應用需要標準定義，以及 OAM 模型到底是什麼樣子的。今天則為大家介紹 OAM 本身有哪些價值，即回答為什麼是使用 OAM 來作為應用標準模型。

# AWS 構建 ECS CLI v2 的開發原則
本月初（2019 年 12 月），AWS 釋出了 [ECS CLI v2](https://aws.amazon.com/cn/blogs/containers/announcing-the-amazon-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，完整包含了一個應用方方面面的資源。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/130c7b6c13684117801a091d42d53799.png)

## 平臺無關、執行時無關
OAM 應用定義並不限定你底層的平臺和實際執行時，你完全可以執行在 K8s 以外的平臺，不管是 ECS、Docker、又或是 FaaS (Serverless)，自然也不存在廠商鎖定的問題。如果你的應用滿足 Serverless 的條件，那麼針對該應用的 OAM 描述，天然就可以執行在支援 OAM 規範的 Serverless 執行時。
![2.png](https://ucc.alicdn.com/pic/developer-ecology/be63d69f62554a1fa6f99b0cff5f061b.png)

在支援 OAM 的不同環境中，你便可以使用統一的應用描述，打造無差別的應用交付。就如下圖所示，對應使用者，他們只要描述統一的應用配置，便可以在不同的環境達到一致的應用體驗。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/4994300312c94d3ab421ed326459109a.png)

## 基礎設施即程式碼
雲原生的普及很大程度上推動了基礎設施即程式碼的實現，K8s 作為一個基礎設施平臺，透過宣告式 API，讓使用者習慣了 透過 Yaml 檔案描述需要的資源，這其實就是基礎設施即程式碼的實現。 而 OAM 更進一步，還將原生 K8s 中沒有包含的基礎設施資源也統一定義起來，透過配置 OAM 規範的 yaml（程式碼）來使用基礎設施。

如今阿里雲上的[資源編排產品 ROS](https://www.aliyun.com/product/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，使用者指定它的元件是資料庫的。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/68f07c7cb0084d0fa20c509e3e7cc68d.png)

## 運維能力管理
使用者希望運維能力也是應用生命週期的一部分，而 OAM 正是如此，透過繫結 Trait，來定義一個 Component 所使用到的運維能力，從而把運維能力也加入到應用描述中，方便底層基礎設施統一管理。

如下圖所示，一個應用包含兩部分元件，一個 web 服務和一個資料庫， 資料庫元件應該具有資料備份的能力，而 web 服務則可以被訪問、可以彈性擴縮容。這些能力由 OAM 的直譯器（即 OAM 的實現層）統一管理，從此運維能力繫結出現衝突也不再是煩惱。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/a201fd09a9f7451aae9435a811413494.png)

## 透明化的整合
就像 Docker 映象解決了長久以來開發、測試、生產環境不一致一樣，統一而標準化的 OAM 應用描述也讓不同系統之間的整合變得透明而標準化。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/8d68b57cd50d4d7782303349ae274879.png)

## 不同的角色關注點分離
OAM 也將原先 K8s All-in-one 的複雜 API 做了一定層次的解耦，分為應用研發（管理 Component）、應用運維（將 Component 組合並繫結 Trait 變成 AppConfig）、以及基礎設施提供方（提供 OAM 的解釋能力對映到實際的基礎設施）三大角色，不同角色分工協作，從而整體簡化單個角色關注的內容。使得不同角色可以更聚焦更專業的做好本角色的工作。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/6f4cced0de5840c4a5636a0d4b87d7b2.png)

## 彈性可擴充套件
OAM 應用定義是彈性、可擴充套件的，你可以透過擴充套件 Workload 來定義不同型別的工作負載，你也可以透過自定義的 Trait 來描述你的運維能力，而且都可以與現有的 K8s 體系裡面 CRD+Operator 的擴充套件方式完美結合。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/91678ece3aaf44e89e7851c273f4df9b.png)

## 模組化協作
OAM 透過關注點分離的思想，將應用分為研發、運維和基礎設施三個層次，同時又為研發的 Workload 和運維的 Trait 提供了模組化協作的能力，大大提高了複用能力。
![9.png](https://ucc.alicdn.com/pic/developer-ecology/b9e4e30f548147edabf5864b7e4890ff.png)

當模組化的 Workload 和 Trait 越來越多，就會形成這些元件的市場，使用者可以在 CRD Registry 這樣的註冊中心，快速找到適合自己的應用的架構（Workload），以及自己需要使用的運維能力（Trait）。構建應用將越來越簡單。

# 未來
相信應用的構建會越來越簡單，基礎設施的選擇會根據使用者的架構需求自動匹配，使用者可以真正享受到雲平臺化的紅利，快速複用已有的模組化能力，而 OAM 也將成為應用雲原生化的必然選擇。

目前，阿里巴巴團隊正在上游貢獻和維護這套技術，如果大家有什麼問題或者反饋，也非常歡迎與我們在上游或者釘釘聯絡。

參與方式：

- 釘釘掃碼進入 OAM 專案中文討論群

![10.png](https://ucc.alicdn.com/pic/developer-ecology/c9ac995e6e2944bf8e48973af05babff.png)

- [透過 Gitter 直接參與討論](https://gitter.im/oam-dev/)
- [OAM 開源實現地址](https://github.com/oam-dev/rudr)
- [點選 star 一下](https://github.com/oam-dev/rudr)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

OAM 深入解讀：OAM 為雲原生應用帶來哪些價值？

相關文章