开放应用模型操作指南（一）| 云服务一键接入 OAM 体系

2019-12-27 2356

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： Open Application Model（OAM)是阿里云联合微软等国际顶级技术团队联合发布的开放应用模型技术。旨在通过全新的应用定义、运维、分发与交付模型，推动应用管理技术向“轻运维”的方向迈进，全力开启下一代云原生 DevOps 的技术革命。

作者 | 邓洪超阿里云容器平台软件工程师

导读：Open Application Model（OAM）是阿里云联合微软等国际顶级技术团队联合发布的开放应用模型技术。旨在通过全新的应用定义、运维、分发与交付模型，推动应用管理技术向“轻运维”的方向迈进，全力开启下一代云原生 DevOps 的技术革命。本《开放应用模型操作指南》系列文章，将为广大技术人员（研发、运维、基础设施工程师）提供接地气的、体系化的 OAM 操作和接入指南。

前言

自 OAM 标准推出以来，越来越多的平台和服务开始接入 OAM 标准，朝着 BaaS (Backend as a service) 化的方向迈进。在阿里巴巴集团，我们见证了 EDAS、内部中间件交付平台等以 OAM 的方式打造和推出应用交付和运维产品。并且，ROS、PolarDB 等以开放的姿态逐步接入 OAM 作为跨平台集成方案。

随着跟终端用户和平台提供方的交流日益增多，我们也同时更加清楚地了解到在 OAM 集成各个平台和服务的时候还是有一些不一致、不标准的地方。举些例子，DB 等资源创建起来后连接信息该如何暴露，已有的资源定义该如何模型化成 OAM，什么应该作为 Workload？什么应该作为 Trait 等等。这些问题在不同团队的解决方式是类似却有些许差异的，不仅造成重复劳作，实践经验也缺乏进一步沉淀。

我们希望用户去使用和接入 OAM，能够有一个统一的、清晰的流程和架构。这就是本文尝试去阐述问题、提供解法的地方。

什么人适合读这篇文章？

这篇文章主要面向服务集成方，他们希望自己的服务能够通过 OAM 去被使用。这包括：

服务提供方。比如监控服务 ARMS、日志服务 SLS、分布式追踪服务等；
平台提供方。比如 EDAS、中间件交付平台、ROS、DBaaS 等，一个平台往往包含很多服务。

用 OAM 描述云资源/服务

如果你有一个服务，怎样才能以云原生的方式暴露呢？答案就是在 Kubernetes 上提供该服务。而 OAM，正是帮助大家更好地在 K8s 上描述服务能力、实现扩平台集成的一种标准。

1. 归类 OAM 类型

首先，服务的能力需要归类为 OAM 类型中的某一种。这里有三种类型：

类型	定义	例子
Workload	能单独跑起来、单独使用的服务需要定义的类型。	DB (MySQL)、MQ (Kafka)、Cache (Redis)、Service Mesh
Trait	跟运维相关的服务需要定义的类型。	Ingress、Monitoring、Logging、服务发现、灰度发布
Scope	囊括一组服务组件的边界。目前仅适用少数场景。	网络边界 (VPC、Firewall、Gateway)、健康边界 (互相关联的组件的整体健康检测)

服务提供方需要将己方服务归类为上述一种。这样能够在平台上清楚地表达自己的目的，更好地被集成和使用。

2. 编写 OAM 定义

我们通常在把一个服务归类为一种 OAM 类型之后，就会去编写这个服务的 OAM 定义。这包括两部分：

编写 OAM 定义里面的通用元数据；
编写服务自定义的 API。

服务自定义的 API 是用来描述服务对外提供的能力的 API。在这方面，我们选择使用 JSON Schema 来作为 API 描述语言，因为它是一种开放、标准的方式，在工程领域为大家所熟知。

下面，我们就分别以 Workload 和 Trait 为例，结合注释来详解如何去编写服务的 OAM 定义。

OAM Workload 例子

apiVersion: oam.dev/v1alpha1
kind: WorkloadType
metadata:
  name: rds
spec:
  group: alibaba.io/v1
  names: [RDS]
  # 下面用 JSON schema 描述服务能力
  settings: |
    {
   
      "$schema": "http://json-schema.org/draft-07/schema#",
      "type": "object",
      "required": [
        "storageType"
      ],
      "properties": {
   
        "storageType": {
   
          "type": "string",
          "description": "The type of storage for RDS instance"
        }
      }
    }

OAM Trait 例子

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
  # 下面用 JSON schema 描述运维能力
  properties: |
    {
   
      "$schema": "http://json-schema.org/draft-07/schema#",
      "type": "object",
      "required": [
        "replicaCount"
      ],
      "properties": {
   
        "replicaCount": {
   
          "type": "integer",
          "description": "the target number of replicas to scale a component to.",
          "minimum": 0
        }
      }
    }

3. 实现 OAM Operator

在定义了 OAM API 之后，我们还需要有实现层能让这个 spec “跑”起来。这里我们推荐实现 K8s Operator 来作为这个 OAM API 的服务。Operator 具体细节有很多文章介绍，这里不再赘述。

阿里巴巴云原生应用团队实现并开源了 OAM framework（oam-go-sdk）来帮助大家简化【构建 API + 实现 Operator】。

大家如果在实现 OAM Operator 过程中有什么问题，欢迎联系我们。可以在上游提 issue 或者钉钉发消息。

服务的暴露与消费

OAM 能给大家带来的一个重要好处就是能够横向联通不同平台之间的服务能力。这里我们介绍下如何实现。

在集成服务的时候，通常要做两件事情：

服务提供方需要暴露服务信息，比如 DB 连接信息写到 CMDB；
服务信息需要提供给用户应用去消费，比如将 DB 连接信息自动注入到（消费者）应用的环境变量。

当前现状是，OAM 对接的项目往往都有自己的一套系统暴露和消费服务的方式。下面我们举些例子：

Service Broker 将服务信息写入到 CRD 实例状态中，然后通过工作流读取并写入应用环境变量；
ROS 在 DB 模板执行完后有 outputs 属性包含服务信息，然后作为用户应用模板的参数入参；
CrossPlane 在多家云厂商上提供统一的 MySQL Resource 定义，然后通过将 connection 信息写入 secret 并挂载到用户应用文件系统里。

除了上面的例子，我们还有很多其他或大或小的服务暴露与消费的例子。现在这里有一个问题，那就是不同的项目之间，没有统一的服务暴露与消费方式，导致不同的平台之间无法互通。在这里，我们希望定义一个统一的接口，让不同平台不同服务在接入 OAM 以后能够互通，更简单地透出服务能力赋能云用户。

解决思路

针对上述问题，我们接下来描述下解决思路：

OAM Runtime 解析 AppConfig，发现一个 Component (微服务应用) 需要消费另一个 Component (云服务) 。于是 Runtime 需要安排好 Component 之间的创建顺序；
首先，OAM Runtime 创建云服务 Workload Component，并将相应的服务信息暴露到一个 spec 指定名字的 secret 里面去；
然后，OAM Runtime 创建微服务应用 Component，并将 spec 声明的消费内容通过名字相关联，并将 secret（通过 env、file 等方式）注入到应用中去。

整体架构图如下：

示例

下面我们通过举例来说明整个过程。

通过 CrossPlane 创建一个 CloudSQL Component:

apiVersion: oam.dev/v1alpha1
kind: Component
metadata:
  name: mysql
spec:
  workloadType: database.cloud.io/v1beta1.CloudSQL
  expose:
    name: mysql-connection 
  ... # 其他一些参数输入

上面我们看到 expose 字段声明了暴露信息的名字，这样做是为了让消费者能关联。具体如何暴露与消费服务信息，则是由 Runtime 层来实现。在这里，创建完 MySQL Workload 实例之后，MySQL 连接信息会被写入到一个 mysql-connection secret 里面去。

另一个应用 Web Component 则如下面定义所示来消费 MySQL：

apiVersion: oam.dev/v1alpha1
kind: Component
metadata:
  name: web
spec:
  workloadType: Server
  consume:
  - name: mysql-connection
    as: env # 注入到环境变量当中。也可以设置为 file，则会注入到本地文件当中

总结

在这篇文章里，我们主要针对云服务提供方讲了如何用 OAM 描述服务能力、定义和实现相应的 OAM Runtime、以及如何通过 OAM 集成不同平台的服务。

目前，OAM 还处于一个早期阶段，阿里巴巴团队正在上游贡献和维护这套技术，希望这篇文章能给大家对于 OAM 以及如何接入云服务有更多的了解。如果大家有什么问题或者反馈，也非常欢迎跟我们在上游或者钉钉联系。

参与方式：

期待大家的参与！

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