指南：随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区以及微服务等开发理念的推动下在云的驱动下，应用上云是不可逆转的趋势。云原生带来了标准化、松散耦合、易观察、易扩展的特点，为交付基础设施与业务的解耦、更灵活的环境管理、无损发布带来了新的机遇。同时，微服务架构下的服务数量呈爆炸式增长，相应的交付基础设施工作量剧增，服务间拓扑复杂，导致升级影响评估难、问题定位难等问题，以及单独测试环境的高成本。高效交付提出了巨大挑战。全文6228字，预计阅读时间17分钟。爱饭饭产品自2020年4月全面云化，在云化时代，通过与业务解耦的DevOps基础架构，业务团队可以专注于业务发展本身，大幅提升业务效率，通过智能生成合约测试用例保障服务。通话可靠性，通过全链路灰度能力，赋能离线测试和无损放行，实现产品高效交付。1、业务背景爱饭饭是典型的toB型业务，具有以下特点：在产品形态上，产品线较长，涵盖了（延伸、聊天、追求、洞察）等核心产品能力；在市场环境方面，市场环境竞争异常激烈，对产学研的效率和质量提出了更高的要求；从研发模式来看，产品和研发采用敏捷思维，需要不断创新和试错，快速完成PoC和MVP产品的研发和上线；从部署形式来看，在互联网上，除了提供SaaS服务外，还有多元化的销售需求；团队按业务领域划分为多个scrumTeam，如下图：2.绩效体系面临的挑战2.1服务爆炸带来的基础设施成本活跃模块数200+，平均新增8个模块每个月，流水线、监控等基础设施接入管理和维护成本急剧增加。各模块需要连接的基础设施如下：2.2拓扑复杂导致问题难以定位，难以评估回归范围服务之间的拓扑复杂，如上图所示，复杂的拓扑带来存在以下问题：1.升级影响难以评估，回归缺失较多；2、线上问题难以定位；3、环境规模大，联调测试成本高；2.3随着拓扑复杂度的增加，日益频繁的发布需求与不断增加的发布成本之间的矛盾。上线存在依赖关系，每次上线100+个模块，人工控制过程风险高、效率低。但是，业务发布的需求越来越频繁。在高频发布下，如何保证发布过程的效率和安全也是一个很大的挑战。3、整体效率提升思路流程机制层面：以用户价值和流程效率提升为核心的敏捷体系构建，包括以下敏捷迭代机制：以用户价值流程效率为核心理念，确保团队目标一致信息透明；需求拆分管理：标准化、可视化、自动化的管理机制，实现小批量需求加速流转，在成本可控的前提下快速验证价值；分支模式和环境管理：基于云原生强大的流控能力，实现基于istio的全链路灰度环境能力，实现简单、灵活、低风险的分支模式；全程数据测度体系：通过目标指标测度了解现状，通过过程指标测度挖掘问题，自动为问题创建任务，协同同行推进问题闭环；技术层面：自动化、智能化提升整个过程，包括以下几个方面：基础设施：基础设施服务与建设和业务解耦；自动化：微服务下合理的分层自动化体系，投入可控下的有效质量召回；发布能力：一键式操作高效执行，流程可视化、可感知、可控的最终发布体验；工具赋能：丰富的工具能力赋能研发测试各种性能痛点，为人员赋能（建设中，本文暂不详细介绍）；下面主要从技术层面从四个方向一一讲解解决方案：4.Devops基础设施服务与业务解耦上面提到，基础设施面临的最大问题是由于服务个体的爆炸式增长DEVOPS基础设施的快速增长数量带来的接入和维护成本。在处理这个问题上，我们借鉴了serverless的思想，让基础设施服务化，和业务解耦，独立运维。过去，除了业务开发和测试，我们的业务团队R&D和QA在新应用、日志、配置接入、环境、流水线、监控维护等和核心业务无关的事情上花费了大量时间，如下图左侧，任何基础设施服务需要升级，比如日志平台SDK升级，流水线需要增加安全检测链路等，都需要各个业务团队的配合升级和实施推广困难重重。如果我们将这些基础设施内容以服务化的形式提供给业务团队，业务研发和QA就可以专注于关键的业务问题，从而大大提高团队效率。如右下图。同时，基础设施升级业务没有感知，基础设施能力的落地和推广将不再有困难。如何创建与业务解耦的面向服务的基础架构？4.1基础设施标准化与业务解耦的第一步是基础设施的标准化。只有标准化的流程才能规模化，实现技术设施的服务化。我们主要对以下几个部分进行了标准化改造：1、模块标准化：代码结构、打包流程、标准容器、镜像管理、部署流程2、标准管道3、标准基础服务：APM组件、配置中心、发布平台、资源管理4.研发模型：4.2声明式基础设施与业务解耦的第二步是在标准化的基础上建立声明式基础设施能力。这里的声明式是指给业务团队一个声明式的基础设施体验。业务团队只需在标准配置中声明一些基础属性，即可自动完成所有基础设施的接入，后续维护无成本。主要分为两个建设阶段：接入：分钟级一键接入。我们的做法是以脚手架为起点，构建基础设施一键接入能力。如下图所示：脚手架是我们这边新建模块的入口。所有新的代码库都是通过脚手架创建的，他会帮助开发一个自动生成一套集成标准组件的代码框架。脚手架创建新模块时，根据业务声明的模块属性，如是否接入apm、模块代码类型、模块服务类型等，进行流水线创建、基础组件接入、集群环境申请、以及配置文件的生成都是自动完成的。对于一个新的服务，从创建代码库到完成服务整个基础设施的接入，直接将服务部署到测试集群上只需要不到10分钟的时间。脚手架：自动生成框架代码，包括apm基础组件接入、api管理平台等；configMap：自动生成应用标准配置，并根据配置增/改主动触发接入服务；接入服务：拉取configMap配置并解析，根据配置内容调度不同的基础设施服务，完成接入初始化；运行时：根据服务声明的内容动态运行，零成本实现基础组件部分的业务升级和维护。既然所有的服务都是以sidecar的方式提供的，那么运行时自然要和业务解耦，所以重点是如何在运行时将pipeline和业务解耦。我们对流水线进行了模板化、参数化改造，并与业务声明的属性相结合。如下图所示，pipeline每次都是动态运行的，运行内容是依赖左侧语句数据的5部分实时生成的，包括cicd通用配置、pipeline模板、任务脚本、任务策略和业务报表属性。除了业务本身的声明文件外，其余由基础设施组独立运维，因此相应的任务优化、添加、统一配置修改等对业务都是透明的。就像右图，如果要优化管道上的某个环节，或者增加一些环节，只需要基础设施组修改管道模板或任务脚本即可。4.3智能基础设施因为服务化之后，基础设施是一个独立的运维服务，所有的问题都需要设施团队独立维护检查，所以第三步与业务解耦就是建立一个高稳定、高效和低运维成本的设施能力。我们的想法是通过智能策略确保高效和稳定。通过流水线运行前、运行中、运行后的策略为流水线添加“主管”，模拟人工判断任务是否执行，模拟人工分析跟进，修复问题等常见流水线稳定性与效率分析环境不稳定、底层资源不稳定、网络异常等问题，大致可以分为三类：偶尔重试可以恢复的问题、比较复杂需要人工排查的问题、堵塞问题需要人工修复。在效率上，大量重复无效的任务，比如只加一条日志，就得跑一整套测试流程，造成资源浪费，执行效率低下。如下图左侧所示：针对这些场景，我们在流水线运行前后增加了可配置的策略判断流程，判断任务是否需要跳过、排队、重试等，从而提高稳定性和效率.典型场景：自动红灯分析：任务失败后，可以根据日志中的错误码自动分析问题原因，并给出注释，以便后续根据统计数据优化更有效。排队策略：在执行自动化等任务之前，自动检测依赖环境是否正常，从而减少运行失败导致的红灯。5.分层的自动化系统要实现持续交付，自动化是一个绕不开的话题。在云原生微服务的背景下，自动化水平会发生哪些变化？不同于传统的三层金字塔自动化，云原生架构下的自动化在服务内部比较简单，服务拓扑复杂，所以测试的重点是系统端到端的测试，而实际分层测试的比例更像是一个倒置的。来金字塔。但由于端到端成本较高，考虑到投入产出比，爱饭饭的分层自动化按照右下角的结构搭建，其中接口DIFF测试、合约测试、纯前端DIFF测试不需要人工干预。三个核心部分。5.1基于全链路灰度环境的接口DIFF自动化5.1.1全链路灰度解决方案我们接口的DIFF测试是基于强大的全链路灰度环境能力，这是云原生架构给我们带来的红利。先介绍一下我们的全链路灰度方案。我们基于istio灵活的路由能力，通过同构底层“群组多维路由”的架构设计，以及自研的CRDOperator来搭建爱饭饭的“全链路灰度发布”平台。该方案支持我们离线复用环境、在线安全能力评估、金丝雀发布等多种场景。5.1.2测试环境复用测试环境复用是指利用有限的资源，将多套环境从一个基础环境中逻辑隔离出来，以支持并行开发和联调。如下图所示，不同的分支对应不同的特征。通过流量着色+流量规则路由，实现不同分支的逻辑隔离环境，支持并行开发。前端将流量标记为橙色后，全链接的请求会通过橙色链接访问。5.1.3基于多路复用的DIFF测试如上所述有了多套逻辑隔离的测试环境后，每当拉出一个新的分支环境，更新代码，流量就可以在基础环境中通过（部署上次线上代码)和新的分支环境进行回放，比较两者的返回值进行回归测试。我们的diff方案如下：该方案具有以下优点：基于流量回放的界面diff，最大程度覆盖在线用户的真实场景；全流程自动化，无需人工参与；可配置流量筛选策略和diff策略接入，方便扩展和优化；分布式任务运行支持大批量并发；5.2召回服务之间调用问题的保证契约测试5.2.1什么是契约测试？独立团队维护，服务到服务，前端和后端主要通过API调用。在这种情况下，可能会出现以下场景：A团队开发的API同时服务于B\C团队。它通过了第一个测试。但在后续的迭代中，B团队对A字段有一些调整需求，A团队根据需求进行了修改，并通过了测试。但是C队上线后发现功能异常。造成上述问题的本质原因是：当服务提供者服务的消费者数量不断增加时，服务变更的影响难以评估，服务变更无法及时同步到所有消费者，因此往往消费者发现问题反馈，造成损失。为了避免上述问题，我们引入契约测试。契约测试的核心思想是以消费者驱动的方式建立服务端和每个消费者之间的契约。服务器修改后，通过测试之前与所有消费者的合约是否被破坏来保证服务升级的安全性。.同时，合约也可以作为双方进行解耦测试的手段。通过契约测试，团队可以以契约为中间标准，以离线方式验证提供者提供的内容是否满足消费者的期望（不需要消费者和提供者同时在线）5.2.2常见的合约测试解决方案常见的合约测试解决方案包括消费者驱动的，如pact，合约由消费者生成和维护。提供者代码更新后，拉取所有消费者合约进行测试，解决了集成测试解耦的问题，保证了服务端可以满足所有消费者需求。（左图下方）也有非消费者驱动的。提供商生成合同并提供模拟服务。消费者可以基于合约文件进行测试，例如SpringCloudContract。只能解决集成测试解耦的问题（下右图）??5.2.3Aifanfan的合约测试方案Aifanfan的方案是一种妥协。一方面，由于团队习惯，合约一直由服务提供方给，另一方面希望保留消费者驱动的特性，保证服务提供方能够满足需求所有消费者。我们选择在提供者端生成合约，但通过在线日志和调用链分析的方式补充了模拟消费者端的合约案例。并且整个过程是完全自动化的。5.2.4合约测试技术实现第一步：引入swagger促进全接口接入，保证接口管理平台接口文档信息与实际代码实时同步。详细实现步骤如下；第二步：根据接口文档自动生成合约用例具有与代码同步的接口信息后，根据接口文档信息自动生成基础合约测试用例。每次向平台上传接口信息，都会检测上传的内容，并根据内容自动触发新案例的生成和旧案例的验证。验证将运行与修改接口关联的契约测试用例，以检测接口更新是否破坏了原始契约。运行结果记录在报表中，并推送给相应的团队进行标注。根据标注结果，判断是否更新案例。Step3：依托调用链和日志信息，智能分析消费者特征，生成如下图所示的模拟消费者案例。通过调用链信息，提取每个服务的消费者。通过对每个消费者的日志分析，得到模拟的Consumer合约，自动生成案例和接口进行关联；5.3智能定位问题，降低自动化维护成本。是防止大家进行自动化建设或者中途放弃自动化建设的一个重要原因。为了提高自动化的稳定性，降低后续成本，我们构建了案例故障自动定位修复能力，让智能助手帮你轻松维护案例运营。下面是我们自动定位的效果示例：我们会在自动case运行失败后调用自动定位服务，自动标记失败的case，并根据标记结果对失败的case进行分类。比如环境问题会自动重试，未知批次会发给自动化团队排查，找不到的元素会发给业务QA排查。下面是实现方案。包括基本的定位能力和基本的数据采集。基于这些基础能力，构建配置层，实现配置分析和调度能力，让我们可以灵活组合不同的定位策略，通过配置快速支持不同场景下的问题定位。6.高效安全持续发布6.1发布困境不同类型的模块接入不同的未发布平台和流程，难以统一发布。底层发布方式的改变需要对每个模块进行升级，模块数量多，拓扑复杂，迁移成本高，且模块间上线时存在依赖，每次上线100+模块，人工控制流程，风险大，效率低。在线过程的记录和分析也是非常耗费人力的。整体上线过程无形，风险感知滞后。如何解决以上问题？6.2多平台部署引擎构建基于云原生的多平台统一部署发布引擎，无缝集成CICD，实现发布流程的高度标准化，同时支持多种发布策略。如下图所示：通过CD发布平台的统一，实现各类模块的统一发布，底层部署迁移业务无感知。6.3发布脚本设计有了统一的发布平台后，为了解决发布流程复杂、效率低下的问题，我们希望实现全自动化的发布流程。分析发布前后需要做的事情，如下图所示。基于这些事项，整理出自动完成整个发布流程需要收集的数据，如右图所示，包括发布模块密封信息、依赖信息、配置信息等。基于这些数据，按照固定的编排逻辑，自动生成服务发布拓扑和本次上线的步骤。生成的在线拓扑和步骤信息经人工确认后，自动调用相应的在线发布服务进行发布，自动统计发布过程数据，生成发布过程摘要。6.4流程可视、可感知、可控一键发布在自动化分发发布流程后，为了能够及时发现发布过程中的问题，降低发布风险，进行了发布流程可视化建设，与APM、CanaryRelease等策略相结合，保证发布的安全性。发布过程可视化：服务粒度的依赖拓扑已实时启动，过程可视可感知；金丝雀发布策略：发布无损，及时发现风险并召回七次，整体营收迭代故事量提升85.8%，发布周期稳定，研发测试周期下降30%，bug率每千行从1.5减少到0.5。八、未来展望1、通过IDE本地插件工具，为开发、编码、测试流程赋能，提升研发流程效率；2、通过白盒能力，构建质量风险识别体系，并应用于准入、准入、灰度等场景；推荐阅读：｜百度短视频推荐系统的目标设计｜百度信誉认证中台架构浅析｜图数据库在百度中文中的应用｜一年几十万次实验背后的架构与数据科学----------END------------百度极客说，百度官方技术公众号上线啦！技术干货·行业资讯·在线沙龙·行业会议招聘信息·介绍资料·技术书籍·百度周边欢迎各位同学关注
