导读：随着虚拟化技术的成熟和分布式框架的遍及，在容器技术、可继续交付、编排零碎等开源社区的推动下，以及微服务等开发理念的带动下，利用上云曾经是不可逆转的趋势。

云原生带来了标准化、松耦合、易观测、易扩大的个性，为交付基建与业务解耦、更灵便的环境治理和无损公布带来新机遇。同时，微服务架构下服务数量爆炸式增长，对应的交付基建工作量暴增，且服务间拓扑简单，又导致了降级影响难评估、问题定位艰难、独自测试环境老本极低等问题给高效能交付带来了极大挑战。

全文 6228 字，预计浏览工夫 17 分钟。

爱番番产品从 20 年 4 月全面云化，在云化时代，通过与业务解耦的 DevOps 基建，让业务团队专一与业务开发自身，大幅度晋升业务效力，通过智能生成契约测试 case 保障服务间调用的可靠性，通过全链路灰度能力为线下测试和无损公布赋能，实现产品的高效能交付。

一、业务背景

爱番番是典型的 toB 型业务，具备以下特点：

• 从产品状态上，产品阵线长，涵盖 (拓、聊、追、洞察) 等外围产品能力；
• 从市场环境上，市场环境竞争异样强烈，对产研的效率与品质提出更高的要求；
• 从研发模式上，产品与研发采纳麻利思维研发，须要一直的翻新与试错，疾速实现 PoC 及 MVP 产品的研发上线；
• 从部署状态上，除了提供 SaaS 服务外，同时具备多样化售卖的诉求；

团队以业务畛域划分的多个 scrumTeam，如下图:

二、效力体系面临的挑战

2.1 服务爆炸导致的基础设施老本剧增

沉闷模块数 200+，月均新增模块 8 个，流水线、监控等基础设施接入治理保护老本剧增。每个模块须要接入的基础设施如下：

2.2 简单拓扑导致的问题定位艰难和回归范畴难以评估

服务间拓扑简单，如上图，简单拓扑带来下列问题：

1、降级影响难评估，回归漏测多；
2、线上问题定位艰难；
3、环境规模宏大，联调测试老本高；

2.3 越来越高频的公布需要和随拓扑复杂度晋升的公布老本的矛盾

模块泛滥且简单拓扑，而且模块间上线有依赖关系，每次上线 100+ 模块，人工控制流程，危险高而且效率越发低下。然而业务上公布的需要愈发频繁，在高频次的公布下，如何保障公布过程的高效、平安也是一项极大的挑战。

三、整体的效力改良思路

流程机制层面：用户价值，流动效率晋升为外围的麻利体系建设，蕴含以下几个方面

• 麻利迭代机制：以用户价值流动效率为核心理念，保障团队指标统一，信息通明；
• 需要拆分治理：标准化、可视化、自动化的管理机制，在老本可控的前提下达成小批量需要减速流动，疾速验证价值；
• 分支模式和环境治理：基于云原生弱小的流量管控能力，实现基于 istio 的全链路灰度环境能力，实现简洁、灵便、低危险的分支模式；
• 全流程的数据度量体系：通过指标指标度量理解现状，过程指标度量开掘问题，问题主动创立工作，协同 peer 推动问题闭环；

技术层面：全流程环节自动化智能化晋升，蕴含以下几个方面：

• 基础设施：建设与业务解耦的基础设施服务；
• 自动化：微服务下正当分层自动化体系，可控投入下保障无效品质召回；
• 公布能力：一键操作高效执行、过程可视、可感知、可控的极致公布体验；
• 工具赋能：丰盛的工具能力赋能研发测试各效力痛点环节，为人员赋能（建设中，本文暂不具体介绍）；

上面次要从技术层面的 4 个方向逐个进行计划阐明：

四、与业务解耦的 Devops 基础设施服务

上文曾经提到，基础设施面临的最大问题是，因为爆炸的服务个数带来的暴增的 DEVOPS 基础设施接入和保护老本问题。在这个问题的解决上，咱们借鉴了 serverless 的思路，把基础设施服务化，与业务解耦，独立运维。以前，咱们的业务团队研发和 QA，除了须要进行业务的开发和测试工作之外，有大量的工夫都破费在了新利用、日志、配置的接入以及环境、流水线、监控保护等等和外围业务无关的事项上，就像上面这个图的右边，而且，任意基础设施服务要降级，比方日志平台 SDK 降级、流水线须要对立减少一项平安检测环节等等，都须要各个业务团队配合降级，落地推广艰难。

如果咱们把这些基建内容通过服务化的模式提供给业务团队应用，就能让业务研发和 QA 聚焦于业务的要害事项，从而大幅度晋升团队效力。就像上面的左边这个图。同时基础设施的降级业务无感知，再也不会有基础设施能力落地推广艰难的问题。

如何打造与业务解耦，服务化的基础设施？

4.1 基础设施标准化

与业务解耦的第一步是基础设施的标准化，只有标准化的过程才有可能规模化，从而实现技术设施服务化。咱们次要针对以下几局部内容进行了标准化革新：

1. 模块标准化：代码构造、打包流程、规范容器、镜像治理、部署过程

2. 规范流水线

3. 规范的根底服务：APM 组件、配置核心、公布平台、资源管理

4. 研发模式：

4.2 申明式基础设施

与业务解耦的第二步，是基于标准化的根底上，建设申明式的基础设施能力。这里的申明式是指给业务团队申明式的基础设施体验。业务团队只须要在标准配置中申明一些根底属性，即可主动实现所有基础设施的接入，且后续保护上业务 0 老本。次要分为两个环节的建设：

接入时：分钟级的一键接入

咱们的做法是通过脚手架为抓手来构建基础设施的一键接入能力。如下图所示：脚手架是咱们这边新模块创立的入口。所有新代码库都是通过脚手架创立，他会帮忙开发主动生成一整套集成了规范组件的代码框架。

在脚手架创立新模块的时候，依据业务申明的模块属性，如是否接入 apm、模块代码类型、模块服务类型等等主动完流水线创立、根底组件接入、集群环境申请、配置文件生成等操作。一个新的服务，从创立代码库到服务全套基础设施接入实现，服务可间接部署到测试集群的工夫 <10 分钟。

• 脚手架：主动生成框架代码，蕴含根底 apm 组件、api 治理平台等的接入；
• configMap: 主动生成利用标准配置并基于配置新增 / 变更被动触发接入服务；
• 接入服务：拉取 configMap 配置并解析，依据配置内容调度不同的基础设施服务实现接入初始化；

运行时：依据服务申明内容动静运行，实现业务降级保护 0 老本

根底组件局部，因为都是以 sidecar 模式提供服务，所以运行时人造与业务解耦，因而重点在于如何实现流水线在运行时与业务解耦。咱们针对流水线进行了模板化、参数化革新，并和业务的申明属性联合。就像上面这张图，流水线每次都是动静运行的，运行的内容是依赖左侧 5 局部申明数据实时生成，包含 cicd 通用配置、流水线模板、工作脚本、工作策略、业务申明属性。除了业务本人的申明文件，其余部分都是基础设施组独立运维，故对应工作优化、增加、对立配置批改等均对业务通明。就像右图，如果要针对流水线上的某个环节进行优化，或者减少一些环节，仅需基础设施组批改流水线模板或者工作脚本即可。

4.3 智能化基础设施

因为服务化之后，基础设施作为独立运维的服务，所有的问题都须要设施团队独立保护排查，所以与业务解耦的第三步就是建设高稳固高效低运维老本的基础设施能力。咱们的思路是通过智能化的策略，来保障高效和稳固。在流水线运行的前中后通过策略给流水线减少一个”监工”，模仿人工判断工作是否应该执行，模仿人工剖析跟进、修复问题等。

剖析常见的流水线稳固和效率问题比方环境不稳固、底层资源不稳固、网络异样等等，大体可分为 偶发问题重试可复原、问题绝对简单需人工排查、阻塞问题需人工修复三类。而效率方面大量反复、有效工作比方只加了个 log 也要跑全套测试流程，导致了资源节约，也导致了执行效率低下。如下图左侧所示：

针对这些场景，咱们在流水线运行前后都增加了可配置的策略判断过程，判断工作是否须要跳过、排队、重试等等，从而晋升稳定性和效率。

典型场景：

主动红灯剖析：工作失败后可主动依据日志错误码剖析问题起因并给出标注，方面后续依据统计数据更无效的优化。

排队策略：在自动化等工作执行之前，自动检测依赖环境是否失常，从而升高运行失败导致的红灯。

五、分层自动化体系

要想实现继续的交付，自动化是一个绕不开的话题，在云原生微服务的背景下，自动化层级会产生怎么的变动呢？

和传统 3 层金字塔自动化不一样，云原生架构下的自动化，因为服务外部绝对简略，而服务拓扑简单，所以测试的重点是在零碎端到端测试，理论的分层测试的比重更像一个倒过去的金字塔。

而因为端到端老本过高, 思考到投入产出比，爱番番的分层自动化是依照右下角这个构造来建设的，其中接口 DIFF 测试、契约测试、纯前端 DIFF 测试是无人工染指，最外围的三个局部。

5.1 基于全链路灰度环境的接口 DIFF 自动化

5.1.1 全链路灰度计划

咱们接口的 DIFF 测试是基于弱小的全链路灰度环境能力来建设的，这是云原生架构给咱们带来的红利。先介绍下咱们的全链路灰度计划。

咱们是基于 istio 的灵便的路由能力，通过同构底层「分组多维路由」的架构设计，自研 CRD Operator 构建爱番番的「全链路灰度公布」平台。该计划反对了咱们的线下多路复用环境、线上平安的容量评估以及金丝雀公布等多个场景。

5.1.2 测试环境多路复用

测试环境多路复用是指，应用无限的资源，在一套根底环境上逻辑隔离出多套环境，反对并行开发、联调的需要。

如下图所示，不同的分支对应着不同的 feature，通过流量染色 + 流量规定路由的形式，使得不同分支领有逻辑上隔离的环境，反对并行开发。在前端给流量打上橘色标记之后，全链路的申请会走橘色的链路进行拜访。

5.1.3 基于多路复用的 DIFF 测试

有了如上所述的多套逻辑隔离的测试环境之后，每当有新的分支环境拉出并有代码更新时，即可通过将流量在 base 环境（部署最初一次上线的代码）和新分支环境进行回放，并比照两者的返回是否存在差别来进行回归测试。咱们的 diff 计划如下：

该计划具备如下几个长处：

• 基于流量回放的接口 diff，最大限度的笼罩线上用户实在场景；
• 全流程自动化，无人工参加；
• 配置化的流量筛选策略和 diff 策略接入，便于扩大优化；
• 分布式工作运行，反对大批量并发；

5.2 保障召回服务间调用问题的契约测试

5.2.1 什么是契约测试

微服务的架构，服务之间依赖简单，而且通常每个服务都是独立的团队保护，服务和服务之间，前后端之间大多通过 API 调用。那么这种状况下可能就会呈现如下场景：A 团队开发的 API 同时服务于 B\C 团队。最开始测试的时候都是通过的。然而后续迭代中，B 团队对字段 A 有一些调整的需要，A 团队依据需要改了，也测试通过了，然而上线后发现 C 团队性能异样了。

以上问题的实质起因为：

服务提供方服务的消费者越来越多的状况下，服务的变更影响难以评估，服务的变更也不能及时同步到所有消费者，所以往往是生产方发现问题了反馈，导致损失。为了防止上述问题，咱们引入了契约测试。

契约测试的外围思路是通过消费者驱动的形式，建设服务端和各个生产端之前的契约，在服务端有批改之后，通过测试和所有生产方之前的契约是否被破坏来保障服务降级的安全性。同时，契约也能够作为单方测试解耦的伎俩。通过契约测试，团队能以一种离线的形式(不须要消费者、提供者同时在线)，通过契约作为两头的规范，验证提供者提供的内容是否满足消费者的冀望

5.2.2 常见的契约测试计划

常见的契约测试计划有真正实际消费者驱动的如 pact，契约由生产端生成并保护，提供方代码更新之后，拉取所有生产方契约进行测试，即解决了集成测试解耦问题，又保障了服务方能满足所有生产方需要。（下左图）

也有非消费者驱动，提供方生产契约，并提供 mock 服务，生产方能够基于契约文件测试，如 Spring Cloud Contract。只能解决集成测试解耦的问题（下右图）

5.2.3 爱番番的契约测试计划

爱番番的计划则是取了折中。一方面因为团队习惯，契约始终是服务提供方给出，另一方面又心愿保留消费者驱动个性，从而保障服务方能满足所有生产方需要。咱们抉择了在提供方生成契约，然而通过线上日志和调用链解析的形式来补充模仿生产端契约 case。且整个过程全自动化。

5.2.4 契约测试技术实现

第一步：引入 swagger 推动全接口接入，保障接口治理平台的接口文档信息与理论代码达到准实时同步，具体的实现步骤如下；

第二步：依据接口文档主动生成契约 case

有了和代码同步的接口信息之后，则依据接口文档信息主动生成根底的契约测试 case。在每次接口信息上传平台的时候，会检测本次上传内容，依据内容主动触发新 case 的生成和老 case 的验证。验证会运行批改了的接口之前关联的契约测试 case 来检测本次接口更新是否毁坏原有契约，运行后果通过报表记录，并推送到对应团队标注，依据标注后果判断是否更新 case。

第三步：依赖调用链、日志信息智能剖析生产端特色，生成模仿生产端的 case

如下图，通过调用链信息，提取出各个服务的生产方有哪些，通过各生产方的日志剖析，获取模仿各生产方契约，并主动生成 case 和接口进行关联；

5.3 问题智能定位升高自动化保护老本

自动化尽管是效力晋升的好伎俩，然而长期以来，自动化的稳定性问题、问题跟进排查老本的居高不下都是阻止大家发展自动化建设或者自动化建设大功告成的重要起因。针对自动化的稳定性晋升和跟进老本升高，咱们建设了 case 失败主动定位和修复能力，让智能化的小助手帮忙大家轻轻松松保护 case 运行。上面是咱们主动定位的一个成果实例：

咱们会在自动化 case 运行失败后，调用主动定位服务，主动对失败的 case 进行标注，依据标注后果会对失败 case 进行分类解决。

比方，环境问题会主动重试，批量未知会发送到自动化小组进行排查，元素找不到会发送到业务 QA 排查。

以下是实现的计划。蕴含根底定位能力和根底数据获取。在这些根底能力之上，建设了配置层，实现配置解析和调度能力，让咱们能够通过配置的形式，灵便组合不同的定位策略疾速反对不同场景的问题定位。

六、高效平安的继续公布

6.1 公布窘境

• 不同类型模块对接了不同的不发平台和流程，对立公布艰难，底层公布形式的变更须要各模块降级，迁徙老本高
• 因为模块泛滥且简单拓扑，而且模块间上线有依赖关系，每次上线 100+ 模块，人工控制流程，危险高而且效率低。上线过程的的记录和剖析人耗也很高。
• 整体上线过程不可见，危险感知滞后

如何解决以上问题？

6.2 多平台部署引擎

基于云原生构建多平台对立的部署与公布引擎，无缝集成 CICD，实现公布过程的高度标准化，同时反对多种公布策略。如下图：

通过 CD 公布平台的对立，实现各类型模块对立公布，且底层部署迁徙业务无感知。

6.3 公布剧本设计

有了对立的公布平台之后，为了解决上线过程简单低效的问题，咱们心愿实现齐全自动化的公布过程。

剖析公布前后须要进行的事项，如下做图所示。基于这些事项，梳理了要主动实现整个公布过程须要收集的数据，如右图所示，蕴含公布模块封板信息、依赖信息、配置信息等等。基于这些数据，依据固定的编排逻辑，主动生成服务公布拓扑以及本次上线步骤。生成的上线拓扑和步骤信息经人工确认之后，主动调用对应上线公布服务进行公布，并针对公布过程数据主动统计，生成公布过程总结。

6.4 过程可视、可感知、可控的一键公布

有了自动化分公布过程之后，为了可能及时感知公布过程中的问题，升高公布危险，进行了公布过程可视化建设，并与 APM、金丝雀公布等策略联合，保障公布的平安。

公布过程可视：服务粒度的依赖拓扑曾经实时上线进度展示、过程可视可感知；

金丝雀公布策略：公布无损、危险及时感知并召回

七、整体收益

迭代 story 量增长 85.8%，公布周期稳固，研发测试周期降落 30%，千行 bug 率从 1.5 升高到 0.5。

八、将来瞻望

1、通过 IDE 本地插件工具，赋能开发编码测试过程，晋升研发环节效力；

2、通过白盒能力，构建品质危险辨认体系，利用于准入、准出、灰度等场景；

举荐浏览：

|百度短视频举荐零碎的指标设计

|百度信用认证中台架构解析

|图数据库在百度汉语中的利用

|一年数十万次试验背地的架构与数据迷信

———- END ———-

百度 Geek 说

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注