云原生 DevOps 的 5 步升级路径

做者 | 张裕
编辑 | 雅纯
来源|阿里巴巴云原生公众号

什么是云原生 DevOps

点击查看视频：https://v.qq.com/x/page/u3220cutt7v.html

咱们先经过上面一个简短视频和下面两张图，来了解什么是云原生 DevOps，它和 DevOps 有什么不一样。

上图是一个大排档，图中的大厨在很是努力的去切、炒、制做各类美食，并将它卖出去。从原材料的采购到加工到销售到售后，都是一两我的完成。这是很是典型的 DevOps 场景，团队搞定端到端的全部的事情。这种状况，当厨师水平比较高、销售能力比较强的时候，能够作到高效率、低浪费。但存在的问题是，想要规模化会很难。由于它的流程都是非标准的，须要厨师有很强的我的能力。

咱们再看上面这张南京大排档的图，虽然名字里有大排档，但它显然不是咱们上面说的大排档。咱们随便走进任何一家南京大排档，均可以发现，南京大排档的厨师，能够专一在为客户提供更好的菜品上，研发试验新菜品，并经过小批量的用户来尝试和推广。不管是用户量增长或减小，都能很快的去适应。店铺扩张也能够很快。这种咱们能够理解为云原生 DevOps。

那究竟什么是云原生 DevOps 呢？咱们认为：云原生 DevOps 是充分利用云原生基础设施，基于微服务/无服务架构体系和开源标准，语言和框架无关，具有持续交付和智能自运维能力，从而作到比传统 DevOps 更高的服务质量、更低的开发运维成本，让研发专一于业务的快速迭代。

如上图所示，云原生 DevOps 基于 2 个原则：符合开放标准、语言和框架无关；有 2 个基础：微服务/无服务架构、Serverless 基础设施 BaaS/FaaS；提供 2 个能力：智能自运维、持续交付。 

• 2 个原则：符合开放标准、语言和框架无关。相比于针对某个特定语言、特定框架，在技术升级或迭代时能够有更高的弹性、更好的发展和生命力，造成更好的生态。

• 2 个基础：基于微服务和无服务架构，可让 DevOps 成为可能；基于 Serverless 的基础设施，是面向资源和需求，以达到更好的弹性。

• 在这 2 个原则和 2 个基础之上，作到 2 个能力：持续交付和智能自运维。

阿里巴巴云原生 DevOps 升级案例

咱们先来看一个阿里某团队云原生 DevOps 转型的案例。 案例背景：阿里某海外电商团队面临海外市场站点多、建站成本高、需求变化快、交付慢、运维成本高等挑战，如何平滑地升级到云原生 DevOps 来解决这些问题，以提高业务交付效率呢？咱们是这么作的。

1. 架构升级 - 服务治理 sidecar 和 mesh 化

第一步是架构升级，首先将服务治理的代码下沉到应用以外的 sidecar 部分，同时用服务网格来承载了如环境路由之类的能力。如上图所示，每一个绿点表明一个服务应用代码，每个橘点表明一个服务治理代码，这些代码以二方包的形式存在这个容器中。随着服务治理体系的建设，这里面就包含了很是多的东西，如日志采集、监控埋点、运维干预等等，咱们把这种容器称之为富容器。它的问题很明显：即使是日志采集的升级或调整，咱们都须要把应用从新升级、构建和部署一遍。然而这个其实与应用自己是没有任何关系的。同时，由于关注点不分离，日志采集的一个 bug，都会影响到应用自己。

本着让应用能更专一于应用自己的目的，咱们作的第一件事就是把全部服务治理的代码从应用容器中剥离出来，放到了 sidecar 里面，这样服务治理和应用的代码就存在两个容器里了。同时咱们又把原来服务治理的一些事情，好比测试路由、链路追踪等交给了 Mesh sidecar 。这样应用就瘦身了，应用只须要关心应用代码的自己。

这样作的好处是，业务能够专一于业务相关的应用代码，而无需依赖于服务治理了。

这是第一步，这一步是平滑的，由于咱们能够逐步把服务治理迁移到 sidecar 里面，不用担忧一次迁移成本过大。

2. 架构升级 - 从构建解耦、发布解耦到运维解耦

第二步，咱们作了三个层面的解耦：构建解耦、发布解耦、运维解耦。

了解微服务和无服务架构的人应该清楚，只有当一个业务可以独立去开发、测试、发布、运维的时候，业务才能跑得更快、更好。由于这样跟其余人的耦合性降到最低。可是咱们也知道，随着业务愈来愈复杂和应用的持续演进，应用里会包含愈来愈多的业务代码。好比下图中这个应用，它里面有一些代码是针对某个特定业务的，好比做为一个支付应用，有的是针对盒马的特定需求的，有的是针对天猫的特定需求的，还有一些是通用代码，或者叫平台代码，是针对全部业务场景的。

显然，从提升开发效率的角度讲，业务方改本身相关的业务代码，能够减小沟通成本，提升研发效率。但这带来了一个新的问题：若是某一个业务有需求改动，但并不涉及通用的业务逻辑时，也须要对整个应用的全部业务进行全面回归，若是这个时间段还有其余业务改动，他们须要一块儿集成并进行发布。若是改动的业务多，你们就须要排队集成。这种状况下，集成测试和沟通协调的成本很是高。

咱们的目标是每一个业务都能独立的开发、发布和运维。为了平滑地达到这个目标，咱们首先要作的是让它们在构建阶段可以解耦。好比，对一个相对独立的业务，咱们将其单独构建为一个容器镜像，并经过编排把它放到 Pod 的 init Container 中，Pod 启动的时候，再将其挂载到主应用容器的存储空间。

可是这时，应用的发布和运维仍是在一块儿的，咱们须要将它们分开。

咱们知道，应用的亲密性粗略能够分为三类：

• 超亲密，在同一个进程中，经过函数调用通讯。

• 位于同一个 Pod 的不一样容器，经过 IPC 通讯。

• 位于同一个网络中，经过 RPC 通讯。

咱们能够根据业务的特色，逐步地把一些业务代码拆分红一个个 RPC 或者 IPC 服务，这样它们就能够独立的发布和运维了。

至此咱们就完成了应用容器的构建解耦、发布解耦和运维解耦。

3. IaC & GitOps

第三步咱们看一下开发和运维态。在不少研发场景中，一个棘手的问题是：不一样的环境和业务会有很是多的本身特有的配置，在发布和运维时常常须要根据状况修改和选择正确的配置，而这个配置和应用代码自己其实就是发布的一部分，传统的经过控制台去维护的方式成本将会很是高。

在云原生背景下，咱们认为 IaC（Infrastructure as Code）和 GitOps 是更好的选择。每一个应用除了有一个代码库以外，咱们还有一个 IaC 仓库。这个仓库里面会包含应用的镜像版本和全部相关的配置信息。当代码变动须要发布或配置有变化时，都经过代码 push 的形式推送到 IaC 仓库。GitOps 引擎能自动检测到 IaC 的变化，并自动将其翻译为符合 OAM 规范的配置，而后基于 OAM 模型把改动应用到对应的环境上。不管是开发仍是运维，均可以经过 IaC 的代码版本了解到系统发生了哪些变化，并且每次发布都是完整的。

4. 资源的 BaaS 化

最后一步是资源的 BaaS 化。

咱们想象一下在应用中是怎么去使用资源的。咱们通常会先去对应的控制台提交资源申请，描述咱们须要的资源规格和要求，而后经过审批后获得资源的链接串和认证信息。在应用的配置中加上资源配置，以后若是有改动，在到对应的控制台操做，并配合代码发布进行审批。固然，对于这类资源的运维和监控通常也是在独立的控制台进行的。

当咱们的资源种类愈来愈多，操做和维护成本就很是高了，尤为是在新建站点的时候。

本着用声明式的方式去描述资源、按需使用的原则，咱们经过在 IaC 里定义这些资源的方式，去简化全部应用对资源的使用。全部的资源都是声明式的描述，可以实现资源的智能管理和按需使用。同时咱们全部的资源都采用的是云上通用资源、标准协议，极大下降了迁移成本。这样咱们就逐步把业务团队迁移到云原生基础设施上。

因此，资源 BaaS 化的两大关键点是：

• 声明式地描述资源需求，智能管理，按需使用。

• 采用云上通用资源，对齐标准协议。

云效驱动云原生 DevOps 高效落地

上面咱们分享的是阿里内部的实践，它依赖于阿里内部的研发协做平台 Aone。Aone 的公有云版本即阿里云云效。咱们如何经过阿里云云效去落地云原生 DevOps 呢？

从前面的案例咱们能够看到，云原生 DevOps 的落地是一个系统性的工程，包含方法、架构、协做和工程各个方面。其中，云原生 DevOps 的落地属于精益交付的范畴。

上图是云效云原生 DevOps 解决方案图。

这里，咱们将用户分为 2 种角色：

• 技术主管或架构师。

• 工程师，包括开发、测试和运维等。

做为技术主管或架构师，他须要从总体上去定义和把控企业的研发行为。从大的角度讲，研发过程包含四个方面：可运行、可观测、可治理、可变动。

首先他会去定义企业的研发协做模式，例如是采用敏捷研发仍是精益看板。其次他须要掌握总体的产品架构、如须要用到哪些云产品、这些云产品如何协调和管理等。而后他会去决定团队的研发模式：怎么作好研发协做，怎么把控研发质量等。第三步，他须要肯定发布策略，采用灰度发布仍是蓝绿部署，灰度策略是什么等等。最后，就是服务的监控策略，好比服务须要接入哪些监控平台，怎么探测服务状态，全局监控配置等等。

一线开发、测试、运维工程师，关注的是工做过程的顺畅和高效。在云效项目协做平台接收到一个需求或任务以后，能够经过云效去编码、提交、构建、集成、发布和测试，并部署到预发和生产环境上，将管理员配置的研发模式、发布策略真正落地。同时，各个环境都是自动触发和流转的，不须要人为地协调和拉动。

整个研发过程当中产生的数据是一个有机的总体，能够产生大量的数据洞察，能够驱动团队进行持续改进。当团队在研发过程当中遇到瓶颈或迷茫时，还能够从云效专家团队得到专业的诊断建议和研发指导。

总结一下，云效的云原生 DevOps 解决方案是在 ALPD 方法论指导下，基于专家建议的最佳实践，深度整合到完整的 DevOps 工具链中，帮助企业渐进式地迈入云原生 DevOps。

接下来，咱们看一个具体的案例。

某互联网企业，研发团队在 30 人左右，没有专职的运维人员，产品包括 20 多个微服务以及几十个前端应用（web、小程序、APP 等）。其业务增加很是快，在面对快速增加的客户和愈来愈多的需求状况下，原先基于 Jenkins+ECS 的脚本为主的部署方式渐渐没法知足诉求，特别是没法解决零停机部署升级的问题。因而，开始需求云效的帮助，并最终全面迁移到云效云原生 DevOps。

这个研发团队主要面临三大痛点：

• 客户量大、紧急需求多。

• 无专职运维、云原生技术如 K8s 的学习门槛高。

• IT 基础设施架构复杂、发布耗时耗力。

针对这些问题，云效从基础能力、发布能力和运维能力三个方面入手。

首先，引入阿里云 ACK 在已有 ECS 资源之上进行基础设施升级，应用进行容器化改造。在服务治理和应用架构上，从 Spring Cloud 全家桶简化为 SpringBoot，经过 K8s 标准能力支撑服务发现和治理。

其次，经过云效流水线实现自动化容器部署，配合灰度部署策略，作到灰度上线，自动扩容，出现故障自动重启，同时，基于云效流水线作到零停机快速回滚任意成本，节约机器成本的同时解决了企业无专职运维人员的问题。

第三，经过云效自动化流水线和分支保护规范研发模式，包括代码评审、代码检测、测试卡点等，提高反馈效率和发布质量。

下图为总体解决方案的架构图。

云原生 DevOps 升级路径

咱们将云原生 DevOps 落地分为 5 个阶段。

第一个阶段：全手工交付和运维。它是咱们最初始的阶段，应用架构尚未进行服务化改造，也没有使用云基础设施或仅使用 IaaS，没有持续集成、测试自动化，使用手工部署发布和手工运维。相信不多还有企业停留在这个阶段了。

第二个阶段：工具化的交付和运维。首先要作的是应用架构的服务化，采用微服务架构改善服务质量；其次是引入一些研发工具，如 gitlab、jenkins 这类孤岛式的工具解决部分问题。同时咱们开始落地单模块的持续集成，可是通常尚未实现自动化的质量卡点，发布每每有自动化工具进行辅助。

第三个阶段：有限制的持续交付和自动化运维。咱们进一步提高基础能力，将基础设施进行容器化改造，基于 CaaS 建设。另外一方面，开始引入完整的工具链，打通研发数据，例如使用云效 DevOps 这样的工具平台,实现全部数据的完整互通。在发布能力上能作到持续部署，可是还须要必定的人工干预。这时，自动化测试已经成为主流了，服务总体能够观测，运维可以面向服务，而且是声明式的。

第四个阶段：持续交付和人工辅助自运维。咱们进一步让开发同窗专一于业务开发，首先在应用架构上开始大量采用无服务架构，并作到无人值守的持续部署；发布的灰度和回滚，可以在有干预的状况下尽可能的自动化。观测能力从应用级别提高到业务级别，实现业务的可观测性，而且可以在人工辅助的状况下作到部分的自运维。

第五个阶段：全链路持续交付和自运维。这是咱们追寻的终极目标。这个阶段咱们全部的应用和基础设施采用的都是无服务架构，并作到端到端的无人值守持续交付，包括发布的回滚和灰度也是自动化的；技术设施和服务彻底实现自运维。开发者真正只须要关心业务的开发和迭代。

可是，魔鬼都在细节处，固然咱们真正的落地的时候仍有不少的问题须要咱们去解决，借助云效这样的工具平台和 ALPD 的专家咨询，可让咱们少走弯路，更快的实现目标。