云原生DevOps的5步升级路径

1、什么是云原生DevOps

我们先通过一个简单的例子来了解什么是云原生DevOps，它和DevOps有什么不同。

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

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

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

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

符合开放标准、语言和框架无关，相比于针对某个特定语言、特定框架，在技术升级或迭代时可以有更高的弹性、更好的发展和生命力，形成更好的生态。
2个基础：基于微服务和无服务架构，可以让DevOps成为可能；基于Serverless的基础设施，是面向资源和需求，以达到更好的弹性。
在这2个原则和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 模型把改动应用到对应的环境上。无论是开发还是运维，都可以通过 I aC 的代码版本了解到系统发生了哪些变化，而且每次发布都是完整的。

（4）资源的BaaS化

最后一步是资源的BaaS化。
我们想象一下在应用中是怎么去使用资源的。我们一般会先去对应的控制台提交资源申请，描述我们需要的资源规格和要求，然后通过审批后得到资源的连接串和认证信息。在应用的配置中加上资源配置，之后如果有改动，在到对应的控制台操作，并配合代码发布进行审批。当然，对于这类资源的运维和监控一般也是在独立的控制台进行的。
当我们的资源种类越来越多，操作和维护成本就非常高了，尤其是在新建站点的时候。
本着用声明式的方式去描述资源、按需使用的原则，我们通过在IaC 里定义这些资源的方式，去简化所有应用对资源的使用。所有的资源都是声明式的描述，能够实现资源的智能管理和按需使用。同时我们所有的资源都采用的是云上通用资源、标准协议，极大降低了迁移成本。这样我们就逐步把业务团队迁移到云原生基础设施上。
所以，资源BaaS化的两大关键点是：

• 声明式地描述资源需求，智能管理，按需使用
• 采用云上通用资源，对齐标准协议

3、云效驱动云原生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标准能力支撑服务发现和治理。

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

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

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

4、云原生DevOps升级路径

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

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

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

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

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

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

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