简介： 受阿里云邀请，我有幸在《云原生架构白皮书》公布前试读了该书，本文联合白皮书内容，谈谈凋谢利用模型（OAM）

前言

7 月 21 日阿里云公布了《云原生架构白皮书》，该书由阿里云泛滥技术专家独特编撰而成，从云原生定义、技术、架构、产品、实际和发展趋势几个方面具体介绍了云原生这一近些年来大火的技术概念。受阿里云邀请，我有幸在该书公布前试读了该书，然而因为最近比较忙，当初才有空和大家分享我的试读感触。

相熟我的敌人必定晓得，去年凋谢利用模型（OAM）概念一经提出，我就非常关注这一技术模型，最近更是参加到了该模型的实现我的项目 Crossplane 中，同社区中的同学独特实现云原生技术“以利用为核心”这一终极愿景。然而苦于社区中的材料都是英文，同时本人的了解又比拟全面，在向身边共事和其余不理解该项技术的同学科普 OAM 时，往往很难精确表白我的观点。

OAM 是什么？OAM 能做什么？咱们为什么须要 OAM？每每被共事进行灵魂拷问时，总是不能拿出残缺、条理、有说服力的货色，只能依据本人的了解以及一些零零散散的技术文章来阐明我的观点，很是不爽。然而当我读到《云原生架构白皮书》第三章中的凋谢利用模型（OAM）章节时，我晓得我的问题解决了。该章零碎的介绍了 OAM 这项技术的背景、定义、概念、实现和将来，读者只有对云原生稍有了解，就能轻松从这章中找到后面那些问题的答案。

那么 OAM 到底是什么？

从《云原生架构白皮书》的内容登程，联合我的了解，大抵将 OAM 的特点分为以下三点：

以利用为核心

往年是 Kubernetes 我的项目诞生的第六年，在这六年中，以 Kubernetes 为首的云原生技术疾速的扭转着咱们的技术架构，一个又一个的利用被拆分成微服务，打包成容器，运行在 Kubernetes 上。然而随着微服务越拆越多，治理微服务的难度也呈指数型增长，Kubernetes 中并没有”利用“这一概念，提供给咱们的只有 deployment、StatefulSet 这样工作负载粒度的资源，而一个利用，可能由多个 Deployment、Service、以及各种相干配套资源组成（如：HPA 用于弹性伸缩、Ingress 用于内部拜访等）。Kubernetes 并没有提供给咱们一个对立的资源或者说是办法来治理这些相干资源，各个公司只能开发本人的 PASS 平台或设立标准束缚本人的利用。

OAM 的呈现补充了“利用”这一概念，建设对利用和它所需的运维能力定义与形容的标准规范。换言之，OAM 既是规范“利用定义”同时也是帮忙封装、组织和治理 Kubernetes 中各种“运维能力”的工具。通过 OAM 中利用的可交付对象 – Application Configuration，咱们能够轻松的把握咱们的利用到底有那些 Kubernetes 工作负载组成，这些工作负载都应用了哪些运维个性，这些内容都会以 Kubernetes API 对象的模式展现，查看起来和查看 Deployment 与 Service 资源一样不便。

关注点拆散

在实践中，如果基础架构和利用是由不同团队保护的，因为各个团队的关注点不同、对 Kubernetes 理解的水平不同、应用习惯不同，很容易产生凌乱。实际上，对于业务研发人员和运维人员而言，他们并不想配置这些如此底层的资源信息，而心愿有更高维度的形象。这就要求一个真正面向最终用户侧的利用定义，一个可能为业务研发和利用运维人员提供各自所需的利用定义原语。

通过组件（Component）和运维特色（Trait）将业务研发人员与运维人员关注的不同特色进行拆散，再将不同的运维特色（Trait）与业务组件（Component）进行绑定，最终再由 OAM 可交付物 – Application Configuration 将所有组件组装为一个对立的利用。研发与运维对资源的管制进行细粒度的划分，能够无效的解决理论状况中存在的相似”我比你更懂 Kubernetes，要听我的“的景象，防止了研发与运维之间的甩锅与扯皮的状况。

面向最终用户的利用治理平台

这部分白皮书中并未具体提及，但这也是咱们现阶段的次要工作和致力方向，通过不到一年的工夫，OAM 的概念、思维曾经根本成熟，而基于 OAM 的实现也曾经呈现 – Crossplane 我的项目，该我的项目目前为 CNCF 的 Sandbox 我的项目。

Crossplane 的呈现解决了平台维护者，也就是负责保护 Kubernetes 的基础设施工程师的难题。然而对于利用研发和运维人员，也就是 OAM 的最终用户，操作起来并不是非常的敌对。基础设施工程师为他们提供了一堆 CRD，他们必须一一去筛选、测试和甄别，尤其是一些运维特色（Trait）可能存在性能抵触，不能同时与一个业务组件（Component）绑定，这都都要利用研发和运维人员本人去学习和测试，尽管能够通过文档来标准，但显然这样做并不优雅，这时 OAM App Engine（暂定名 RdurX）就呈现了。

OAM App Engine 的指标用户群体是利用开发者，是心愿终端开发者用户能够感触到 OAM 提倡的各类利用治理理念带来的价值。相比于其余基于 K8s 的利用治理平台（如 rio），OAM App Engine 将至多具备如下三大外围价值。

1. 插件零碎：App Engine 能够通过 OAM 具备疾速纳管 operator 的能力，轻松扩大各种能力。
2. 用户体验：贴近开发者，所有设计以最终开发者应用体验至上，简单的概念做形象，用户相熟的概念不暗藏。
3. 最佳实际：App Engine 将成为 OAM 实现的最佳实际。

OAM App Engine 由 CLI 命令行工具、Dashboard UI 治理页面和一系列编排文件 /DSL 组成，目前还处于功能设计与开发当中，预计在 8 月底会和用户见面。OAM App Engine 的开发者均来自 OAM 中国社区，来自不同的公司和组织，是真正的从社区中来，服务社区用户。

原文链接：https://developer.aliyun.com/…_content=g_1000162429

本文为阿里云原创内容，未经容许不得转载。