4 個概念，1 個動作，讓應用管理變得更簡單

隨著以 K8s 為主的雲原生基礎架構遍地生根，越來越多的團隊開始基於 K8s 搭建持續部署、自助式釋出體驗的應用管理平臺。然而，在 K8s 交付和管理應用方面，目前還缺乏一個統一的標準，這最終促使我們與微軟聯合推出了首個雲原生應用標準定義與架構模型 - OAM。本文作者將從基本概念以及各個模組的封裝設計與用法等角度出發來詳細解讀 OAM。

OAM 主要有三個特點：

• 開發和運維關注點分離：開發者關注業務邏輯，運維人員關注運維能力，讓不同角色更專注於領域知識和能力；
• 平臺無關與高可擴充套件：應用定義與平臺實現解耦，應用描述支援跨平臺實現和可擴充套件性；
• 模組化應用部署和運維特徵：應用部署和運維能力可以描述成高層抽象模組，開發和運維可以自由組合和支援模組化實現。

OAM 綜合考慮了在公有云、私有云以及邊緣雲上應用交付的解決方案，提出了通用的模型，讓各平臺可以在統一的高層抽象上透出應用部署和運維能力，解決跨平臺的應用交付問題。同時，OAM 以標準化的方式溝通和連線應用開發者、運維人員、應用基礎設施，讓雲原生應用交付和管理流程更加連貫、一致。

角色分類

OAM 將應用相關的人員劃分為 3 個角色：

• 應用開發：關注應用程式碼開發和執行配置，是應用程式碼的領域專家，應用開發完成後打包（比如映象）交給應用運維；
• 應用運維：關注配置和執行應用例項的生命週期，比如灰度釋出、監控、報警等操作，是應用運維專家；
• 平臺運維：關注應用執行平臺的能力和穩定性，是底層（比如 Kubernetes 運維/最佳化，OS 等）的領域專家。

核心概念

OAM 包含以下核心概念：

服務元件（Component Schematics）

應用開發使用服務元件來宣告應用的屬性（配置項），運維人員定義這些屬性之後就能按照元件宣告得到執行的元件例項，元件宣告包含以下資訊：

• 工作負載型別（Workload type）：表明該元件執行時的工作負載依賴；
• 後設資料（Metadata）：面向元件使用者的一些描述性資訊；
• 資源需求（Resource requirements）：元件執行的最小資源需求，比如最小記憶體，CPU 和檔案掛載需求；
• 引數（Parameters）：可以被運維人員配置的引數；
• 工作負載定義（Workload definition）：工作負載執行的一些定義，比如可執行包定義（ICO images, Function等）。

應用邊界（Application Scopes）

運維人員使用應用邊界將元件組成松耦合的應用，可以賦予這組元件一些共用的屬性和依賴，應用邊界宣告包含以下資訊：

• 後設資料（Metadata）：面向應用邊界使用者的一些描述性資訊。
• 型別（Type）：邊界型別，不同型別提供不同的能力；
• 引數（Parameters）：可以被運維人員配置的引數。

運維特徵（Traits）

運維人員使用運維特徵賦予元件例項特定的運維能力，比如自動擴縮容，一個 Trait 可能僅限特定的工作負載型別，它們代表了系統運維方面的特性，而不是開發的特性，比如開發者知道自己的元件是否可以擴縮容，但是運維可以決定是手動擴縮容還是自動擴縮容，特徵宣告包含以下資訊：

• 後設資料（Metadata）：面向特徵使用者的一些描述性資訊；
• 適用工作負載列表（Applies-to list）：該特徵可以應用的工作負載列表；
• 屬性（Properties）：可以被運維人員配置的屬性。

工作負載型別和配置（Workload types and configurations）

描述特定工作負載的底層執行時，平臺需要能夠提供對應工作負載的執行時，工作負載宣告包含以下資訊：

• 後設資料（Metadata）：面向工作負載使用者的一些描述性資訊；
• 工作負載設定（Workload Setting）：可以被運維人員配置的設定。

應用配置（Application configuration）

運維人員使用應用配置將元件、特徵和應用邊界的組合在一起例項化部署，應用配置宣告包含以下資訊：

• 後設資料（Metadata）：面向應用配置使用者的一些描述性資訊；
• 引數覆蓋（Parameter overrides）：可以理解為變數定義，可以被元件、特徵、應用邊界的引數引用；
• 元件設定（Component）：構成應用的全部元件都在這裡設定；
• 繫結元件的運維特徵配置（Trait Configuration）：繫結的特徵列表及其引數。

OAM 認為：

一個雲原生應用由一組相互關聯但又離散獨立的元件構成，這些元件例項化在合適的執行時上，由配置來控制行為並共同協作提供統一的功能。

更加具體的說：

一個 Application 由一組 Components 構成，每個 Component 的執行時由 Workload 描述，每個 Component 可以施加 Traits 來獲取額外的運維能力，同時我們可以使用 Application scopes 將 Components 劃分到 1 或者多個應用邊界中，便於統一做配置、限制、管理。

整體的執行模式如下所示：

元件、運維特徵、應用邊界透過應用配置（Application Configuration）例項化，然後再透過 OAM 的實現層翻譯為真實的資源。

怎麼用？

使用 OAM 來管理雲原生應用，其核心主要是圍繞著“四個概念，一個動作”。

四個概念

• 應用元件（包含對工作負載的依賴宣告）；【開發人員關心】
• 工作負載；【平臺關心】
• 運維特徵；【平臺關心】
• 應用邊界；【平臺關心】

一個動作

• 下發應用配置；【運維人員關心】

下發應用配置之後 OAM 平臺將會例項化四個概念得到執行的應用。

一個 OAM 平臺在對外提供 OAM 應用管理介面時，一定是預先已經準備好了“運維特徵，應用邊界”供運維人員使用，準備好了“工作負載”供開發者使用，同時開發者準備“元件”供運維人員使用。因此角色劃分就很明瞭：

• 開發者提供元件，使用平臺的工作負載；
• 運維人員關注一個動作例項化四個概念；
• 平臺方需要提供工作負載，運維特徵，應用邊界，並且託管使用者的應用元件；

例子

如何使用上面“四個概念，一個動作”來部署一個 OAM 應用呢？

我們假想一個場景，使用者的應用有兩個元件：frontend 和 backend，其中 frontend 元件需要域名訪問、自動擴縮容能力，並且 frontend 要訪問 backend，兩者應該在同一個 vpc 內，基於這個場景我們需要有：

• 開發者建立 2 個元件

frontend 的 workload 型別是 Server 容器服務（OAM 平臺提供該工作負載）：

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: frontend
  annotations:
    version: v1.0.0
    description: "A simple webserver"
spec:
  workloadType: core.oam.dev/v1.Server
  parameters:
    - name: message
      description: The message to display in the web app.
      type: string
      value: "Hello from my app, too"
  containers:
    - name: web
      env:
        - name: MESSAGE
          fromParam: message
      image:
        name: example/charybdis-single:latest

backend 的 workload 是 Cassandra（OAM 平臺提供該工作負載）：

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: backend
  annotations:
    version: v1.0.0
    description: "Cassandra database"
spec:
  workloadType: data.oam.dev/v1.Cassandra
  parameters:
    - name: maxStalenessPrefix
      description: Max stale requests.
      type: int
      value: 100000
    - name: defaultConsistencyLevel
      description: The default consistency level
      type: string
      value: "Eventual"
  workloadSettings:
    - name: maxStalenessPrefix
      fromParam: maxStalenessPrefix
    - name: defaultConsistencyLevel
      fromParam: defaultConsistencyLevel

• OAM 平臺提供 Ingress Trait

apiVersion: core.oam.dev/v1alpha1
kind: Trait
metadata:
  name: Ingress
spec:
  type: core.oam.dev/v1beta1.Ingress
  appliesTo:
    - core.oam.dev/v1alpha1.Server
  parameters:
    properties: |
      {
        "$schema": "
        "type": "object",
        "properties": {
          "host": {
            "type": "string",
            "description": "ingress hosts",
          },
          "path": {
            "type": "string",
            "description": "ingress path",
          }
        }
      }

• OAM 平臺提供網路應用邊界

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationScope
metadata:
  name: network
  annotations:
    version: v1.0.0
    description: "network boundary that a group components reside in"
spec:
  type: core.oam.dev/v1.NetworkScope
  allowComponentOverlap: false
  parameters:
    - name: network-id
      description: The id of the network, e.g. vpc-id, VNet name.
      type: string
      required: Y
    - name: subnet-ids
      description: >
        A comma separated list of IDs of the subnets within the network. For example, "vsw-123" or ""vsw-123,vsw-456".
        There could be more than one subnet because there is a limit in the number of IPs in a subnet.
        If IPs are taken up, operators need to add another subnet into this network.
      type: string
      required: Y
    - name: internet-gateway-type
      description: The type of the gateway, options are 'public', 'nat'. Empty string means no gateway.
      type: string
      required: N

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-vpc-network
spec:
  variables:
    - name: networkName
      value: "my-vpc"
  scopes:
    - name: network
      type: core.oam.dev/v1alpha1.Network
      properties:
        - name: network-id
          value: "[fromVariable(networkName)]"
        - name: subnet-ids
          value: "my-subnet1, my-subnet2"

• 應用運維部署整個應用

使用應用配置將上面的元件、邊界、特徵組合起來即可部署一個應用，這個由應用的運維人員提供：

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: custom-single-app
  annotations:
    version: v1.0.0
    description: "Customized version of single-app"
spec:
  variables:
    - name: message
      value: "Well hello there"
    - name: domainName
      value: "
  components:
    - componentName: frontend
      instanceName: web-front-end
      parameterValues:
        - name: message
          value: "[fromVariable(message)]"
      traits:
        - name: Ingress
          properties:
            - name: host
              value: "[fromVaraible(domainName)]"
            - name: path
              value: "/"
      applicationScopes:
        - my-vpc-network
    - componentName: backend
      instanceName: database
      applicationScopes:
        - my-vpc-network

透過以上完整的使用流程我們可以看到：應用配置是真正部署應用的起點，在使用該配置的時候，對應的元件、應用邊界、特徵都要提前部署好，運維人員只需做一個組合即可。

服務元件（Component Schematic）

服務元件的意義是讓開發者宣告離散執行單元的執行時特性，可以用 JSON/YAML 格式來表示，其宣告遵循 Kubernetes API 規範，區別在於：

• 定義欄位是 Kubernetes 的子集，因為 OAM 是更高的抽象；
• OAM Spec 的底層執行時可以不是 Kubernetes

下面我們來看看具體的元件宣告如何定義。

定義

頂層屬性

屬性型別必填預設值描述apiVersionstringY特定oam spec版本，比如core.oam.dev/v1kindstringY型別，對於元件來說就是

ComponentSchematicmetadataMetadataY元件後設資料specSpecY元件特定的定義屬性

Metadata

屬性型別必填預設值描述namestringYlabelsmap[string]stringNk/v對作為元件的lebelsannotationsmap[string]stringNk/v對作為元件的描述資訊

Spec

屬性型別必填預設值描述parameters[]ParameterN元件的可配置項workloadTypestringY簡明語義化的元件執行時描述，以K8s為例就是指定底層使用StatefulSet還是Deployment這樣osTypestringNlinux元件容器執行時依賴的作業系統型別，可選值：

- linux

- windows

archstringNamd64元件容器執行時依賴的CPU架構，可選值：

- i386

- amd64

- arm

- arm64

containers[]ContainerN實現元件的OCI容器們workloadSettings[]WorkloadSettingsN需要傳給工作負載執行時的非容器配置宣告

上面的 workloadType 後面會有詳細說明，這裡簡要來說就是開發者可以指定該 field 告訴執行時該元件如何被執行。工作負載命名的規範是 GROUP/VERSION.KIND，和 K8s 資源型別座標一致，比如：

• core.oam.dev/v1alpha1.Singleton

core.oam.dev 表示是 oam 內建的分組，oam 內建的表示任何 OAM 實現都支援該型別的工作負載，v1alpha1 表示依舊是 alpha 狀態，型別是 Singleton，這表示執行時應該只執行一個元件例項，無論誰提供。

• http:// alibabacloud.com/v1.Fun ction

http:// alibabacloud.com  表示該物件是一個運營商特定的實現，不一定所有平臺都實現，版本 v1 表示實現已經穩定，型別是 Function 表示執行時是 Alibaba Functions 提供的。

• http:// streams.oam.io/v1beta2. Kafka

表示該物件是一個第三方組織實現，不一定所有平臺都實現，版本 v1beta2 表示實現已經趨於穩定，型別是 Kafka 表示執行時是開源元件 Kafka 提供的。

工作負載主要分為兩類：

• 核心工作負載型別

屬於 core.oam.dev 分組，所有物件都需要 oam 平臺實現，都是容器執行時，該 Spec 目前定義瞭如下核心工作負載型別：

名字型別是否對外提供服務是否可以多副本執行是否常駐Servercore.oam.dev/v1alpha1.ServerYYYSingleton Servercore.oam.dev/v1alpha1.SingletonServerYNYWorkercore.oam.dev/v1alpha1.WorkerNYYSingleton

Workercore.oam.dev/v1alpha1.SingletonWorkerNNYTaskcore.oam.dev/v1alpha1.TaskNYNSingleton Taskcore.oam.dev/v1alpha1.SingletonTaskNNN

• Server：定義了容器執行時可以執行 0 或多個容器例項，該工作負載提供了冗餘的可擴縮容的多副本常駐服務，在 K8s 平臺可以使用 Deployment 或者 Statefulset 加上 Service 來實現；
• Singleton Server：定義了容器執行時只能執行一個容器例項，該工作負載提供了無法冗餘的單副本常駐服務，在 K8s 平臺可以使用副本為 1 的 Statefulset 加上 Service 來實現；
• Worker：定義了容器執行時可以執行 0 或多個容器例項，該工作負載提供了冗餘的可擴縮容的多副本常駐例項但是不提供服務，在 K8s 平臺可以使用 Deployment 或者 Statefulset 來實現；
• Singleton Worker：定義了容器執行時只能執行一個容器例項，該工作負載提供了無法冗餘的單副本常駐例項但是不提供服務，在 K8s 平臺可以使用副本為 1 的 Statefulset 來實現；
• Task：定義了非常駐可冗餘的容器執行時，執行完就退出，可以賦予擴縮容特性，在 K8s 平臺可以使用 Job 來實現；
• Singleton Task：定義了非常駐非冗餘的容器執行時，執行完就退出，在 K8s 平臺可以使用 completions=1 的 Job 來實現。

核心工作負載必須給定 container 部分，實現核心工作負載的 OAM 平臺必須不依賴 workloadSettings。

• 擴充套件工作負載型別

擴充套件工作負載型別是平臺執行時特定的，由各個 OAM 平臺自定提供，當前版本的 Spec 不支援使用者自定義工作負載型別，只能是平臺方提供，擴充套件工作負載可以使用非容器執行時，workloadSettings 的目的就是為了擴充套件工作負載型別的配置。

工作負載的定義是包羅永珍的，他允許任何部署的服務作為工作負載，無論是容器化還是虛擬機器，基於此，我們可以將快取，資料庫，訊息佇列都作為工作負載，如果元件指定的工作負載在平臺沒有提供，應該快速失敗將資訊返回給使用者。

除了 WorkloadType，可以看到元件 Spec 內嵌了 3 種結構體，下面來看看它們的定義：

1.Parameter

定義了該元件的所有可配置項，其定義如下：

屬性型別必填預設值描述namestringYdescriptionstringN元件的簡短描述typestringY引數型別，JSON定義的boolean, number, ... requiredbooleanNfalse引數值是否必須提供default同上面的typeN引數的預設值

2.Container

屬性型別必填預設值描述namestringY容器名字，在元件內必須唯一iamgestringY映象地址resourcesResourcesY映象執行最小資源需求env[]EnvN環境變數ports[]PortN暴露埠livenessProdeHealthProbeN健康狀態檢查指令readinessProbeHealthProbeN流量可服務狀態檢查指令cmd[]stringN容器執行入口args[]stringN容器執行引數config[]ConfigFileN容器內可以訪問的配置檔案imagePullSecretsstringN拉取容器的憑證

其中 Resources 的定義如下：

屬性型別必填預設值描述cpuCPUY容器執行所需的cpu資源memoryMemoryY容器執行所需的memory資源gpuGPUN容器執行所需的gpu資源volumes[]VolumeN容器執行所需的儲存資源extended[]ExtendedResourceN容器執行所需的外部資源

其中 CPU/Memory/GPU 都是數值型，不贅述，Volume 的定義如下：

屬性型別必填預設值描述namestringY資料卷的名字，引用的時候使用mountPathstringY實際在檔案系統的掛載路徑accessModestringNRW訪問模式，RW或ROsharingPolicystringNExclusive掛載共享策略，Exclusive或者ShareddiskDiskN該資料卷使用底層磁碟資源的屬性

Disk 指定儲存是否需要持久化，最小的空間需求，定義如下：

屬性型別必填預設值描述requiredstringY最小磁碟大小需求ephemeralbooleanN是否需要掛載外部磁碟

ExtendedResource 描述特定實現的資源需求，比如 OAM 執行時平臺可能提供特殊的硬體，這個欄位允許容器宣告需要這個特定的 offering：

屬性型別必填預設值描述requiredstringY需要的條件namestringY資源名字，比如GV.K

Env，Port，HealthProbe 和 K8s 類似，這裡不再贅述。

3.WorkloadSetting

工作負載的附加配置，用於非容器執行時（當然，也可以用於容器執行時工作負載的附加欄位）。

屬性型別必填預設值描述namestringY引數名typestringNstring引數型別，用於實現的hintvalueanyN引數值，如果沒有fromParam則用該值fromParamstringN引數引用，覆蓋value

這組配置會傳給執行時，一個執行時可以返回錯誤，如果特定的限制沒有滿足，比如：

• 丟失了期望的 k/v 對；
• 不認識的 k/v 對；

例子

使用核心工作負載 Server 的元件宣告

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: frontend
  annotations:
    version: v1.0.0
    description: >
      Sample component schematic that describes the administrative interface for our Twitter bot.
spec:
  workloadType: core.oam.dev/v1alpha1.Server
  osType: linux
  parameters:
  - name: username
    description: Basic auth username for accessing the administrative interface
    type: string
    required: true
  - name: password
    description: Basic auth password for accessing the administrative interface
    type: string
    required: true
  - name: backend-address
    description: Host name or IP of the backend
    type: string
    required: true
  containers:
  - name: my-twitter-bot-frontend
    image:
      name: example/my-twitter-bot-frontend:1.0.0
      digest: sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b
    resources:
      cpu:
        required: 1.0
      memory:
        required: 100MB
    ports:
    - name: http
      value: 8080
    env:
    - name: USERNAME
      fromParam: 'username'
    - name: PASSWORD
      fromParam: 'password'
    - name: BACKEND_ADDRESS
      fromParam: 'backend-address'
    livenessProbe:
      httpGet:
        port: 8080
        path: /healthz
    readinessProbe:
      httpGet:
        port: 8080
        path: /healthz

使用擴充套件工作負載的元件宣告

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: alibabacloudFunctions
  annotations:
    version: v1.0.0
    description: "Extended workflow example"
spec:
  workloadType: alibabacloud.com/v1.Function
  parameters:
  - name: github-token
    description: GitHub API session key
    type: string
    required: true
  workloadSettings:
    - name: source
      value: git://git.example.com/function/myfunction.git
    - name: github_token
      fromParam: github-token

總結

元件宣告是由開發者或者 OAM 平臺給出，透出應用執行的可配置項、依賴的平臺和工作負載，可以看成是一個宣告瞭執行環境的函式定義，運維人員填寫函式引數之後，元件就會按照宣告的功能執行起來。

應用邊界（Application scopes）

應用邊界透過提供不同形式的應用邊界以及共有的分組行為來將元件組成邏輯的應用，應用邊界具備以下通用的特徵：

• 應用邊界應該描述該組元件例項的共有行為和後設資料；
• 一個元件可以同時部署到多個不同型別的應用邊界中；
• 應用邊界型別可以決定元件是否可以部署到多個相同的應用邊界型別例項；
• 應用邊界可以用於不同元件分組以及不同 infra 能力之間的連線機制，比如 networking 或者外部能力（如驗證服務）；

下圖說明了元件可以屬於多個重疊的應用分組，最終建立出不同的應用邊界。

上圖有兩種應用邊界型別：Network 與 Health，有四個元件分佈在不同的應用邊界例項中：

• A、B、C 三個元件部署到了相同的 Health scope，該 scope 會收集所有屬於這個邊界的元件狀態和資訊，可以給 Traits 或者其他元件使用；
• 元件 A 和 B、C、D 的網路邊界是隔離的，這允許 infra 運維提供不同的 SDN 設定，控制不同分組的流量流入/流出規則；

型別

主要是有兩種應用邊界型別：

• 核心應用邊界型別
• 擴充套件應用邊界型別

核心應用邊界型別

定義基本執行時行為的分組結構，它們擁有如下特徵：

• 必須是 core.oam.dev 名稱空間；
• 必須被全部實現；
• 核心工作負載型別例項必須部署到所有核心應用邊界型別例項中；
• 執行時必須為每種應用邊界型別提供預設的應用邊界例項；
• 執行時如果元件例項沒有指定特定的應用邊界，必須將該元件例項部署到預設應用邊界例項上；

當前 Spec 定義的應用邊界型別有：

NameTypeDescriptionNetworkcore.oam.dev/v1alpha1.Network該邊界將元件組織到一個子網邊界並且定義統一的執行時網路模型，以及infra網路描述的定義和規則Healthcore.oam.dev/v1alpha1.Health該邊界將元件組織到一個聚合的健康組中，資訊可以用於回滾和升級

擴充套件應用邊界型別

對於執行時來說是 optional 的，可以自定義。

定義

apiVersion，kind，metadata 和前面元件一致，不贅述，主要描述 Spec：

屬性型別必填預設值描述typestringY應用邊界型別allowComponentOverlapboolY決定是否允許一個元件同時出現在多個該型別應用邊界例項中parameters[]ParameterN邊界的可配置引數

例子

Network scope（core）

用於將元件劃分到一個網路或者 SDN 中，網路本身必須被 infra 定義和運維，也可以被流量管理 Traits 查詢，用於發現 service mesh 的可發現邊界或者 API 閘道器的 API 邊界：

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationScope
metadata:
  name: network
  annotations:
    version: v1.0.0
    description: "network boundary that a group components reside in"
spec:
  type: core.oam.dev/v1.NetworkScope
  allowComponentOverlap: false
  parameters:
    - name: network-id
      description: The id of the network, e.g. vpc-id, VNet name.
      type: string
      required: Y
    - name: subnet-id
      description: The id of the subnet within the network.
      type: string
      required: Y
    - name: internet-gateway-type
      description: The type of the gateway, options are 'public', 'nat'. Empty string means no gateway.
      type: string
      required: N

Health scope（core）

用於聚合元件的健康狀態，可以設計的引數有健康閾值（超過該閾值的元件不健康則認為整個邊界不健康），健康邊界例項本身不會用健康狀態做任何操作，它只是分組健康聚合器，其資訊可以被查詢並用於其他地方，比如：

• 應用的變更 Traits 可以監控健康狀態來決定何時回滾；
• 監控 Traits 可以監控健康狀態來觸發報警。

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationScope
metadata:
  name: health
  annotations:
    version: v1.0.0
    description: "aggregated health state for a group of components."
spec:
  type: core.oam.dev/v1alpha1.HealthScope
  allowComponentOverlap: true
  parameters:
    - name: probe-method
      description: The method to probe the components, e.g. 'httpGet'.
      type: string
      required: true
    - name: probe-endpoint
      description: The endpoint to probe from the components, e.g. '/v1/health'.
      type: string
      required: true
    - name: probe-timeout
      description: The amount of time in seconds to wait when receiving a response before marked failure.
      type: integer
      required: false
    - name: probe-interval
      description: The amount of time in seconds between probing tries.
      type: integer
      required: false
    - name: failure-rate-threshold
      description: If the rate of failure of total probe results is above this threshold, declared 'failed'.
      type: double
      required: false
    - name: healthy-rate-threshold
      description: If the rate of healthy of total probe results is above this threshold, declared 'healthy'.
      type: double
      required: false
    - name: health-threshold-percentage
      description: The % of healthy components required to upgrade scope
      type: double
      required: false
    - name: required-healthy-components
      description: Comma-separated list of names of the components required to be healthy for the scope to be health.
      type: []string
      required: false

resource quota scope（extended）

限制分組內所有元件的資源使用總量上限。

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationScope
metadata:
  name: myResourceQuotas
  annotations:
    version: v1.0.0
    description: "The production configuration for Corp CMS"
spec:
  type: resources.oam.dev/v1.ResourceQuotaScope
  allowComponentOverlap: false
  parameters:
    - name: CPU
      description: maximum CPU to be consumed by this scope
      type: double
      required: Y
    - name: Memory
      description: maximum memory to be consumed by this scope
      type: double
      required: Y

總結

應用邊界宣告由 OAM 平臺提供，透出應用邊界例項執行的可配置項，可以看成是一個函式定義，運維人員或者平臺填寫函式引數之後，應用邊界就會按照宣告的功能執行起來，對該邊界內的元件們起作用。

應用特徵（Traits）

OAM Spec 的實現平臺應該提供 Traits 給元件工作負載增強運維操作，一個 Trait 是一種自由的執行時，增強工作負載提供額外的功能，比如流量路由規則、自動擴縮容規則、升級策略等，這讓應用運維具備根據需求配置元件，不需要開發者參與的能力。一個獨立的 Trait 可以繫結 1 或多個工作負載型別，它可以宣告哪些工作負載型別才能使用該Trait。

規則

• 目前並沒有機制來顯示約定元件的多個 Traits 組合，也就是一個元件應用了 Trait A 無法要求 Trait B 必須應用於該元件，如果在執行時發生存在 Trait A 但是 Trait B 不存在，應該標記 Trait A 失敗；
• Traits 應該按照定義的順序施加到元件上；
• 應用部署只有當所有元件和其 Traits 都正常執行起來才能標記為部署成功；
• OAM 平臺應該支援元件施加多個 Traits，這些 Traits 可能是相同的型別；
• OAM 對 Trait 的實現沒有任何限制，Trait 一般作用於應用的安裝和升級時；

分類

目前 Traits 主要分為三類：

• Core Traits: core Traits 屬於 core.oam.dev 分組，是一些必要的運維特徵，所有 OAM 平臺必須實現；
• Standard Traits: standard Traits 屬於 standard.oam.dev 分組裡面，是一些常用的運維特徵，推薦 OAM 平臺實現；
• Extensions Traits: extension Traits 是自定義 Traits，其分組也是自定義，是平臺特定的運維特徵（通常是特定 OAM 平臺差異性）的體現。

定義

apiVersion，kind，metadata 和前面元件一致，不贅述，主要描述 Spec：

屬性型別必填預設值描述appliesTo[]stringN["*"]該Trait可以應用的工作負載型別properties[]PropertiesNTrait的可配置引數，使用JSON Schema來表達。

例子

Manual Scaler（core）

apiVersion: core.oam.dev/v1alpha1
kind: Trait
metadata:
  name: ManualScaler
  annotations:
    version: v1.0.0
    description: "Allow operators to manually scale a workloads that allow multiple replicas."
spec:
  appliesTo:
    - core.oam.dev/v1alpha1.Server
    - core.oam.dev/v1alpha1.Worker
    - core.oam.dev/v1alpha1.Task
  properties: |
    {
      "$schema": "
      "type": "object",
      "required": ["replicaCount],
      "properties": {
        "replicaCount": {
          "type": "integer",
          "description": "the target number of replicas to scale a component to.",
          "minimum": 0
        }
      }
    }

上面是一個手動擴縮容服務的 Trait，只有一個引數就是 replicaCount。

總結

應用特徵宣告由 OAM 平臺提供，透出應用特徵的可配置項，標明瞭可作用於的工作負載，可以看成函式定義，運維人員或者平臺填寫實參之後，應用特徵就會按照宣告的功能執行起來，對繫結的元件起作用。

應用配置（Application Configuration）

應用配置主要是描述應用如何被部署的，一個元件可以部署到任意的執行時，我們稱一個元件的一次部署為例項，每次元件部署的時候必須有應用配置。

應用配置由應用運維管理，提供當前元件例項的資訊：

• 特定元件的基本資訊：名字、版本、描述；
• 元件及其相關元件定義 parameters 的賦值；
• 元件要施加的 Trait 以及 Trait 的配置。

概念

例項與升級（Instances and upgrades）

一個例項是元件的可追溯部署，當元件部署時建立，後續該元件的升級都是修改該例項，回滾/重新部署都屬於升級，例項都會有名字方便引用。當一個例項首次建立時，處於初始發行 (release) 狀態，每次升級操作之後，一個新的發行就會建立。

發行（Releases）

任何對元件本身或者其配置的變更都會建立一個新的發行，一個發行就是應用配置以及它對元件、應用特徵、應用邊界的定義，當一個發行被部署，對應的元件、應用特徵和應用邊界也會被部署。

基於該定義，平臺需要保證以下變更語義：

• 如果新的發行包含了舊發行不存在的元件，平臺需要建立該元件；
• 如果新的發行不包含舊發行存在的元件，平臺需要刪除該元件；
• 應用特徵和應用邊界與元件的變更語義一致。

執行時與應用配置（Runtime and Application Configuration）

一個元件可以部署到多個不同的執行時，在每個執行時中應用配置的例項與應用配置之間是 1:1 的關係，應用配置由應用運維管理，包含 3 個主要部分：

• 引數：運維人員在部署時可以定義的引數；
• 應用邊界列表：一組應用邊界列表，每個應用邊界定義對應的引數；
• 元件例項定義：定義一個元件例項如何部署，這個定義本身有 3 個部分：
  
• 元件引數的定義；
• Traits 列表：每個 Trait 定義對應的引數；
• 應用邊界列表：該元件應該部署到的應用邊界列表。

定義

apiVersion，kind，metadata 和前面元件一致，不贅述，主要描述 Spec：

屬性型別必填預設值描述variables[]VariableN可以在引數值和屬性中引用的變數scopes[]ScopeN應用邊界定義components[]ComponentN元件例項定義

variables 就是一個 k/v 對，一個集中的地方定義運維的變數，在運維配置的其他地方都可以用 fromVariable(VARNAME) 引用：

屬性型別必填預設值描述namestringY變數名字valuestringY標量值

scopes 定義該運維配置將要建立的應用邊界，其定義為：

屬性型別必填預設值描述namestringY應用邊界名字typestringY應用邊界的GROUP/VERSION.KINDpropertiesPropertiesN覆蓋邊界的引數

components 是元件例項定義，而不是元件定義：

屬性型別必填預設值描述componentNamestringY元件名instanceNamestringY元件例項名parameterValues[]ParameterValueN覆蓋元件的引數Traits[]TraitN指定元件例項繫結的TraitsapplicationScopes[]stringN指定元件執行的應用邊界

Trait 在這裡的定義是：

屬性型別必填預設值描述namestringYTrait例項名propertiesPropertiesN覆蓋Trait的引數

例子

apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: my-app-deployment
  annotations:
    version: v1.0.0
    description: "Description of this deployment"
spec:
  variables:
    - name: VAR_NAME
      value: SUPPLIED_VALUE
  scopes:
    - name: core.oam.dev/v1alpha1.Network
      parameterValues:
        - name: PARAM_NAME
          value: SUPPLIED_VALUE
  components:
    - componentName: my-web-app-component
      instanceName: my-app-frontent
      parameterValues:
        - name: PARAMETER_NAME
          value: SUPPLIED_VALUE
        - name: ANOTHER_PARAMETER
          value: "[fromVariable(VAR_NAME)]"
      traits:
        - name: Ingress
          properties:
            CUSTOM_OBJECT:
              DATA: "[fromVariable(VAR_NAME)]"

總結

應用配置定義由運維人員或者 OAM 平臺提供，描述應用的部署，可以看成是一個函式呼叫，運維人員或者 OAM 平臺填寫實參之後，呼叫之前定義的元件、應用特徵、應用邊界等函式，這些例項一起作用對外提供應用服務。

工作負載型別（Workload Types）

Workload 型別和 Trait 一樣由平臺提供，所以使用者可以檢視平臺提供哪些工作負載，對於平臺使用者來說工作負載型別無法擴充套件，只能由平臺開發者擴充套件提供，因此平臺一定不允許使用者建立自定義的工作負載型別。

定義

apiVersion，kind，metadata 和前面元件類似，不贅述，這裡主要描述 Spec，定義元件如何使用工作負載型別，除此之外暴露了底層工作負載執行時的可配置引數：

屬性型別必填預設值描述groupstringY該工作負載型別所屬的groupnamesNamesY該工作負載型別的關聯名字資訊settings[]SettingN該工作負載的設定選項

Names 就是描述了對應型別的不同形式名字引用：

屬性型別必填預設值描述kindstringY工作負載型別的正確引用名字，比如SingletonsingularstringN單數形式的可讀名字，比如singletonpluralstringN複數形式的可讀名字，比如singletons

Setting 描述工作負載可配置部分，類似前面元件的 Parameters，都是 schema：

屬性型別必填預設值描述namestringY配置名，每個workload型別必須唯一descriptionstringN配置說明typestringY配置型別requiredboolNfalse是否必須提供defaultindicated by typeN預設值

價值

透過上面的介紹，我們瞭解了 OAM Spec 裡面的基本概念和定義，以及如何使用它們來描述應用交付和運維流程。然而，OAM 能給我們帶來什麼樣的價值呢？我們評判一個好的架構體系，不僅是因為它在技術上更先進，更主要的是它能夠解決一些實際問題，為使用者帶來價值。所以，接下來我們將總結一下這方面的內容。

OAM 的價值要從下往上三個層面來說起。

1. 從基礎設施層面

基礎設施，指的是像 K8s 這類的提供基礎服務能力與抽象的一層服務體系。拿 K8s 來說，它提供了許多種類的基礎服務和強大的擴充套件能力來靈活擴充套件其他基礎服務。

但是，使用基礎設施的運維人員很快就發現 K8s 存在一個問題：缺乏統一的機制來註冊和管理自定義擴充套件能力。這些擴充套件能力的表達方式不夠統一，有些是 CRD、有些是 annotation、有些是 Config...

這種亂象使得基礎設施使用者不知道平臺上都提供了哪些能力，不知道怎麼使用這些能力，更不知道這些能力互相之間的相容組合關係。

OAM 提供了抽象（如 Workload/Trait 等）來統一定義和管理這些能力。有了 OAM，各平臺實現就有了統一的標準規範去透出公共的或差異化的能力：公共的基礎服務像容器部署、監控、日誌、灰度釋出；差異化的、高階複雜的能力像 CronHPA（週期性定時變化的強化版 HPA）。

2. 從應用運維者層面

應用運維，指的是像給應用加上網路接入、複雜均衡、彈性伸縮、甚至是建站等運維操作。但是，運維的一個痛點就是原來這些能力並不是跨平臺的：這導致在不同平臺、不同環境下去部署和運維應用的操作，是不互通和不相容的。

上面這個問題，是客戶應用、尤其是傳統 ERP 應用上雲的一大阻礙。我們做 OAM 的一個初衷，就是透過一套標準定義，讓不同的平臺實現也透過統一的方式透出。我們希望：哪怕一個應用不是生在雲上、長在雲上，也能夠趕上這趟通往雲原生未來的列車，擁抱雲帶來的變化和紅利！

OAM 提供的抽象和模型，是我們通往統一、標準的應用架構的強有力工具。這些標準能力以後都會透過 OAM 輸出，讓運維人員輕易去實現跨平臺部署。

3. 從應用開發者層面

應用開發，指的就是業務邏輯開發，這是業務產生價值的核心位置。

也正因如此，我們希望，應用開發者能夠專注於業務開發，而不需要關心運維細節。但是，K8s 提供的 API，並沒有很好地分離開發和運維的關注點，開發和運維之間需要來回溝通以避免產生誤解和衝突。

OAM 分離了開發和運維的關注點，很好地解決了以上問題，讓整個釋出流程更加連貫、高效。

下一步

目前，OAM 已經在阿里雲 EDAS 等多個專案中進行了數月的內部落地嘗試。我們希望透過一套統一、標準的應用定義體系，承載雲應用管理專案產品與外部資源關係的高效管理體驗，並將這種體驗統一帶給了基於 Function、ECS、Kubernetes 等不同執行時的應用管理流程；透過應用特徵系統，將多個阿里雲獨有的能力進行了模組化，大大提高了阿里雲基礎設施能力的交付效率。

經過了前一段努力的鋪墊，我們也慢慢明確了接下來的工作方向：

• 將接入更多的雲產品服務，為使用者將跨平臺應用交付的能力最大化；
• 提供 OAM framework 等工具和框架，幫助新的 OAM 平臺開發者去快速、簡單地搭建 OAM 服務，接入 OAM 標準；
• 推動開源生態建設，以標準化的方式幫助“應用”高效和高質量地交付到任何平臺上去。

原文連結

本文為雲棲社群原創內容，未經允許不得轉載。