![0.png](https://ucc.alicdn.com/pic/developer-ecology/0410593173e04a90bc171c9d08ca1247.png)

作者 | 李響、張磊

從 2019 年初開始，阿里巴巴雲原生應用平臺團隊開始逐步在整個阿里經濟體內，基於標準應用定義與交付模型進行應用管理產品與專案統一架構升級的技術工作。

事實上，早在 2018 年末，當 Kubernetes 專案正式成為阿里巴巴的應用基礎設施底盤之後，阿里內部以及阿里雲產品線在應用管理領域的碎片化問題就開始日漸凸顯出來。

尤其是在雲原生生態日新月異的今天，阿里巴巴與阿里雲的應用管理產品架構（包括阿里內部 PaaS 和雲上 PaaS 產品），如何以最佳姿態擁抱雲原生生態、如何以最高效的技術手段藉助生態日新月異的能力構建出更強大的 PaaS 服務，而不是重複造輪子甚至和生態“背道而馳”，很快就成為了阿里團隊亟待解決的重要技術難題。

但棘手的是，這個問題並不是簡單把 PaaS 遷移或者整合到 Kubernetes 上來就能夠解決的：PaaS 與 Kubernetes 之間，從來就沒有存在這樣一條清晰的分界線，可是 Kubernetes 本身又並不是面向終端使用者設計的。

如何既讓全公司的研發和運維充分享受雲原生技術體系革新帶來的專注力與生產力提升，又能夠讓現有 PaaS 體系無縫遷移、接入到 Kubernetes 大底盤當中，還要讓新的 PaaS 體系把 Kubernetes 技術與生態的能力和價值最大程度的發揮出來，而不是互相“遮蔽”甚至“打架”？這個“既要、又要、還要”的高標準要求，才是解決上述 “Kubernetes vs PaaS” 難題的關鍵所在。

# 什麼是“應用模型”？

在 2019 年 10 月，阿里巴巴宣佈聯合微軟共同推出[開放應用模型專案（Open Application Model - OAM）](https://developer.aliyun.com/article/721106)，正是阿里進行自身應用管理體系標準化與統一架構升級過程中，逐步演進出來的一項關鍵技術。

所謂“應用模型”，其實是一個專門用來對雲原生應用本身和它所需運維能力進行定義與描述的標準開源規範。所以對於 Kubernetes 來說，OAM 即是一個標準的“應用定義”專案（類比已經不再活躍的 Kubernetes Application CRD 專案），同時也是一個專注於封裝、組織和管理 Kubernetes 中各種“運維能力”、以及連線“運維能力”與“應用”的平臺層專案。而透過同時提供“定義應用”和“組織管理應用的運維能力”這兩大核心功能，OAM 專案自然成為了阿里巴巴進行統一應用架構升級和構建下一代 PaaS/Serverless 過程中“當仁不讓”的關鍵路徑。

此外，OAM 模型並不負責應用和能力的具體實現，從而確保了它們都是由 Kubernetes 本身直接提供的 API 原語和控制器實現。所以， OAM 也成為了當前阿里構建 Kubernetes 原生 PaaS 的一項主要手段。

在 OAM 中，一個應用程式包含三個核心理念：

- 第一個核心理念是組成應用程式的元件（Component），它可能包含微服務集合、資料庫和雲負載均衡器；
- 第二個核心理念是描述應用程式運維特徵（Trait）的集合，例如，彈性伸縮和 Ingress 等功能。它們對應用程式的執行至關重要，但在不同環境中其實現方式各不相同；
- 最後，為了將這些描述轉化為具體的應用程式，運維人員使用應用配置（Application Configuration）來組合元件和相應的特徵，以構建應部署的應用程式的具體例項。

阿里巴巴在 OAM 這個專案中融入了大量網際網路規模場景中管理 Kubernetes 叢集和公共雲產品方面的實際經驗，特別是阿里從原先不計其數的內部應用 CRD 轉向基於 OAM 的標準應用定義過程中的諸多收穫。作為工程師，我們從過去的失敗和錯誤中吸取教訓，不斷開拓創新、發展壯大。

在本文中，我們將會詳細分享 OAM 專案背後的動機和推動力，希望能夠幫助更多人更好地瞭解這個專案。

# 背景

## 1. 關於我們

<br>我們是阿里巴巴的“基礎設施運維人員”，或者說 Kubernetes 團隊。具體來說，我們負責開發、安裝和維護各種 Kubernetes 級別的功能。具體工作包括但不限於維護大規模的 K8s 叢集、實現控制器/Operator，以及開發各種 K8s 外掛。在公司內部，我們通常被稱為“平臺團隊（Platform Builder）”。

不過，為了與兄弟團隊區分，即那些在我們之上基於 K8s 構建的 PaaS 工程人員區分，我們在本文中將自稱為“基礎設施運維人員（Infra Operator）”。過去幾年裡，我們已透過 Kubernetes 取得了巨大成功，並在使用過程中透過出現的問題獲取了寶貴的經驗教訓。

## 2. 我們管理各種 Kubernetes 叢集

<br>毫無疑問，我們為阿里巴巴電商業務維護著世界上最大、最複雜的 Kubernetes 叢集，這些叢集：

- 可縱向擴充套件至 1 萬個節點；
- 執行 1 萬多種應用程式；
- 在高峰期每天處理 10 萬次應用部署。

同時，我們還協助支援著阿里雲的 Kubernetes 服務（ACK），該服務類似於面向外部客戶的其他公有云 Kubernetes 產品，其中包含大量叢集（約 1 萬個），不過通常均為小型或中型的叢集。我們的內部和外部客戶在工作負載管理方面的需求和用例非常多樣化。

## 3. 我們服務的物件是“運維”；而運維的服務物件是“研發”

與其他網際網路公司類似，阿里巴巴的技術棧由基礎設施運維人員、應用運維人員和業務研發人員合作完成。業務研發和應用運維人員的角色可以概括如下：

### 業務研發人員

以程式碼形式傳遞業務價值。大多數業務研發都對基礎設施或 K8s 不甚瞭解，他們與 PaaS 和 CI 流水線互動以管理其應用程式。業務研發人員的生產效率對公司而言價值巨大。

### 應用運維人員

為業務研發人員提供有關叢集容量、穩定性和效能的專業知識，幫助業務研發人員大規模配置、部署和執行應用程式（例如，更新、擴充套件、恢復）。請注意，儘管應用運維人員對 K8s 的 API 和功能具有一定了解，但他們並不直接在 K8s 上工作。在大多數情況下，他們利用 PaaS 系統為業務研發人員提供基礎 K8s 功能。在這種情況下，許多應用運維人員實際上也是 PaaS 工程人員。

總之，像我們這樣的基礎設施運維人員為應用運維人員提供服務，他們隨之為業務研發人員提供服務。

# 合作問題

綜上所述，這三方顯然擁有不同的專業知識，但他們卻需要協調一致以確保順利工作。這在 Kubernetes 的世界裡可能很難實現！

我們將在下面的章節中介紹不同參與方的痛點，但簡而言之，我們面臨的根本問題是不同參與方之間缺乏一種標準化的方法來進行高效而準確的互動。這會導致低效的應用程式管理流程，甚至導致執行失敗。

而標準應用模型正是我們解決此問題的關鍵方法。

## 基礎設施運維人員和應用運維人員之間的互動

Kubernetes 具有高度的可擴充套件性，使得基礎設施運維人員能夠隨心所欲地構建自己的運維功能。但 Kubernetes 巨大的靈活性也是一把雙刃劍：這些功能的使用者（即應用運維人員）會遇到一些棘手的問題。

舉例來說，在阿里巴巴，我們開發了 CronHPA CRD 以根據 CRON 表示式擴充套件應用程式。當應用程式的水平擴充套件策略希望在白天和晚上有所不同時，這非常有用。CronHPA 是一種可選功能，僅在叢集中按需部署。

CronHPA 的 yaml 示例如下所示：

```
apiVersion: “app.alibaba.com/v1”
kind: CronHPA
metadata:
  name: cron-scaler
spec:
  timezone: America/Los_Angeles
  schedule:
  - cron: ‘0 0 6 * * ?’
    minReplicas: 20
    maxReplicas: 25
  - cron: ‘0 0 19 * * ?’
    minReplicas: 1
    maxReplicas: 9
  template:
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        name: php-apache
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 50
```

這是一個典型的 Kubernetes 自定義資源（CRD），可以直接安裝使用。

但是，當我們把這些功能交付出去，應用運維人員開始使用諸如 CronHPA 等自定義外掛時，他們很快就遇到麻煩了：

### 1. 這些 K8s 自定義功能的使用方法不明確。

應用運維人員經常抱怨這些外掛功能的使用方法（也就是 spec） 分佈的非常隨意。它有時位於 CRD 中，有時位於 ConfigMap 中，有時又位於某個隨機位置的配置檔案中。此外，他們還感到非常困惑：為什麼 K8s 中很多外掛（例如，CNI 和 CSI 外掛）的 CRD 並不是對應的能力（例如：網路功能和儲存功能）描述，而只是那些外掛本身的安裝說明？

### 2. 很難確認 K8s 叢集中是否存在某項具體能力。

應用運維人員對某項運維能力是否已在叢集中準備就緒毫無把握，尤其是當該能力是新開發的外掛提供時更是如此。基礎設施運維人員和應用運維人員之間需要進行多輪溝通，才能澄清這些問題。

除上述可發現性問題外，還有一個與可管理性相關的額外難題。

### 3. 運維能力之間的衝突可能會相當麻煩。

K8s 叢集中的運維能力之間的關係可以概括為以下三類：

- 正交 —— 能力彼此獨立。例如，Ingress 用於流量管理，永續性儲存用於儲存管理；
- 可組合 —— 多個能力可以協同應用於同一應用程式。例如，Ingress 和 Rollout：Rollout 升級應用程式並控制 Ingress 以便實現漸進式流量切換；
- 衝突 —— 多個能力不能應用於同一應用程式。例如，如果將 HPA 和 CronHPA 應用於同一應用程式，則會彼此衝突。

正交和可組合能力相對安全。然而，互相沖突的功能可能導致意外/不可預測的行為。

這裡的問題在於， Kubernetes 很難事先向應用運維人員傳送衝突警告。因此，他們可能會對同一應用程式使用彼此衝突的兩個運維能力。而當實際發生衝突時，解決衝突會產生高昂的成本，在極端情況下，這些衝突會導致災難性的故障。當然，在管理平臺能力時，應用運維人員顯然不希望面臨“頭頂懸著達摩克里斯之劍”的情況，因此希望找到一種更好的方法來提前避免衝突情況。

應用運維人員如何發現和管理可能相互衝突的運維能力？換而言之，作為基礎設施運維人員，我們能否為應用運維人員構建可發現且易管理的運維能力呢？

# OAM 中的運維特徵（Trait）

在 OAM 中，我們透過“運維特徵（Trait）”來描述和構建具備可發現性和可管理性的平臺層能力。

這些平臺層能力實質上是應用程式的運維特徵，而這正是 OAM 中“Trait”這個名稱的來歷。

## 1. 打造可發現的運維能力

在阿里的 K8s 叢集中，大多數 Trait 都由基礎設施運維人員定義，並使用 Kubernetes 中的自定義控制器實現，例如：

- Ingress
- Auto-scaler
- Volume-mounter
- Traffic-shifting、Security-policy 等

請注意， Trait 並不等同於 K8s 外掛。比如：一個叢集可具有多個網路相關 Trait ，如“動態 QoS  Trait ”、“頻寬控制 Trait ”和“流量映象 Trait ”，這些 Trait 均由一個 CNI 外掛提供。

實際上， Trait 安裝在 K8s 叢集中，並供應用運維人員使用。將能力作為 Trait 呈現時，應用運維人員使用簡單的 kubectl get 命令即可發現當前叢集支援的運維能力：

```
$ kubectl get traitDefinition
NAME                AGE
cron-scaler         19m
auto-scaler         19m
```

上面的示例顯示此叢集支援兩種 “scaler” 能力。使用者可以將需要基於 CRON 的擴充套件策略的應用程式部署到該叢集。

**Trait 提供給定運維能力的結構化描述。**

這使應用運維人員透過簡單的 kubectl describe 命令即可輕鬆準確地理解特定能力，而不必深入研究其 CRD 或文件。能力描述包括“此 Trait 適用於何種工作負載”和“它的使用方式”等。

例如，kubectl describe traitDefinition cron-scaler：

```
apiVersion: core.oam.dev/v1alpha2
kind: TraitDefinition
metadata:
  name: cron-scaler
spec:
  appliesTo:
    - core.oam.dev/v1alpha1.ContainerizedWorkload
  definitionRef:
    name: cronhpas.app.alibaba.com
```

請注意，在 OAM 中， Trait 透過 definitionRef 引用 CRD 來描述其用法，同時也與 K8s 的 CRD 解耦。

Trait 採用了規範與實現分離的設計，同樣一個 Trait 的 spec，可以被不同平臺不同環境完全基於不同的技術來實現。透過引用的方式，實現層既可以對接到一個已有實現的 CRD，也可以對接到一個統一描述的中間層，底下可插拔的對接不同的具體實現。考慮到 K8s 中的一個特定的能力比如 Ingress 可能有多達幾十種實現，這種規範與實現分離的思想會非常有用。Trait 提供了統一的描述，可幫助應用運維人員準確理解和使用能力。

## 2. 打造可管理的運維能力

應用運維人員透過使用 ApplicationConfiguration（將在下一部分中詳細介紹），對應用程式配置一個或多個已安裝的 Trait 。ApplicationConfiguration 控制器將處理 Trait 衝突（如果有）。

我們以此示例 ApplicationConfiguration 為例：

```
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: failed-example
spec:
  components:
    - name: nginx-replicated-v1
      traits:
        - trait:
            apiVersion: core.oam.dev/v1alpha2
            kind: AutoScaler
            spec:            
              minimum: 1
              maximum: 9
        - trait:
            apiVersion: app.alibabacloud.com/v1
            kind: CronHPA
            spec:            
              timezone: "America/Los_Angeles"
              schedule: "0 0 6 * * ?"
              cpu: 50
              ...
```

在 OAM 中，ApplicationConfiguration 控制器必須保證這些 Trait 之間的相容性，如果不能滿足要求，應用的部署就會立刻失敗。所以，當運維人員將上述 YAML 提交給 Kubernetes 時，由於“Trait 衝突”，OAM 控制器將會報告部署失敗。這就使得應用運維人員能夠提前知道有運維能力衝突，而不是在部署失敗後大驚失色。

總的來說，我們團隊不提倡提供冗長的維護規範和運維指南（它們根本無法防止應用運維人員出錯），我們傾向於是使用 OAM  Trait 來對外暴露基於 Kubernetes 的可發現和可管理的運維能力。這使我們的應用運維人員能夠“快速失敗”，並滿懷信心地組合運維能力來構建無衝突的應用運維解決方案，這就像玩“樂高積木”一樣簡單。

# 應用運維人員和業務研發之間的互動

Kubernetes 的 API 物件並不關心自己的使用者到底是運維還是研發。這意味著任何人都可能對一個 Kubernetes API 物件中的任何欄位負責。這也稱為“all-in-one”的 API，它使得新手很容易上手。

但是，當具有不同關注點的多個團隊必須在同一個 Kubernetes 叢集上展開協作時，特別是當應用運維人員和業務研發人員需要在相同 API 物件上展開協作時，all-in-one API 缺點就會凸顯出來。

讓我們先來看一個簡單的 Deployment YAML 檔案：

```
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      deploy: example
  template:
    metadata:
      labels:
        deploy: example
    spec:
      containers:
        - name: nginx
          image: nginx:1.7.9
          securityContext:
            allowPrivilegeEscalation: false
```

在我們的叢集中，應用運維人員與業務研發人員需要面對面開會來填寫這個 yaml 檔案。這種合作既耗時又複雜，但我們別無選擇。原因何在？

# “抱歉，這個欄位與我無關”

顯而易見，這裡最直接的方法是讓業務研發人員自己填寫 Deployment yaml。但是，業務研發人員可能會發現 Deployment 裡的某些欄位與他們的關注點沒有絲毫關聯。例如：

**有多少業務研發人員知道 allowPrivilegeEscalation 是什麼意思？**

事實上，很少有業務研發人員知道，在生產環境裡，這個欄位務必要設定為 false （預設是 true），才能確保應用程式在宿主機中具有合理的許可權。在實踐中，這個欄位只能應用運維人員配置。而現實是，一旦把整個 Deployment 暴露給業務研發填寫，這些欄位最終就會淪為“猜謎遊戲”，甚至完全被業務研發人員忽視。

# 這個欄位到底是研發還是運維負責？

如果你瞭解 K8s 的話，就一定會發現 K8s 中有大量的 API 欄位很難說清楚到底是應該由研發還是運維來填寫。

例如，當業務研發人員設定 Deployment 的 replicas:3 時，他會假設該數字在應用程式生命週期中固定不變。

但是，大多數業務研發人員並不知道 Kubernetes 的 HPA 控制器可以接管該欄位，並可能會根據 Pod 負載改變 replicas 的值。這種由系統自動化流程帶來的變更很容易導致問題：這意味著當業務研發人員想要更改副本數時，他對 replicas 的修改可能根本不會生效。

在此種情況下，一個 Kubernetes 的 YAML 檔案就不能表示工作負載的最終狀態，從業務研發人員角度而言，這非常令人困惑。我們曾嘗試使用 fieldManager 來處理此問題，但 fieldManager 進行衝突解決的過程仍頗具挑戰性，因為我們很難弄清這些衝突方的修改目的。

# “割裂研發與運維”能否解決上述問題？

如上所示，當使用 K8s API 時，業務研發人員和運維人員的關注點會不可避免地被混在一起。這使得多個參與方可能很難基於同一個 API 物件展開協作。

此外，我們也發現，阿里內部的很多應用程式管理系統（如 PaaS）並不願意暴露 K8s 的全部能力，顯然他們並不希望向業務研發人員暴露更多的 Kubernetes 概念。

對於上述問題，最簡單的解決方案是在業務研發人員和運維人員之間劃一條“明確的界限”。例如，我們可以僅允許業務研發人員設定 Deployment yaml 的一部分欄位（這正是阿里很多 PaaS 曾經採用的辦法）。但是，這種“割裂研發與運維”的解決方案可能並不奏效。

# 運維需要聽取業務研發人員的意見

在很多情況下，業務研發人員都希望運維人員聽取他們的一些關於運維的“意見”。

例如，假定業務研發人員為應用程式定義了 10 個引數，然後他們發現應用運維人員可能會覆蓋這些引數以適配不同的執行環境的差異。那麼問題來了：業務研發如何才能做到僅允許運維人員修改其中特定的 5 個引數？

實際上，如果採用“割裂研發與運維”應用管理流程，要傳達業務研發人員的運維意見將變得難上加難。這樣類似的例子有許多，業務研發人員可能希望表述很多關於他們的應用程式的資訊：

- 無法水平擴充套件（即單一例項）；
- 是一個批處理作業，而不是長執行的服務；
- 需要最高階別的安全性等等。

上述所有這些請求都是合理的，因為只有業務研發人員才是最瞭解應用程式的那個人。這就提出了一個我們亟待解決的重要問題：我們的 Kubernetes 能否既為業務研發和運維人員提供單獨的 API，同時又允許業務研發人員有效傳達自己對運維的訴求？

# OAM 中的 Component 和 ApplicationConfiguration

在 OAM 中，我們從邏輯上對 K8s 的 API 物件進行了拆分，並且做到了既使得業務研發人員能夠填寫屬於自己的那些欄位，同時又能有條理地向運維人員傳達訴求。

**定義你的應用程式，而不是僅僅描述它。**

## 1. Component

<br>在 OAM 中，Component（元件） 就是一個完全面向業務研發人員設計的、用於定義應用程式而不必考慮其運維詳細資訊的載體。一個應用程式包含一個或多個 Component 。例如，一個網站應用可以由一個 Java web 元件和一個資料庫元件組成。

以下是業務研發人員為 Nginx 部署定義的 Component 示例：

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

OAM 中的 Component 包含兩個部分：

- 工作負載描述 —— 如何執行此 Component，以及它的執行內容，實際上就是一個完整的 K8s CR；
- 可重寫引數列表 —— 研發透過這個欄位表示該 Component 的哪些欄位後續可以被運維或者系統覆蓋。

在 Component 中，workload 欄位可以直接向運維人員傳達業務研發人員關於如何執行其應用程式的說明。同時，OAM 圍繞容器應用定義了一種核心工作負載 ContainerizedWorkload，涵蓋了雲原生應用程式的典型模式。

與此同時，OAM 可以透過定義擴充套件工作負載來自由宣告使用者自己的工作負載型別。在阿里巴巴，我們在很大程度上依賴於擴充套件工作負載來使業務研發人員定義阿里雲服務 Component ，例如，阿里雲函式計算 Component 等。

請注意，在上面的示例中，業務研發人員不再需要設定副本數；因為這並不是他所關注的欄位：他選擇讓 HPA 或應用運維人員完全控制副本數的值。

總體來說，Component 允許業務研發人員使用自己的方式定義應用程式的宣告式描述，但同時也為他/她提供了隨時向運維人員準確傳達意見或資訊的能力。這些資訊包括對運維的訴求，例如，“如何執行此應用程式”和“可重寫引數”。

## 2. ApplicationConfiguration

最終，透過引用 Component 名稱並對它繫結 Trait ，運維人員就可以使用 ApplicationConfiguration 來例項化應用程式。

使用 Component 和 ApplicationConfiguration 的示例協作工作流：

- Kubernetes 裡安裝了各種工作負載型別（workloadType）；
- 業務研發人員使用所選工作負載型別定義一個 component.yaml；
- 然後，應用運維人員（或 CI / CD 系統）執行 kubectl apply -f component.yaml 來安裝此 Component；
- 應用運維人員接下來使用 app-config.yaml 來定義 ApplicationConfiguration 以例項化應用程式；
- 最後，應用運維人員執行 kubectl apply -f app-config.yaml 以觸發整個應用程式的部署。

這個 app-config.yaml 檔案的內容如下所示：

```
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-awesome-app
spec:
  components:
    - componentName: nginx
      parameterValues:
        - name: connections
          value: 4096
      traits:
        - trait:
            apiVersion: core.oam.dev/v1alpha2
            kind: AutoScaler
            spec:            
              minimum: 1
              maximum: 9
        - trait:
            apiVersion: app.aliaba.com/v1
            kind: SecurityPolicy
            spec:           
                allowPrivilegeEscalation: false
```

我們來重點說明以上 ApplicationConfiguration YAML 中的一些詳細資訊：

- parameterValues —— 供運維人員使用，用於將 connections 值重寫為 4096，在該元件中，該值最初為 1024。請注意，運維人員必須填寫整數 4096，而不是字串 "4096"，因為此欄位的 schema 已在 Component 中明確定義；

- Trait  AutoScaler —— 供運維人員使用，用於將 autoscaler  Trait （如 HPA）繫結給 Component 。因此，其副本數將完全由 autoscaler 控制；

- Trait SecurityPolicy —— 供運維人員使用，用於將安全策略規則應用於 Component。請注意，運維人員還可以修改 Trait 列表以繫結更多 Trait。例如，“Canary Deployment Trait ”意味著這個應用程式在後期升級過程中遵循金絲雀釋出策略。

實質上，ApplicationConfiguration 的主要功能，就是讓應用運維人員（或系統）瞭解和使用業務研發人員傳達的資訊，然後自由的為 Component 組合繫結不同的運維能力以相應實現其最終的運維目的。

# 並不止是應用管理

綜上所述，我們使用 OAM 的主要目標是解決應用程式管理中的以下問題：

- 如何在 Kubernetes 中構建可發現、可組合和可管理的運維能力；
- 如何使 Kubernetes 中的多個參與方圍繞同一個 API 物件準確有效地協作。

所以說，對於阿里巴巴來說，OAM 其實是阿里巴巴 Kubernetes 團隊提出的一種 Application CRD 規範，從而使得所有參與者可以採用結構化的標準方法來定義應用程式及其運維能力。

阿里巴巴開發 OAM 的另一個強大動力，則是在混合雲和多環境中進行軟體分發與交付。隨著 Google Anthos 和 Microsoft Arc 的出現，我們已然看到 Kubernetes 正成為新的 Android，並且雲原生生態系統的價值正迅速轉移到應用層的趨勢。我們將在以後討論這一主題。

本文中的實際使用案例由阿里雲原生團隊和螞蟻金服共同提供。

# OAM 的未來

目前，OAM 規範和模型實際已解決許多現有問題，但它的路程才剛剛開始。例如，我們正在研究使用 OAM 處理元件依賴關係、在 OAM 中整合 Dapr 工作負載等。

我們期待在 OAM 規範及其 K8s 實現方面與社群展開協作。OAM 是一箇中立的開源專案，其所有貢獻者都應遵循非營利性基金會的 CLA。

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

參與方式：

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

![2.png](https://ucc.alicdn.com/pic/developer-ecology/3845fe40447a4cdf90e3f1be67eaff4e.png)

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

**作者簡介**
**李響，阿里雲資深技術專家。**他在阿里巴巴從事叢集管理系統工作，並協助推動阿里巴巴集團內的 Kubernetes 採用。在效力於阿里巴巴之前，李響曾是 CoreOS Kubernetes 上游團隊的負責人。他還是 etcd 和 Kubernetes Operator 的建立者。

**張磊，阿里雲高階技術專家。**他是 Kubernetes 專案的維護者之一。張磊目前在阿里的 Kubernetes 團隊工作，其工作領域包括 Kubernetes 和雲原生應用管理系統。

# 有一個阿里團隊需要你！

雲原生應用平臺誠邀 Kubernetes / Serverless / PaaS / 應用交付領域專家（ P6-P8 ）加盟：

- 工作年限：建議 P6-7 三年起，P8 五年起，具體看實際能力；
- 工作地點：國內（北京 / 杭州 / 深圳）；海外（舊金山灣區 / 西雅圖）；
- 崗位包含：架構師、技術專家、全棧工程師等。

簡歷立刻回覆，2~3 周出結果，簡歷投遞：jianbo.sjb AT alibaba-inc.com。

![2群直播海報.png](https://ucc.alicdn.com/pic/developer-ecology/f33c2df2fbfd44b7a05af8dc57c14773.png)

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

深度解讀！阿里統一應用管理架構升級的教訓與實踐

相關文章