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

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

导读：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 以及如何接入云服务有更多的了解。若是你们有什么问题或者反馈，也很是欢迎跟咱们在上游或者钉钉联系。

参与方式：

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

• 经过 Gitter 直接参与讨论：https://gitter.im/oam-dev/

期待你们的参与！

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