如何做到行业领先？腾讯会议背后的研发效能改进历程

从2020年下半年开始，腾讯会议启动了基础建设与调研。2021年，腾讯CSIG技术委员会研发效能提升组成立，腾讯会议作为第一批试点业务团队，正式启动了研发效能专项，目标是通过半年的专项共建提升团队的整体研发效能，图1是研发效能建设规划。

图1 研发效能建设规划

腾讯会议研发效能体系建设分别从开发域、测试域、部署域、运营域4个方面输出解决方案，对存在的问题逐个击破。

开发

开发域的研发效能建设主要分为两个方向：标准化建设和工具建设。

腾讯高级管理顾问乔梁说：“一致性是效能提升的必经之路”。没有标准，散乱的微服务就如同一盘散沙，无法形成合力。这也是腾讯会议要从标准化建设入手建设研发效能体系的原因。

标准化建设

腾讯会议的标准化建设包括语言、框架和流水线。

统一语言和框架

由于历史遗留等原因，腾讯会议存在技术栈不统一、缺乏统一规范的问题。

统一语言和框架可以大大减小开发差异和减少学习成本，也有利于团队内部研发进行组间流动和需求支持。从语言的角度看，没有任何一门语言能“一统天下”，但从腾讯会议的角度看，肯定有一门最适合腾讯会议目前现状的语言。

在研发效能建设专项成立后，腾讯会议对比了腾讯内部各业务的使用情况，分析了各门语言和框架在公共组件的适配程度，以及语言和社区的学习成本，最终选择公司内部主流的Go语言 + tRPC分别作为开发基础语言和框架。

这时，又面临一个困难：若统一语言，那么存量的业务模块怎么办？

对此，我们采用的策略主要有阻断新增、限时重构，减少支持的力度。最终，腾讯会议采用Go语言 + tRPC的覆盖率已超过95%，完美地实现了语言与框架统一的目标。图2所示为统一语言与框架图。

图2  统一语言与框架

统一流水线

在研发效能建设前，腾讯会议项目下有一百多种风格的持续集成（CI）流水线。在研发配置流水线时，由于对流水线的设计在很大程度上靠“觉悟”，因此统一流水线的建设其实是统一研发流程的起点，因为这是提升代码质量的切入口。比如，如果某个第三方组件存在安全风险，则可以通过在流水线上增加Hook来添加相关的校验规则。

腾讯会议通过标准化接入、统一基线流水线配置模板等方式，让流水线逐渐统一，达到控制提交代码质量、流程和规范的效果。

我们基于研发现状梳理了各条流水线的工作流，如图3所示，按照研发过程流水线被拆分为5条：开发流水线→提测流水线→合流流水线→主干流水线→预发布流水线。

图3  流水线工作流

• 开发流水线：通过提交代码触发，在个人开发环境下完成代码扫描、单元测试，以及单组件冒烟自动化。

• 提测流水线：通过扭转TAPD状态触发，在集成测试环境中完成产品P0用例自动化回归、开发自测，以及测试验证。

• 合流流水线：通过MR触发，在集成测试环境中实现产品P0用例的自动化回归、Code Review、自动打包。

• 主干流水线：通过定时或提交代码触发，从而实现单组件P0用例回归、自动打包。

• 预发布流水线：通过手动或者打标签触发，完成发布测试区、多产品P0用例自动化回归。

以开发工作流为例，统一流水线改造的内容，如图4所示。

图4 开发工作流统一流水线

√通过流水线模板创建开发流水线，确保执行的内容一致，也可以是一个代码库对应一条流水线。

√监视分支代码变更，有推送时自动触发。

√必要的门禁保障，如单元测试、代码分析等。

√环境部署建议通过子流水线来维护。

开发流水线实例，如图5所示。

图5 开发流水线实例

工具建设

在工具建设方面，腾讯会议分别从服务脚手架、性能分析、接口即文档等方面进行了研发效能建设。

服务脚手架

在进行研发效能建设前，团队研发人员经常反馈：项目从零开始搭建非常复杂，各个项目间的差异非常大，交接、维护成本高等。

在研发效能建设开展后，我们通过服务脚手架建设解决上述问题，服务脚手架实例如图6所示。

图6  服务脚手架实例

首先通过CODING平台的服务接口功能编写PB文件，然后根据基础项目模板一键生成项目代码。新生成的项目能直接部署、运行，并符合开源治理规范，便于进行后续的自动化流程，如代码质量检查、镜像构建等。

性能分析

在性能分析中，腾讯会议的自研工具——火焰图（图7）可以与CODING应用管理无缝集成，做到一站式闭环。火焰图集成是Golang官方的性能调优利器，通过可视化能直观呈现CPU和内存等消耗情况，同时支持多维度在线性能分析，10秒即可完成性能分析，对服务的关键指标和热点消耗做到一目了然。

图7  性能分析-火焰图实例

接口即文档

随着业务规模的迅速扩大，文档问题一直为大家所诟病，特别是在接口对接、联调过程中，“口口相传”成为常态。

研发效能建设开展后，腾讯会议通过自研接口，即文档工具，无缝闭环嵌入CODING应用管理。通过规范接口定义和注释说明，使定义PB、定义接口自动生成对应的接口文档，从而实现一站式的统一管理，摆脱了“口口相传”的困境，也降低了沟通的信息差与成本。接口文档前后对比如图8所示。

图8 接口文档前后对比

测试

腾讯会议在测试域的研发效能建设主要从环境治理、快速更新、接口测试与压测3方面入手。

环境治理

环境治理分为环境构建和环境编排两部分。

环境构建：在进行研效建设前，腾讯会议环境单一，“千人一面”。

腾讯会议后台日常并行的需求有100多个，但测试环境只有一套，这显然是不够的，并且环境冲突问题频繁出现，经常阻塞测试进度。如果直接采用横向扩展的方式，把一变成十，则维护十套测试环境的常态化对人力的投入非常大，而且治标不治本。因为各套环境的一致性无从保证，服务质量更无从说起。

在研发效能建设开展后，如何“一键快”速构建环境变成腾讯会议必须攻克的难题，环境治理就此诞生。

腾会议对测试环境的要求同需求的生命线持平，由需求而生，也由需求而止。

CODING平台提供的环境管理能力，支持快速构建一套全新的、独立的All in one环境，构建时间一般在分钟级，最长不超过20分钟，并且互相隔离，保证互不干扰。另外，新环境的质量也有对应的度量指标，如在环境构建完成后，需要测试一遍全量的自动化用例，保证环境交付的质量，如图9所示。

图9 环境构建前后对比

环境编排：环境编排是腾讯会议特有的，也是研发效能建设中重点克服的难题之一。

由于腾讯会议的服务都是基于镜像的模式，因此100多个服务就有100多个镜像，而每个镜像都单独部署，资源和成本的压力非常大，并且腾讯会议的私有化场景也是刚需。比如，某银行购买了一套腾讯会议产品，需要进行私有化部署，但是能提供的机器可能只有2台或4台。

如果没有动态编排环境的能力，则会频繁遇到资源严重不足的问题，故环境编排由此诞生。

腾讯会议的环境编排支持根据自身的需求动态编排模板，快速生成一套环境。在环境中，可以把全量的服务合并到一个镜像，也可以自由编排，把某些服务合并到一个镜像。多个镜像和服务可以灵活组合编排，并支持自动化构建和部署，如图10所示。

图10  环境编排解决方案

快速更新

在腾讯会议的研发效能建设中，快速更新的诉求其实来源于开发层面：如果一个小变更的改动需要5秒钟，而发布需要5分钟，则显然是不能接受的，快速更新就此诞生。

在进行研发效能建设前，采用的是“编译+打包+冷更新”模式；在进行研发效能建设后，快速更新采用的是“编译+上传+热更新”模式。简单来说，使用了“一键式”自动化的RZ工具。以前更新一次需要5分钟，现在只要30秒，开发人员的幸福感有了明显的提升，快速更新解决方案图如图11所示。

图11  快速更新解决方案

接口测试与压测

在进行研发效能建设前，研发人员经常反馈：接口协议多，自测和Mock困难，并且测试工具不完善，测试左移也愈发成为讨论的话题之一。

在研发效能建设展开后，自研的接口测试与压测工具被无缝集成进入 CODING 平台，做到了测试与压测一站式闭环。同时，支持腾讯会议常用的多种传输协议，如Oidb、tRPC、HTTP 等，支持自动关联服务接口并自动保存测试用例，如图12所示。

图12  接口测试与压测实例

部署

腾讯会议的部署域研效建设主要从部署优化和部署编排两部分入手。

部署优化

容器化：腾讯会议作为自研业务上云的首批业务，在整体架构上采用了容器化的云原生方案，真正做到弹性伸缩、自动扩容、异地容灾备份、服务化治理。在研发效能建设的过程中，腾讯会议全面使用腾讯云的云原生组件和能力，比如TDSQL、对象存储、CDN加速器、文件存储、日志监控、消息队列等。基于云原生模式，会议的开发、测试、部署、运营等四个域的研发效能全面得到提升，也让腾讯会议在快速成长时得以保持敏捷的迭代节奏。容器化历程如图13所示。

图13 容器化历程

发布提速：腾讯会议发布提速的诞生来源于一次次对故障的总结。

在研发效能建设前期，若要在生产环境里进行发布操作，需要十几分钟到一个多小时，回滚亦是如此，这就严重影响了研发效率和质量。

经过层层分析和总结容器发布时间的构成，腾讯会议在研发效能建设时把优雅终止时长、Pod销毁时长、Pod启动时长、就绪检测时长等每一环节都进行了逐一击破，如增加StopSignal、优化轮询间隔、优化镜像大小等。针对一次发布操作，优化前一般需要8分钟，优化后只需1.5分钟，极大地提升了效率，发布提速解决方案如图14所示。

 图14 发布提速解决方案

镜像瘦身：镜像瘦身的目的也是提速。带宽不变，体积大小就是关键因素，镜像体积越大，发布时间就会越长。

在研发效能建设展开后，腾讯会议通过层层抽丝剥茧的，努力达到瘦身等目标，如删除日常不需要的包、压缩镜像体积等，把原来近4GB的业务镜像缩小到300MB，发布效率有了显著的提升，如图15所示。

图15 镜像瘦身前后对比

编排部署

在研发效能建设前，腾讯会议一次发布部署需要操作七八个平台，平台多且杂，自动化程度低，稍有疏忽可能就会变成一次发布故障。

在研发效能建设展开后，腾讯会议的持续部署（CD）全部被闭环在CODING平台。从持续集成（CI）到持续部署无缝对接，彻底改变了之前“盯点式”的发布困境。CODING持续部署除了支持自定义部署编排，还提供变更体检功能，可以及时发现由发布操作引起的故障。编排部署实例如图16所示。

  图16 编排部署实例

运营

腾讯会议的运营域研发效能建设主要体现在可观测性上，如日志、监控、调用链-链路跟踪、自动拨测与压测。

统一日志

在研发效能建设前，腾讯会议后台使用的日志组件非常多，有CLS、ULS、鹰眼等，缺乏统一的规范，研发人员根据各自的经验自由发挥，导致产生的问题非常多。比如，在出现问题排查时，发现日志丢失；有的服务一天打100TB的日志，造成极大的成本压力；缺乏统一的管理机制，研发人员感知不到问题。

在研发效能建设展开后，腾讯会议进行了统一日志建设，使用CODING平台可观测模块的日志功能，并基于CLS平台主动采集，对业务代码做到零侵入；制定相应的度量指标，每天定时统计各个服务前一天的日志量，让每个研发都能掌握服务日志的量化数据，更好地评估日志的有效产出，进行成本优化。

统一运维

作为统一运维的重要环节，不管是发现故障及时告警，还是定位排查问题，监控平台的搭建都是至关重要的。在研发效能建设前，腾讯会议后台使用的监控组件也非常多，有传统的Monitor、停止维护的秒监控、007和云监控等，研发人员根据自己的熟悉程度自由发挥，没有统一的管理入口和继承机制，导致产生一系列问题。例如，某个研发人员离职了，服务交接没有把监控的链接告知交接人，就永远找不到该监控；在使用的众多组件中，每新增一个指标都需要在平台上创建指标，缺乏维度功能，而且维度单一，只有单维度的上报，成本非常高。

在研发效能建设展开后，腾讯会议进行了统一监控建设，同时也对多个监控平台进行调研，最后选择了CODING应用管理上的监控功能。基于云监控平台，做到自定义指标、模调等多维上报，对业务细节一目了然；还有很多“一站式”的平台打通，如自动告警、变更体检等。统一监控实例如图17所示。

图17  统一监控实例

调用链-链路跟踪

在研发效能建设前，当腾讯会议出现问题时，因为调用链模糊、缺乏统一的平台和工具，所以解决问题所需要的时间比较长。

在研发效能建设展开后，腾讯会议进行了统一调用链建设，选择了 CODING 可观测模块的Tracing功能：基于云监控平台，对服务间的调用依赖关系和性能关键热点一目了然。腾讯会议整体的接入过程也非常简便，做到了代码低成本、零侵入。

拨测与压测

在研发效能建设前，研发人员经常反馈：自动化拨测覆盖率低，系统监控弱，故障发现不及时；缺乏系统压测，对当前的状况和瓶颈一无所知。在研发效能建设展开后，腾讯会议进行了核心链路的统一梳理，做到分钟级自动化拨测，若出现不符合预期的情况，则会触发实时电话预警，拨测覆盖率提升至95%；在系统压测方面积累了大量的测试用例，定期对系统进行压测与状况评估。同时，还在推进混沌工程的评估试点。自动化测试实例如图18所示。

图18  自动化测试实例

最后：下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

全部资料获取