架构师成长系列 | 云原生时代的 DevOps 之道

作者 | 郝树伟(花名：流生) 阿里云高级研发工程师

本文整理自架构师成长系列 2 月17 日直播课程。

关注“阿里巴巴云原生”公众号，回复 “217”，即可获取对应直播回放链接及 PPT 下载链接。

导读：DevOps 是一种软件开发人员和 IT人员之间的合作过程，目标是高效地自动执行软件交付和基础架构更改流程。在云原生时代，企业又如何借助 DevOps 实现产品快速、稳定、高效和安全地迭代，释放业务价值呢？

什么是云原生

为了解决传统应用升级缓慢、架构臃肿、不能快速迭代、故障不能快速定位、问题无法快速解决等问题，云原生这一概念横空出世。

Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。

早在 2015 年 Pivotal 公司的 Matt Stine 就写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征：

符合 12 因素应用
面向微服务架构
自服务敏捷架构
基于 API 的协作
抗脆弱性

后来 Pivotal 对云原生的定义做过几次更新，最新的 Pivotal 官网上对云原生应用的最新介绍是关注以下四点：

集成 DevOps
持续交付
微服务
容器化

DevOps 是软件开发人员和 IT 运营之间的合作，目标是自动执行软件交付和基础架构更改流程。它创造了一种文化和环境，可在其中快速、频繁且更可靠地构建、测试和发布软件；
持续交付使得单个应用更改在准备就绪后即可发布，而不必等待与其它更改捆绑发布或等待维护窗口期等事件。持续交付让发布行为变得平淡可靠，因此企业可以以更低的风险频繁交付，并更快地获得最终用户的反馈，直到部署成为业务流程和企业竞争力必不可少的组成部分；
微服务是将应用作为小型服务集合进行开发的架构方法，其中每个服务都可实施业务功能，在自己的流程中运行并通过 HTTP API 进行通信。每个微服务都可以独立于应用中的其他服务进行部署、升级、扩展和重新启动，通常作为自动化系统的一部分运行，可以在不影响最终客户的情况下频繁更新正在使用中的应用；
与标准虚拟机相比，容器能同时提供效率和速度。单个操作系统实例使用操作系统级的虚拟化，在一个或多个隔离容器之间进行动态划分，每个容器都具有唯一的可写文件系统和资源配额。创建和破坏容器的开销较低，再加上单个虚拟机中的高包装密度，使容器成为部署各个微服务的完美计算工具。

Google 主导成立了云原生计算基金会（CNCF），对云原生的定义为：

“云原生（Cloud Native）技技术帮助企业和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API；这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可以使开发者轻松地对系统进行频繁并可预测的重大变更。”

目前云原生背后最大的推手就是 CNCF，关键技术包括容器、微服务、服务网格、devops，声明式的 API 等等。

云原生应用与传统应用的对比，云原生应用可以充分利用云的优势，灵活地在各个云厂商分发应用，释放企业生产力，聚焦到业务创新上，而不是花费更多的时间在适配和扩展不同的基础设施平台上。

云原生时代的 DevOps 新挑战

首先我们要清楚地知道，站在企业的角度来看，在这样一个快捷商业的时代，企业最需要什么？

唯快不破。这里的快可以解读出来两层含义，一是业务应用快速上线，有利于抢占市场先机，第二层意思就是在你的业务有爆炸式增长的时候，你如何在计算资源上给以充分的保证，这个时候其实追加巨额的 IT 投资购买软硬件也未必能跟得上业务的快速发展。这个其实就是企业研发效能的问题；
稳中求变。业务或者应用的稳定性永远都是第一位的，如何既保证业务的“稳态”又要满足快捷商业的“敏态”需求，比如新业务的上线、应用的变更等。这个是企业 IT 架构的问题；
节省资源，如何节省计算资源，根据业务是否高峰自动扩容缩容，这个是云平台建设的问题；
开拓创新，开发运维一体化、微服务架构。

DevOps 最初的出现打破了开发人员和运维人员之间历来存在的壁垒和沟鸿，加强了开发、运营和质量保证人员之间的沟通、协作与整合。在后 DevOps 时代，我们可以借助容器技术更快地对应用进行迭代上线。

下面是应用发布的一般过程，开发者 push 代码，触发构建，构建过程是拉取源码，应用打包，容器镜像推送，部署。

这个模型其实已经有很多地方充分利用了云原生的优势，比如容器技术、Kubernetes、动态分配 slave pod 等。但还有一些挑战。

如何应用在环境栈之间的安全推进发布
如何管理应用发布的权限和安全审批
如何提高应用的平均部署时间和平均恢复时间
如何迅速对线上应用进行故障定位、复现和回滚

云原生时代下的 DevOps 之道

首先我们要充分利用云原生技术的优势，云原生可以改进应用开发的效率，改变企业的组织结构，甚至会在文化层面上直接影响一个公司的决策。在容器领域内，Kubernetes 已经成为了容器编排和管理的社区标准。它通过把应用服务抽象成多种资源类型，比如 Deployment、Service 等，提供了一个云原生应用通用的可移植模型。

在这样的背景下，我们如何在云原生的环境下实践更高效的 DevOps 来达到更有生产力的表现就成为了一个新的课题和诉求。

下面是一个企业应用平台的建设目标：

在此 PaaS 平台的基础上，我们设计了 GitOps 安全发布模型来解决前面我们提到的一些挑战。

在设计 GitOps 发布模型的时候是有以下这些核心诉求的：

版本管理。我们希望每一个发布的应用的版本号都能跟 git commit id 关联，这样的好处就是每一个变更都有历史记录查询、可以更快进行故障定位和修复；
基线管理。便于问题复现和快速回滚；
安全发布。包括发布权限管理以及安全审批的内容；
快速反馈。提高研发效能。

GitOps 发布模型有以下特性：

Git 仓库是任何 CICD 过程的唯一输入源
声明式的应用编排、构建部署模型
应用在环境栈之间的无差别、自动化推进
PR/MR 触发的拉取式流水线过程
快速反馈机制

下面是使用 GitOps 管理应用发布到不同 Kubernetes 集群的架构图。

首先是应用源码与构建源码分离，我们可以看到橙色框起来的这两个源码项目，一个是我们的应用源码项目 application-java-demo，左侧的这个源码项目是用来存放构建源码的，比如 preview pipeline 的 Jenkinsfile， staging pipeline 的 Jenkinsfile，production pipeline 的 Jenkinsfile，除了 Jenkinsfile 之外，可能还有一些关于动态创建测试环境、连接预发环境或者生产环境的敏感信息，这些敏感信息也可以存放在数据库里，然后这里保存数据库的连接信息。

这个普通应用 application-java-demo 在 Git 仓库里是有不同的分支的，每个分支跟 Kubernetes 集群环境都有一定的对应关系，比如我们这里的设定，master 分支对应的是生产环境，latest 分支对应的是预发环境，其他开发分支对应的是测试环境，测试环境的动态创建和销毁、应用再测试环境的部署发布是开发测试人员自助的服务，但应用想要部署到预发环境和生产环境中的话是需要经过管理员安全审批的。

普通开发者的权限只有创建新代码分支和创建合并请求的权限，除此之外，剩下其他的部分都是管理员才有权限做的，绿色区域是 Jenkins 的流水线任务，当然你也可以是使用其他 cicd 引擎来做这个流水线任务的构建。普通开发者没有 Jenkins 环境的创建 Job 和构建 Job 的权限，也没有更改配置的权限，他有的只是构建 Job 的日志查看权限。

最后是一个时序图，演示一个应用从开发测试到业务上线迭代的一个完整流程：

开发者提交新的功能分支 feature；
开发者创建请求合并代码到 latest 分支的 Merge Request；
开发者创建 Merge Request 的动作自动触发名为 preview-pipeline 的 Jenkins 流水线任务的构建；
preview-pipeline 流水线任务从 Git 服务器拉取 preview-pipeline 源码项目，并按照项目中 Jenkinsfile 文件中的声明式脚本运行源码编译、测试、容器镜像构建和推送、应用部署到 Preview 的容器集群、钉钉通知的流程；
管理员在 Git 服务器的 Merge Request 页面查看应用的预览连接并验证应用是否可以合并到 latest 分支，如果通过验证则接受 Merge Request 的合并，触发步骤 6，如果不通过则通知开发者进行代码更新和提交，退回步骤 1；
管理员接受 Merge Request 合并的动作会自动触发 Jenkins 流水线任务 staging-pipeline 的构建；
staging-pipeline 流水线任务从 Git 服务器拉取 staging-pipeline 源码项目，并按照项目中 Jenkinsfile 文件中的声明式脚本运行源码编译、测试、容器镜像构建和推送、应用部署到 Staging 的容器集群、钉钉通知的流程；
Staging 环境中的应用服务在通过测试和验证后，管理员可以合并 latest 分支到 master 分支；
管理员合并 latest 分支到 master 分支后，会自动触发 Jenkins 流水线任务 production-pipeline 的构建；
production-pipeline 流水线任务从 Git 服务器拉取 production-pipeline 源码项目，并按照项目中 Jenkinsfile 文件中的声明式脚本运行源码编译、测试、容器镜像构建和推送、应用部署到 Production 的容器集群、钉钉通知的流程。

GitOps 是一套方法论，所以其实是有多种实践的方式的，会有多种多样的好用的工具，比如使用 draft 可以帮助完成应用编排模板的自动化生成，skaffold 用来简化应用构建部署流程，kaniko 可以实现不依赖 docker daemon 的镜像构建和推送，helm 用作应用的包管理工具，还有其他 cicd 引擎像 jenkins，tekton，argo 以及为云原生而生的 jenkinsx 等等。