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

什么是云原生 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 的专家征询，能够让咱们少走弯路，更快的实现目标。