OAM 深刻解读：OAM 为云原生应用带来哪些价值？

时间 2020-06-11

标签 oam 深刻解读原生应用带来哪些价值繁體版

原文原文链接

做者 | 孙健波（天元）阿里巴巴技术专家git

导读：OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范，旨在经过全新的应用定义、运维、分发与交付模型，推进应用管理技术向“轻运维”的方向迈进，全力开启下一代云原生 DevOps 的技术革命。github

背景

OAM 是阿里巴巴联合微软在社区推出的一款用于构建和交付云原生应用的标准规范，以前咱们已经发布过一系列介绍文章，为方便你们查阅，连接和介绍以下：web

《4 个概念，1 个动做，让应用管理变得更简单》：具体而详实的介绍了 OAM 方方面面的细节；
《给 K8s API “作减法”：阿里巴巴云原生应用管理的挑战和实践》：介绍了咱们在探索出 OAM 以前的一些实践背景以及为何会天然而然地设计出 OAM 这样的应用模型；
《OAM 加持下的 Kubernetes PaaS 应用管理实践》：围绕目前常见的基于 Kubernetes 构建 PaaS 的各种解决方案，介绍了 OAM 如何将这些方案有机结合并最终统一，而后进一步的经过标准化模块化的组织，发挥生态的力量，使得彼此协做互惠互利成为可能；
《开放应用模型操做指南（一）：云服务“一键接入” OAM 体系》：以云资源为例，介绍了如何介入 OAM 体系的方法和实践。

在上面的几篇文章中，咱们介绍了为何云原生应用须要标准定义，以及 OAM 模型究竟是什么样子的。今天则为你们介绍 OAM 自己有哪些价值，即回答为何是使用 OAM 来做为应用标准模型。数据库

AWS 构建 ECS CLI v2 的开发原则

本月初（2019 年 12 月），AWS 发布了 ECS CLI v2，这是自 2015 年发布 v1 之后，四年来首次发布的大版本更新，此次发布的 v2 版本命令行工具将更关注端到端的应用体验，即管理从源代码开发到应用部署的全方位应用交付流程。他们基于多年来收到的用户反馈总结了四条 CLI 的开发原则：api

默认建立现代化的应用。建立的现代化应用默认知足这几个特征：无服务化 (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，完整包含了一个应用方方面面的资源。负载均衡

平台无关、运行时无关

OAM 应用定义并不限定你底层的平台和实际运行时，你彻底能够运行在 K8s 之外的平台，不论是 ECS、Docker、又或是 FaaS (Serverless)，天然也不存在厂商锁定的问题。若是你的应用知足 Serverless 的条件，那么针对该应用的 OAM 描述，自然就能够运行在支持 OAM 规范的 Serverless 运行时。
less

在支持 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 也将成为应用云原生化的必然选择。

目前，阿里巴巴团队正在上游贡献和维护这套技术，若是你们有什么问题或者反馈，也很是欢迎与咱们在上游或者钉钉联系。

参与方式：

钉钉扫码进入 OAM 项目中文讨论群

“ 阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的技术圈。”