手掌痣的位置与命运：Open Application Model（OAM）是阿里云联合微软等国际技术团队联合发布的应用模型技术。旨在通过全新的应用定义、运维、分发与交付模型，推动应用管理技术向“轻运维”的方向迈进，全力下一代云原生 DevOps 的技术。本《应用模型操作指南》系列文章，将为广大技术人员（研发、运维、基础设施工程师）提供接地气的、体系化的 OAM 操作和接入指南。 自 OAM 标准推出以来，越来越多的平台和服务开始接入 OAM 标准，朝着 BaaS (Backend as a service) 化的方向迈进。在阿里巴巴集团，我们了 EDAS、内部中间件交付平台等以 OAM 的方式打造和推出应用交付和运维产品。并且，ROS、PolarDB 等以的姿态逐步接入 OAM 作为跨平台集成方案。 随着跟终端用户和平台提供方的交流日益增多，我们也同时更加清楚地了解到在 OAM 集成各个平台和服务的时候还是有一些不一致、不标准的地方。举些例子，DB 等资源创建起来后连接信息该如何，已有的资源定义该如何模型化成 OAM，什么应该作为 Workload？什么应该作为 Trait 等等。这些问题在不同团队的解决方式是类似却有些许差异的，不仅造成重复劳作，实践经验也缺乏进一步沉淀。 我们希望用户去使用和接入 OAM，能够有一个统一的、清晰的流程和架构。这就是本文尝试去阐述问题、提供解法的地方。 如果你有一个服务，怎样才能以云原生的方式呢？答案就是在 Kubernetes 上提供该服务。而 OAM，正是帮助大家更好地在 K8s 上描述服务能力、实现扩平台集成的一种标准。 服务提供方需要将己方服务归类为上述一种。这样能够在平台上清楚地表达自己的目的，更好地被集成和使用。 我们通常在把一个服务归类为一种 OAM 类型之后，就会去编写这个服务的 OAM 定义。这包括两部分： 服务自定义的 API 是用来描述服务对外提供的能力的 API。在这方面，我们选择使用 JSON Schema 来作为 API 描述语言，因为它是一种、标准的方式，在工程领域为大家所熟知。 下面，我们就分别以 Workload 和 Trait 为例，结合注释来详解如何去编写服务的 OAM 定义。 在定义了 OAM API 之后，我们还需要有实现层能让这个 spec “跑”起来。这里我们推荐实现 K8s Operator 来作为这个 OAM API 的服务。Operator 具体细节有很多文章介绍，这里不再赘述。 大家如果在实现 OAM Operator 过程中有什么问题，欢迎联系我们。可以在上游提 issue 或者钉钉发消息。 OAM 能给大家带来的一个重要好处就是能够横向联通不同平台之间的服务能力。这里我们介绍下如何实现。 当前现状是，OAM 对接的项目往往都有自己的一套系统和消费服务的方式。下面我们举些例子： 除了的例子，我们还有很多其他或大或小的服务与消费的例子。现在这里有一个问题，那就是不同的项目之间，没有统一的服务与消费方式，导致不同的平台之间无法互通。在这里，我们希望定义一个统一的接口，让不同平台不同服务在接入 OAM 以后能够互通，更简单地透出服务能力赋能云用户。 我们看到 expose 字段声明了信息的名字，这样做是为了让消费者能关联。具体如何与消费服务信息，则是由 Runtime 层来实现。在这里，创建完 MySQL Workload 实例之后，MySQL 连接信息会被写入到一个 mysql-connection secret 里面去。
|