本文作者：吴海黎 - CODING 研发总监
负责持续部署产品设计，帮助多个行业客户完成研发效能的方案设计与最终落地。
什么是云原生
云原生是指导企业应用上云的方法论和技术体系，包含应用的开发、交付、运行时等阶段， Cloud Native 可以理解为：
-
Cloud 表示应用运行在云端，而非传统的 IDC；
-
Native 表示应用从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用云平台的弹性和敏捷。
对云原生的理解，各家厂商在不同时间有不同的定义：
-
2013 年，Pivotal 公司的 Matt Stine 首次提出云原生“CloudNative”的概念；
-
2015 年，Matt Stine 在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12 因素、微服务、自敏捷架构、基于 API 协作、扛脆弱性；
-
2017 年，Pivotal 最新官网对云原生概括为 4 个要点：DevOps + 持续交付 + 微服务 + 容器；
-
2018 年，CNCF 更新了云原生的定义，新增服务网格“Service Mesh”和声明式 API。
可以简单的总结为： 云原生 = DevOps + 持续交付（Continuous Delivery）+ 微服务（Micro Services）+ 敏捷基础设施（Agile Infrastructure）+ 12 要素（The Twelve-Factor App）+ 服务网格（Service Mesh）+ 声明式 API。
云原生应用交付现状
CNCF 发布的「Continuous Delivery, June 2020」主要结论如下：
-
开源工具难以满足企业级发布需求
中大型企业的发布场景，开源工具较难匹配，一般的解决方案是选择上图中 2-4 种，基于企业自身场景，深度定制满足需求。
-
Helm 不仅仅是包管理工具
虽然 Helm 自身的定位是解决 K8s 应用的安装包管理，但也被广泛应用发布场景，关于这点其实不难猜想，基础架构由单体迁移至微服务，同时也将应用的交付切分为细粒度的服务交付，但企业面向最终用户的价值交付，需由完整的应用承载，单一微服务价值为 0，因此从交付的完整性考虑，Helm 被广泛应用于发布场景并不奇怪。
- Jenkins 正逐步被替代
Jenkins 及其生态（Jenkins X、Jenkins Blue Ocean）依然是持续交付中主要被采纳的工具，但企业也在逐步使用新工具替代，如承载 GitOps 理念的 Flux。Jenkins 定位于持续集成，用来做发布的场景是略显无力的，针对 Jenkins 发布下文也做出了分析。
持续演进的云原生应用交付
从 CNCF 的调研报告中得出的核心结论是企业需求未被满足，持续交付的方法论和工具建设依然处于持续演进中，下面我们回顾一下云原生应用持续演进的重要方法论及相关工具。
Continue Delivery
方法论：持续交付
持续交付主张应用被更频繁、更快速的交付至客户，但快并不意味着对质量要求的降低，通常在持续交付实践中，会辅之以质量左移的手段，如代码审查、代码扫描、单元测试、自动化测试，保障应用交付的可靠性。
工具：Jenkins、Gitlab Ci、Tketon
价值：通过持续交付的引入，用户可通过上诉工具实现部署流程的自动化和可视化，通常的持续交付流水线如下，「Deploy」阶段使用：kubectrl apply 或 helm install等命令完成应用部署。
核心问题：通过上诉工具实现持续交付，前提需将集群密钥交由工具纳管，相比于 GitOps 密钥不出集群，相对不安全；且无法通过版本化的手段，实现交付的可追溯和可审计，出现问题较难快速恢复。
IAC
方法论：IAC（基础设施及代码）
随着云原生应用的快速发展，企业对云基础设施的交付和变更速度要求越来越高，依靠传统手工的方式，操作云控制台维护基础设施，已经无法满足企业的需求，通过抽象云基础设施，并对其通过代码编排的方式即为 IAC。
工具：TIC、Terraform、Crossplane
价值：IAC 将云的基础设施，通过代码来进行编排，并将编排代码存储于代码仓库中，实现了基础设施的版本化管理，用户可轻易的拓展应用依赖的基础设施，比如一个游戏公司将应用部署于腾讯云上海，因业务需求，客户需将应用部署至腾讯云广州，通过 Terraform 的能力，可快速实现应用依赖的基础设施跨可用区迁移：
核心问题：本质上 IAC 的能力依赖于云 OPEN API 的开放性和稳定性，目前云产品处于快速演进中，一定程度上造成了 IAC 的能力不够稳定。同时 IAC 的成熟程度仅局限于单一云厂商，跨云 IAC 目前仍需要较高的人工转换成本。
GitOps
方法论：GitOps
GitOps 是一种实现持续交付的模型，它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 的版本控制库中，通过版本控制库的变更，来实现应用和基础架构的变更。
工具：ArgoCD、Flux
价值：通过版本控制库来发布应用和基础架构的变更，将使发布的复杂性降低至版本控制库的 Pull and Push 操作。GitOps 通过安装在 K8s 集群中的 Operator 实现变更物料获取，集群密钥无需出集群，GitOps Operator 中只需获取制品库凭据，即可获取应用变更的制品信息，这也同时大大简化了大型微服务应用的变更交付流程，因为对变更物料的感知，是通过 Gitops 的 Pull 模式自动实现。另外 Git 仓库天生具有可审计「MR」、可追溯「commit log」、快速恢复「回退至某一版本」的能力，使应用发布的可靠性大大提升。最后 GitOps 通过状态控制实现版本库对集群的终态控制，实现 yaml 仓库的「所见」即是 K8s cluster 「所得」。
核心问题：Gitops 的出现大幅提高了云原生交付的效率和可靠性，但依然有两个问题未被解决，第一：密钥的存储问题，版本仓库的定位决定了它不适合存储密钥；第二：可视化，虽然版本仓库将所有变更存储于 history 中，但这些信息可能分布于不同分支，可读性较差。
OAM
方法论：OAM（Open Application Model）
OAM 试图提供一种云原生应用的建模语言，以实现研发和运维的视角分离，K8s 的复杂性无需透传至研发，运维通过提供模块化、可移植、可扩展的特性组件，支撑各种复杂的应用交付场景，从而实现云原生应用交付的敏捷性和平台无关性。
工具：KubeVela
价值：
- 应用（Application）：云原生应用建模语言，实现视角分离；
- 开放（Open）：支持异构的平台、容器运行时、调度系统、云供应商、硬件配置；
- 模型（Model）：建模标准，与底层平台无关。
总结
上述方法论尝试从不同维度优化云原生交付，但采用云原生架构的企业，依然需基于开源工具定制，才能满足企业级云原生交付需求，可见云原生交付域的发展远没有到最优解。比如云原生应用 12 要素（The Twelve-Factor App）中提及的环境隔离和治理问题，依然未被很好的解决。因此我们相信，2021 年会有更多的方法论和工具出现在云原生应用交付域，尝试解决企业级云原生交付问题。CODING 作为国内一站式 DevOps 头部品牌，将在下半年推出云原生应用交付工具，服务企业更好的落地云原生，实现研发效能升级。
