做者 | 孙健波（天元）数据库
导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何经过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为你们一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。安全
什么是 DevOps？为何基于 Kubernetes 构建？
2009 年举办了第一届 DevOpsDays 大会，DevOps 名字被首次提出。到 2010 年，DevOps 的概念愈来愈火，出了 What is DevOps 的文章，讲解了 DevOps 的概念，方法论及配套的工具。简单来讲，研发工程师须要和运维工程师深度的合做，同时经过一系列工具保证研发更加顺畅，从而更容易的接触生产环境。架构
到 2013 年，Docker 出现了，工程师能够第一次到软件生产环境中定义，经过 Docker image 完成单机软件的交付和分发。此时 DevOps 开始慢慢落地。2015 年开始，DevOps 相关的工具愈来愈多，资源利用率出现了一些问题，CNCF 的成立使得 DevOps 的实践往 Kubernetes 上走。负载均衡
（DevOps 的三个阶段）
框架
阿里在 Kubernetes 上的实践也取得了很是好的成果。在规模方面，阿里内部集成了数十个节点能够达到上万的集群，同时具有高性能和安全特性，秒级扩容，神龙+安全容器。具有极致的弹性，分钟级拆解公有云计算资源，无限资源池。另外一方面，Kubernetes 社区已经具有很是丰富的 DevOps 生态基础功能，包括镜像托管、CI\CD 流水线、任务编排、发布策略、镜像打包、分发、丰富的应用运行时的负载支撑、丰富弹性和应用扩容能力。less
为何阿里基于 Kubernetes 构建 DevOps平台？
1）阿里基于 Kubernetes 的无限资源池与基础设施能力
- 大规模 – 单集群最高可达 10000 节点、百万 Pod
- 高性能 – 秒级扩容，智能伸缩，神龙 + 安全容器
- 极致弹性 – 分钟级拆解公有云计算资源，无限资源池
2）社区围绕 Kubernetes 已经具有丰富的 DevOps 生态基础功能
- 源码到容器镜像仓库，Kubernetes 是容器平台事实标准：Github / DockerHub；
- CI/CD 流水线、任务编排、发布策略：Argo / Teckton / Spinnaker / Jenkins-X / Flagger；
- 镜像打包、分发：Helm / CNAB；
- 丰富的应用运行负载支撑：Deployment(无状态) / StatefulSet(有状态) / OpenKruise(原生有状态加强)；
- 丰富的弹性和应用扩缩容能力：HPA / KEDA。
基于 Kubernetes 的 DevOps 平台新挑战
下图展现了一个云原生下的 DevOps 流水线的典型流程。首先是代码的开发，代码托管到 Github，再接入单元测试的工具 Jenkins，此时基本研发已完成。再接着到镜像的构建，涉及到配置、编排等。云原生中能够用 HELM 打包应用。打包好的应用部署到各个环境中。但整个过程当中会面临不少挑战。首先，在不一样的环境须要不一样的运维能力。运维
（一个云原生 DevOps 流水线的典型流程）
ide
其次，配置的过程当中要建立云上数据库，须要另外打开一个控制台来建立数据库。还须要配置负载均衡。在应用启动之后还须要配置额外的功能，包括日志、策略、安全防御等等。能够发现，云资源和 DevOps 平台体验是割裂的，里面充斥着借助外部平台建立的过程。这对新手来讲是很是痛苦的。模块化
挑战一：云资源与 DevOps 平台体验割裂
DevOps 流程中充斥着大量须要外部平台建立的过程：微服务
挑战二：研发、运维、基础设施关注点耦合
下图是经常使用的 K8s 的 YAML 配置文件，你们常常吐槽这个配置文件很复杂。
简单来讲 YAML 配置文件能够分为三大块，一块是运维比较关心的配置，包括实例数，策略和发布。第二块是研发关心的，涉及到镜像、端口号等。第三块是基础设施工程师看得懂的，如调度策略等。K8s 的配置文件中将方方面面的信息都耦合在一块儿，这对 K8s 工程师来讲是很是适合的，可是对应用侧的终端工程师而言，有不少不须要关心的配置指标。
- DevOps 流程中缺少对“应用”这个概念的描述
- K8s 的 YAML 文件的定位并非终端用户
挑战三：平台的自定义封装，简单却能力不足
DevOps 平台对 K8s 能力封装抽象，只剩下 5 个 Deployment 的字段须要研发填写。从用户角度而言，这种设置很是好用简单。可是针对稍微复杂的应用，涉及到应用状态管理，健康检查等等一系列的操做，此时这 5 个字段是不够的。
挑战四：CRD 扩展能力强大，DevOps 平台没法直接复用
CRD(Customize Resource Definition) 扩展能力强大，几乎全部软件均可以经过 CRD 的方式进行扩展，包括数据库、存储、安全、编排、依赖管理、发布等。可是对 DevOps 平台来讲，上面接口并无向用户暴露，致使没法直接复用。
挑战五：DevOps 平台开发的新能力使用门槛高
若是平台想要扩展一些能力，而原生的自动扩缩容能力不太合适，但愿开发定时的扩缩容YAML文件，随着业务状况而设置。但此时用户使用YAML的门槛很是高，不清楚如何使用YAML。随着新能力开发愈来愈多，能力之间会出现冲突，这也很是难以管理。
-
运维同窗怎么知道这个扩展能力怎么用？看 CRD？看配置文件？看 …… 文档？
- 扩展能力间出现冲突，致使线上故障，好比：CronHPA 和 默认 HPA 被同时安装给了同一个应用；K8s 扩展能力之间的冲突关系，如何有效管理？如何有效的对运维透出？
挑战六：不一样 DevOps 平台须要彻底从新对接
不少云原生实践中会遇到的问题，即须要定义很是复杂的 YAML，这种方式能够解决企业内部全部问题，可是挑战在于很难与生态进行对接。如 RDS，SLB 的能力都嵌到 YAML 文件中，没法复用，几乎不具有原子化能力。同时没法协做，没法提供给兄弟部门或生态使用，只能给内部封闭生态使用。上层系统不一样应用对接 DevOps 平台时，须要写不一样格式的 YAML，这也是很是痛苦的。
- 难以理解，必须经过界面可视化透出
- 没法复用，几乎不具有原子化能力
- 没法协做，只能内部封闭生态使用
OAM 应用模型的技术原理
OAM 应用模型的出现，解决了上述应用管理的难题，下面咱们来介绍一下 OAM 模型的技术原理。
1. Component 组件
OAM 中常见的概念是 Component 组件，彻底从研发角度定义的待部署单元。下图右侧是 YAML 中 Component 的例子，其中黄色部分能够灵活自定义。OAM 中会定义标准的架构 ContaineriseWorkload，表示工做负载部分，里面是待部署单元的具体描述。这时就能够解决关注点分离的问题，帮助应用侧工程师去掉不少细节，只须要关心开发须要关注的端口号，镜像等等。
应对挑战一，在 OAM 中能够定义数据库表达资源须要使用云资源，Workload 中能够根据本身的须要定义不一样的组件，包括基于虚拟机的应用、或者老的 Function 应用。组件是应用开发者关心的。
2. Trait
若是只是组件，组合起来就能够构建简单的应用。若是关心应用运维的问题，OAM 中有 Trait 的概念，指的是在原来组件的基础上附加一些特征。特征指的是运维的能力，如手动扩缩容能力、外部访问能力、发布、负载均衡。弹性扩缩容、基于流量的管理等等。经过 OAM 的 Trait 能够很灵活的获得插件化扩充能力。不一样的 component 绑定不一样的特征。
3. Scope
Component，Trait 以及全部组装起来的 Application Configuration 就是 OAM 中的三种主要的概念。但当多个组件共同协做时应该如何处理？OAM 中有个边界 Scope 的概念，是一种特殊的 Trait，将多个 Component 组合在一块儿，共享一组资源组，CPU 等特征用 Scope 表示，拓展多个组件的共同特征。
OAM 加持下的下一代 DevOps 技术
1. OAM：以应用为中心的分层模型
OAM 是以应用为中心的分层模型，首先须要运行在服务端的 OAM 解释器，对于 YAML 的读取须要经过 OAM 解释器。OAM 提供 Trait，Component 让用户填写，编成 APP Config。APP Config 经过 OAM 解释器具有 Deployment，Ingress，HPA 或者云资源等能力。这种方法能够将研发、运维基于基础设施进行分层，研发关心 Component，运维关心 Trait，基础设施经过 OAM 解释器提供各类能力，与 K8s 紧密结合，对其应用概念作了补充。
- 分层
- 模块化
- 可复用
2. 快速的归入 K8s 生态已有 Operater 能力
OAM 能够快速的归入 K8s 生态已有的 Operater 能力，下图左边的 Component 中是一个 CRD 的实例，右边是 Trait 中的 CRD 的实例，中间表示 Component 底下的 Workload 和 Trait 分别对应了 K8s 自定义资源的能力。若是想要使用 K8s 中的某些能力，只须要在 Trait 中写入相应的字段便可。
3. OAM 框架解决组件依赖关系和启动顺序
OAM 框架解决组件依赖关系和启动顺序。OAM Runtime，OAM 解释器会将组件依赖关系和启动顺序处理好，下图中 Component 之间有 dependency 关系，Trait 与 Component 之间有 preComponent 或者 postComponent 等关系。
4. OAM Trait 灵活解决资源绑定难题
启动顺序厘清以后涉及到资源绑定问题，一边是使用的数据库，另外一边是 Web 的程序，Web 的程序绑定数据库链接串资源。在 OAM 中只须要写一个 Trait 就能够解决资源绑定问题，下图右边，K8s 经过 Secret 承载链接串信息，Service Binding Trait 对应一个运行的 Operator，Web Hook 拿到 Secret 后注入进数据库中。
5. Workload 与 Trait 交互机制
你们会考虑接入 OAM 会不会比较麻烦，需不须要改代码。OAM 设计了 Workload 与 Trait 交互机制，OAM 内部零改造，只须要扩展 Workload 和 Trait。首先，Component 中建立 Workload 实例，再建立 Trait 实例，只须要在 Trait 中查看 Workload 的 Definition，从而配置 Trait 中须要的能力。
（OAM 内核零改造，插件式快速接入新能力）
若是开发了新的能力，碰到冲突问题也是很是头痛的。在 OAM 框架中定义 Trait 时，能够检查哪些字段是冲突的，拒绝掉新的应用的建立，从而保障 Trait 之间的兼容性，使得运维问题可发现、可管理。
（可发现、可管理的 Traits 系统）
6. OAM：无限能力的 DevOps 平台体系
下图是 DevOps 平台体系，最下层是 OAM Runtime，一部分是 Workload，对应运行时的承载的 Runtime，如 Function、Container、虚拟机、Serverless Service 等。另外一部分是 Trait，对应运维能力，如发布、弹性扩缩容、日志、安全等等。再上一层能够根据场景化组合（Application Profile）组装成不一样的业务形态平台，不一样平台可使用不一样组合的 Workload 和 Trait，具有不一样的能力。经过 OAM 标准化的模型构建无限能力的 DevOps 平台，知足各类场景的须要。
在用户侧，OAM 加持下的研发 DevOps 流程在镜像构建完成以后使用达到统一，OAM 提供了 APP Config，包含不一样的 Component，每一个 Component 包含不一样的运维能力 Trait，支持不一样的环境，如测试环境、生成环境。OAM 配置统一，适合不一样的云，能够拿到不一样的集群中直接运行。在 K8s 侧，用户只须要装上插件，就能够很方便的嵌入不少丰富的能力。
若是有其余问题，建议你们加入咱们的钉钉群进行讨论。（钉钉搜索群号：23310022，便可进群）
课程推荐
去年，CNCF 与 阿里云联合发布了《云原生技术公开课》已经成为了 Kubernetes 开发者的一门“必修课”。今天，阿里云再次集结多位具备丰富云原生实践经验的技术专家，正式推出《云原生技术实践公开课》。课程内容由浅入深，专一讲解“ 落地实践”。还为学习者打造了真实、可操做的实验场景，方便验证学习成果，也为以后的实践应用打下坚实基础。
点击连接便可免费观看：https://developer.aliyun.com/learning/roadmap/cloudnative2020
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，作最懂云原生开发者的公众号。”