本文整顿自美团技术沙龙第 77 期《美团亿级流量零碎的品质危险防控和稳定性治理实际》。文章第一局部介绍了软件系统危险与变更；第二局部介绍了代码变更危险可视化零碎的能力建设；第三局部介绍了整个零碎在美团外部实际落地的状况；最初是对将来的布局和瞻望。心愿对大家能有所帮忙或启发。
1 软件系统危险与变更
变更是软件系统进化的推动力，同时也是孕育危险的温床。如果一个零碎没有了相应的迭代和变更，那这个零碎就会逐步失去了活性和价值。不过，随着零碎进行了变更迭代，软件危险也会缓缓衍生，而躲避变更引发的软件危险在品质保障畛域是一个较大的挑战。通过对上面典型软件系统架构图剖析，咱们可提炼出 3 大类变更维度：
- 基础设施变更：次要包含根底硬件变更、运营商网络变更、云服务容器变更、开发语言变更、操作系统变更以及机房集群的变更，这些基础设施迭代极大晋升了零碎底层的服务能力，一旦变更引发零碎危险，其影响面通常也比拟大。
- 零碎内部变更：比方用户流量突增、用户需要变动以及相干三方服务及三方组件变更，这些帮忙零碎一直衍生出新的迭代能力，同时也减少了零碎稳定性危险的产生。
- 零碎外部变更：比方技术人员迭代、新性能公布以及零碎整体架构的降级等，这是驱动系统软件进化的外围变更因子，也是最频繁的变更危险发生地。
在这里，咱们先列举了一些比拟常见的、因变更危险所引发的典型线上事变：
- 内部变更所引发的线上问题，某地的光缆被挖断导致整个服务有很大的影响。
- 代码变更典型问题，谷歌 Gmail 零碎在公布新性能时产生的副作用而引发的性能上问题。
- 代码变更典型问题，Knight 公司在降级一段很老的代码时引发的异样逻辑性能产生。
- 配置变更引发的问题，所引发的“薅羊毛”事件。
- 人员操作变更，研发误操作引发的整个外围数据删除；
能够看到，在理论的工作中，由变更所引发的危险，对业务的冲击十分大。联合美团亿级流量的到家业务状态看，零碎变更引发危险可能性进一步放大，变更危险的“蝴蝶效应”更加凸显，某个单点问题都有可能给整个到家外围业务带来极大的影响。
- 第一，从到家业务接入方看，美团外部业务包含外卖、闪购、医药等等，内部有泛滥的企业客户。
- 第二，零碎参加相干方较多，包含 C 端用户、商家、配送骑手及各个平台。
- 第三，业务基于微服务架构模式，各个业务间调用关系简单，外围链路十分长。另外，业务强依赖配置，一旦某个环节产生变更问题，相干方都会受到影响。
所以对研发与测试来说，洞察与躲避变更引入的品质危险变得至关重要。
那么，对于变更危险，品质建设外围做功点在哪里？咱们对历史线上问题剖析发现，零碎外部变更引发故障的占比拟高，且变更与代码变更有间接或间接关系。因而，咱们开始围绕 代码变更 这个外围变更因子，构建了品质建设的做功点。
随后，咱们思考了两个关键问题：
- 代码变更危险是否可被可视化，晋升测试和研发感知能力。
- 围绕代码变更危险，是否可能构建一套品质保障进攻体系。
通过剖析发现，联合下图的代码特色树，咱们就能够更好地感知代码变更的可视化能力。而后通过各叶子节点，将所有相干特色很好地辨认，并且做对应的品质进攻策略。
2 代码变更危险可视化（后羿）零碎建设
传统测试模式存在两个典型问题：第一，对于研发开发的代码，短少全面可视化剖析能力；第二，对于代码变更所产生的影响范畴有多大，实际上更多地依赖研发人员和 QA 的教训。所以，在这样的传统测试模式的典型问题状况下，咱们心愿从 3 个维度做品质保障建设计划：
- 第一阶段是代码变更的感知能力，重点解决对于不同的代码状态和不同的代码工程模式，如何可能最大范畴地笼罩到所有的代码变更状况；
- 第二阶段重点做代码特色刻画，将所有变更代码抽离出不同的特色，打上作用标签；
- 第三阶段基于前两个建设能力，构建对应的利用场景生态圈，在不同测试流水线阶段，都可能将代码变更危险的刻画能力嵌入，一直做品质进攻。
而代码变更危险的品质保障建设计划最终的落地状态，是打造一个代码可视化剖析零碎，在到家外部咱们将其命名为后羿零碎。顾名思义，咱们心愿该零碎能像“后羿射日”一样，在品质危险评估和拦挡层面可能做到更加精准，同时晋升品质防御能力。该零碎架构次要分为四层：
- 第一层是根底组件层。
- 第二层是代码剖析层，重点解决对不同的代码状态都可能做到精准的代码变更剖析和辨认。
- 第三层做特色刻画层，外围解决整个代码的结构化标注和特色化标注。
- 第四层负责构建业务应用层，在不同的场景和环节下，将代码变更可视化能力嵌入到这个环节中，构建一个齐备的品质危险拦挡能力。
除此之外，咱们也会引入智能化伎俩，赋能整个零碎。同时，咱们也将外围能力通过凋谢 Open API 形式，输入到其余的品质效率相干的工具平台上，赋能美团外部的其余工具平台。
总的来说，对于后羿可视化零碎的要害流程，在应用层的透出是通过两个入口进行感知：一是后羿主站；二是工程交付平台。咱们通过异步音讯感知剖析工作和源码下载，获取对应的变更文件、变更办法和变更行号；同时再借助字节码解析能力，解析对应的调用链路变更状况，存储到图数据库里；再对变更代码做特色打标和辨认；最初会产生一份可视化剖析报告，间接给到对应的 QA 应用。
当然，在整个建设过程中，咱们也遇到了一些技术层面的挑战。
第一个挑战是代码剖析技术。在零碎建设初期，通过 AST 单剖析能力做代码剖析和辨认，但存在 Lambda 表达式辨认问题和 Java 泛型辨认问题，在此基础上引入了 ASM 字节码剖析技术解决了后面的问题，但 ASM 也会有本人的 Java 反射个性相干问题无奈辨认。所以咱们心愿将来引入动态化代码剖析技术，来解决反射类问题。
第二个技术难点是海量关系数据存储问题。在建设之初，通过关系型数据库做存储，但随着零碎的广泛应用，存储了大量调用链路拓扑关系数据，但它的查问性能十分差。所以在此基础上，咱们通过摸索引入图数据库的存储形式，解决了在海量数据关系存储数据的查问性能。
第三个技术难点是代码危险特色多样性，像个性化特色跟咱们的业务有强相关性，比方资损特色、对应的分页特色和多线程特色。针对这种危险特色，咱们之前的开发模式是零碎开发者和业务 QA 深度沟通对应的辨认策略，但这样的形式沟通效率和开发周期都比拟长。
因而咱们做了整体能力改良，通过开发一套组件化开发框架，将整个开发框架凋谢给各业务线 QA，他们能够本人开发定制化开发组件，加载到后羿零碎，实现多样性特色的疾速辨认能力。
3 代码变更危险可视化（后羿）零碎实际
接下来，咱们重点给大家介绍零碎的实际利用落地状况。如下图所示，该图为后羿品质保障利用场景生态全景图。目前后羿零碎整体建设了八个外围利用场景：
- 技术计划层面校准诊断
- 在 Code Review 阶段能力的加强
- 变更影响面评估
- 接口级的用例举荐
- 配置变更危险诊断能力
- 兼容性危险诊断能力
- 代码特色危险预警
- 凋谢 Open API 能力
首先技术计划缺失项诊断，在我的项目测试过程中，次要蕴含以下 2 个痛点：
- 研发写技术计划时，标准化水平较低。
- 两头反馈的问题对于技术计划更新时效性较差，但咱们发现技术计划对 QA 来讲是一个关键性的依赖输出，从而导致 QA 在写测试用例时，往往会遗漏掉一些关键性的变更信息，比方接口定义变更缺失、配置项定义变更缺失、定时工作变更缺失、异步音讯变更缺失以及 DB 表字段变更缺失，这些信息往往在技术计划里更新不全面。
基于这样的状况，后羿零碎通过对代码的辨认，可能真正拿到在本次代码层面上，真正变更了哪些信息，再拉取对应的技术计划做解析，再做要害变更信息项的 Diff，从而生成一份技术计划的缺失项诊断报告给到对应的 QA，QA 能够依据此报告做对应的诊断项卡点拦挡，同时做测试用例的欠缺补充。
第二个利用场景是增强版的 Code Review 评审新模式，传统的 Code Review 也面临几个痛点问题：
- 研发在整个 Review 过程中更多地聚焦在编码标准和架构设计合理性上。
- 常态化的 Code Review 模式基于纯文本，它也有几个痛点：第一是无奈针对 Review 的过程做变更办法的上下游疾速跳转查看；第二无奈做到对变更办法、改变办法的跳转或调用链路的业务逻辑出现。
基于这样痛点问题，后羿零碎打造了基于变更链路场景驱动 Code Review 新模式，外围解决在 Code Review 阶段可能更早地感知品质危险。其外围做法是后羿零碎在 Review 一个变更文件时，可能疾速提炼出变更文件里对应的变更办法、变更变量以及这些变更办法和变量上都具备哪些危险特色，从而让 QA 和 RD 疾速抓到变更的重点信息。
在此基础上，咱们也提供了变更办法的上下游疾速跳转能力，基于 Review 过程中做变更办法的疾速跳转，了解整个业务的上下游关系，同时在跳转过程中，可能将跳转的逻辑点实时绘制成调用拓扑图，感知变更办法之间的业务逻辑关系，更好地从整个链路视角评估本次代码变更的影响状况，很好地解决在 Code Review 阶段的痛点问题。
第三个利用场景是变更影响范畴评估，目前后羿零碎构建了六大变更影响范畴评估能力：
- 代码根本属性，比方变更了哪些办法；
- 可能反对到 HTTP、RPC 以及 JAR 包等不同状态代码工程类型；
- 可能对通用危险特色做辨认，比方事物递归兼容性问题；
- 能够对定制化危险特色做辨认，比方权限、算法特色；
- 能够反对单服务影响，包含办法调用链路，接口特色、音讯特色、工作特色等等；
- 跨端服务的影响面评估，比方一个服务外部的调用链路和在不同的微服务之间的跨端变更点之间的链路影响是什么样子的，都可能做到更精准地影响范畴评估能力。
影响面评估示例：
- 一个变更接口被影响到了，那么它的上游到底是哪些变更办法影响的？咱们可能很直观地看到这个变更接口上面有哪些新增的和变更办法所影响到的。
- 上游所变更的影响办法之间的链路调用拓扑关系是什么样子？咱们可能通过链路拓扑图，疾速绘制进去对于这个接口上面所有变更办法之间的调用链路。
- 对应的变更办法对于接口两头所有办法的调用链路详情，咱们也可能通过这个能力疾速做评估和刻画。
- 对于一个接口上面所有办法的链路调用关系是什么样子？咱们也提供了一个全办法链路的视图剖析能力。
第四个利用场景是配置变更的危险诊断，在比较复杂的大型业务上，整个系统对配置往往有强依赖关系，比方典型的灰度配置、降级配置以及外部逻辑相干管制配置项，对于整个零碎的影响比拟大，但往往 QA 和研发人员对于配置危险的把控实际上比拟缺失，认为代码可能更多的是品质保障的重点，所以因为配置所导致的线上问题比拟多，造成的后果比较严重。
基于这样的外围痛点问题，后羿零碎重点从三个层面做了对于配置变更危险的外围能力建设：
- 在配置的变更辨认剖析层，咱们可能很好地对各种类型配置做精准辨认：是新增还是变更。
- 通过后羿影响面评估能力，拿到配置所影响的接口、影响链路以及对应影响的异步音讯和定时工作。
- 有了影响面评估后，咱们可能更好地通过测试，将变更场景做到笼罩，由此构建了配置变更测试笼罩度量。因为咱们在配置测试过程中对于测试后果的感知能力不强，因而通过基于流量开掘、流量录制能力构建了实时感知配置测试的笼罩状况。在整个流水线层面，通过要害配置变更卡点能力更好地进攻配置变更所引发的一些问题。
下图是咱们目前所建设的利用性能页面：
第五个利用场景是服务端兼容性的危险诊断。咱们通过对线上问题做汇总剖析发现，新老兼容性这类典型问题占比拟高，咱们尝试通过后羿零碎解决，QA 可能做简略的兼容性问题辨认，比方一个接口的入参返回值有显著的字段新增或类型变动会明确判断进去。
但在兼容性问题剖析上，有一类不太显著的变动导致了兼容性问题，比方入参层面有一些约束条件、由可选字段变成了必选字段，这类变动实际上在整个代码定义层面很难感知到；另外一类是变更参数是通过外部间接调用 VO 类间接组装进去的，实际上对于 QA 也很难感知外部间接 VO 类变动的兼容性危险影响。
所以后羿零碎基于这样的痛点，构建了反射和序列化，从而疾速拿到对应的底层变更 VO 类所导致的对接口影响能力，给出兼容性接口预警，QA 依据这样的剖析诊断报告，进一步评估对应的兼容性和上线程序的合理性安顿。
第六个是接口级自动化用例举荐，对于到家的简单业务，咱们积淀的很多自动化用例怎么用，是全量回归还是选择性筛选，也是比拟大的痛点问题。因而后羿零碎基于所具备的辨认变更办法、剖析影响链路以及对应的接口能力，买通和到家智能代码覆盖率平台所具备的历史流量笼罩状况，可能疾速拿到变更接口和办法，再借助一体化平台，拿到对应的自动化用例，做精准的自动化用例举荐，从而构建了用例举荐整体解决方案。
第七个典型的利用场景是代码品质危险特色预警，咱们在品质建设过程中，往往会遇到一类比拟非凡的场景须要验证，比方资损类场景，除了验证性能外，还须要对资损做个性化危险性能场景验证、异样场景验证、非凡分页逻辑、重试场景验证，但这些场景在整个代码过程中，咱们往往很难发现这些特色危险，从而遗记验证非凡场景状况。
针对这个问题，后羿零碎从两个方面构建了特色危险辨认性能：一是零碎会本人构建通用危险特色辨认策略模型，二是各业务方也会本人打造对应的危险特色辨认策略。
如下图所示（最下侧），是目前曾经具备和将来将要建设的特色辨认能力。有了外围辨认能力后，咱们再将对应的特色在所要验证过程中相应上下游的依赖平台做工具能力整合，对于不同特色构建出绝对应具体测试策略的举荐策略，将这几个能力买通后构建出一套基于代码品质危险特色的体系化品质保障计划。
第八个利用场景的能力是凋谢 Open API 的赋能能力，咱们心愿将后羿系统分析辨认的信息，通过凋谢 API 的形式走漏进来，可能给到对应相干工具平台应用。目前在到家范畴内曾经将整个能力凋谢给了接口治理平台、智能代码覆盖率平台、全息零碎、异样测试平台、自主工程交付零碎以及一体化自动化平台这六个外围的效力工具建设平台。
4 将来布局与瞻望
联合具体的实际，以及此前总结的教训。将来，咱们将从四个方向做将来品质保障建设：
- 代码剖析技术的加强，心愿可能通过动静链路剖析技术，晋升整体的剖析准确性。
- 危险特色辨认技术，心愿可能基于大语言模型相应能力对危险特色的剖析和对应测试策略做举荐。
- 进一步丰盛利用场景生态圈，摸索在不同测试环节、不同测试场景下，将后羿能力做更好的整合，赋能到具体的业务品质建设中。
- 长期来讲，心愿将零碎的外围能力，通过开源共享形式赋能给相干测试畛域。
5 Q & A
Q1：单次剖析报告耗时是多久？同一个工程代码的报告间是独立的还是有关联的？
A：目前 1 -2min 可产生剖析报告。报告是基于迭代工作维度生成的服务级报告，比方一个我的项目迭代里有 5 个工程代码变更，那么这 5 个工程代码变更关系会作为一个整体剖析，体现到报告里。
Q2：链路的拓扑关系是怎么实现的？
A：链路的拓扑关系基于 AST 技术和 ASM 技术进行剖析，同时，联合线上 Mtrace 链路关系作为补充。
Q3：微服务多模块之间的服务调用链路可辨认出关联性吗？如 HTTP 接口后续调用多 RPC 服务接口?
A：微服务多模块之间的服务调用链路可辨认出关联性，比方 HTTP 的上游会调用了哪些 RPC 接口，目前具备可辨认能力。
Q4：底层办法的调用链十分多，这种有举荐策略吗？DB 变更是扫描 Mapper 吗？
A：目前对于调用链路会进行危险特色打标解决，比方：链路蕴含资损特色、配置特色等，通过特色危险标签可能更好的让用户感知到链路危险等级，为后续测试策略提供要害信息举荐。目前 DB 变更是通过扫描 Mapper 进行辨认的，基于 Mybatis 整体 DB 开发框架做变更扫描。
Q5：对于用例举荐，是举荐单例接口还是会组合成场景接口？
A：目前是举荐单接口用例，比方这个变更接口关联了 10 个自动化用例，咱们会把这 10 个自动化用例举荐进去。
Q6：剖析一个工程大略会破费多长时间？
A：目前要花费 1 -2min 工夫。
Q7：理论利用中，次要收益是什么？
A：次要收益是基于八大利用场景落地利用，所有利用场景都会给品质与效率带来价值收益，比方在兼容性问题上已胜利拦挡多起兼容性品质问题；在配置变更危险评估上，已胜利拦挡多起因配置默认值编码谬误、线上线下配置不统一问题。
Q8：这套平台是否会对线上服务可用性带来影响？
A：目前这个平台对于线上服务可用性不会造成影响，针对线上环境进行剖析时，外围操作是拉取线上对应的部署 JAR 包，不会对事实服务造成可用性影响。
Q9：这个零碎有护城河吗？这个零碎收益是什么？对业务有什么帮忙吗？在业务上有什么体现吗？
A：说到“护城河”，变更剖析底层技术上次要还是基于 AST 和 ASM 通用技术，外围是对各种业务代码编写形式的兼容反对、业务场景特色辨认精度等维度上有肯定的技术挑战。
次要收益集中在变更带来的业务影响范畴的危险评估及对品质危险的无效拦挡上，目前已胜利拦挡多起接口影响范畴评估不准的 Bug、配置变更相干 Bug、兼容性 Bug 等。
在业务帮忙上，一是八大利用场景可能给整个品质和效率带来晋升；二是可晋升对业务了解的效率，比方通过接口上游调用链路可视化能力，可很快了解这个业务链路关系。
Q10：链路拓扑过大，怎么解决，不同服务应用语言不同，字节码技术有啥举荐吗？
A：链路拓扑过大时，可通过链路聚合来归类晋升可视化，针对美团是 Java 技术栈，重点在冲破 Java 辨认能力，其余语言服务剖析后续会继续关注与解决。
Q11：能够剖析出对上下游服务的影响吗？
A：是的。
Q12：剖析代码变更，如何辨认无效变更和有效变更？
A：比方变更了一段代码，它有可能没有调用方，咱们叫做预埋类代码。相似这种代码在测试过程中很难用业务场景进行验证，而且将来上线后很可能会引入潜在危险，目前通过链路变更剖析可无效辨认此类预埋代码危险。
Q13：零碎应用的阶段都是什么？准入阶段还是准出阶段？
A：目前零碎在准入和准出阶段都能够应用，没有做严格限度。
Q14：辨认出的问题乐音烦扰多吗？
A：从乐音烦扰层面讲，咱们做了很多晋升识别率的策略优化，比方 HTTP/RPC 接口识别率目前已达到 98% 以上，乐音烦扰可做到很好的管制。
6 本文作者
桂来，来自美团到家研发平台。
| 在美团公众号菜单栏对话框回复【2022 年货】、【2021 年货】、【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。
| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。