基于模式挖掘的可靠性治理探索与实践.docVIP

基于模式挖掘的可靠性治理探索与实践

本文整理自美团技术沙龙第77期《美团亿级流量系统的质量风险防控和稳定性治理实践》。本文介绍了基于模式挖掘的可靠性治理探索，为通过技术手段解决该领域代表性问题开启了新的思路。文章第一部分介绍可靠性治理的痛点；第二部分引入模式的概念；第三部分讨论新基建下的新尝试；第四部分分享三个典型的实践案例。

1可靠性治理的痛点

2模式的定义

3大数据下的尝试

4典型实践分享

4.1幂等性治理

4.2依赖治理

4.3越权治理

5QA

1可靠性治理的痛点

对于亿级流量的线上系统来说，可靠性是至关重要的。从字面上理解，可靠性要求故障少、可信赖。与安全性一样，它们都是信息系统的固有属性之一，也是保障产品质量的关键因素。

对照Google的可靠性模型来看，测试同学会投入很多精力在用例设计、测试执行、持续交付等环节上，研发同学则会更多关注监控、应急和故障分析等。但往往由于项目进度和人力因素，在设计和编码阶段对可靠性的投入和关注不足，导致后续需要付出更高的成本发现和解决潜在隐患。有鉴于此，我们希望能找到更低成本且以更有效的方式发现和治理这些隐患，从而提升系统整体的可靠性。

在研发设计阶段，我们需要关注系统弹性，考虑潜在故障风险、适应流量变化等，其中相关治理涉及幂等性、健壮性、一致性、超时、限流、熔断等场景。与一般功能测试相比，可靠性治理需要面对不同的服务和系统，发现并治理技术问题，在模糊度上有较大的提升和挑战。就目前而言，质量问题非常明确，但潜在风险策略和解决路径比较模糊。因此，我们希望能找到办法识别并解决这些问题。

模糊度的提升会带来两种最常见的现象：

一种是过于具体，CasebyCase解决问题，类似算法的过拟合，过拟合的问题在于对更广泛范围内的问题缺乏有效性。以幂等性为例，想验证一个接口是否幂等可以很快完成并很快补充接口幂等相关的测试用例，但是对不同的接口、服务、系统以及不同的幂等性设计，还有哪些问题和风险，我们没有办法关注到并控制这些风险。

另一种是过于泛化，类似算法的欠拟合，欠拟合的问题在于过度虚化导致没有抓住问题的共性特征。以主从延迟为例，主从延迟会给系统带来一致性风险，需要针对性做保护，并进行相关验证，因此我们可以制定规范、梳理CheckList和测试模板，虽然这样可以最大程度在产研各环节提醒大家关注到这类问题，但并没有找到彻底解决问题的方法。

2模式的定义

类似这些问题如何找到更好的解决办法？我们重点看一下模式对可靠性治理的启发。模式在维基百科的定义是：揭示了这个世界上人工设计和抽象思想中的规律。

例如下图所示，计算机图形学中的经典分形图案柯赫雪花，是1904年瑞典数学家科赫提出。可以看到它有明显的规律，这样的分形规律在自然界无处不在。

技术场景的模式会更加丰富些，这类模式和可靠性治理想找到的模式非常接近。

举例缓存设计的两种常见模式：

第一种是Cache-Aside（旁路缓存），也是使用比较广泛的一种方式，它只有在缓存没有命中时，才会查询数据库并更新缓存。

另外一种是Write-throught（只写模式），这种模式在每次数据库变更时都会同步更新缓存。

对比第一种模式，第二种模式的优点是逻辑更清晰、操作简单、缓存命中率更高；缺点是不常请求的数据会被写到缓存中，导致缓存更大。那么，我们如何找到这些潜在模式并应用到可靠性治理呢？我们现有的业务测试数据、专业知识积累、相关问题分析和复盘经验，都可以帮助我们找到治理这些通用技术场景的规律。在这里，很重要的一部分是真实的业务数据，我们可以从最基础的数据提取信息，找到解决共性问题的思路。

3大数据下的尝试

随着JVM非侵入式AOP解决方案的成熟，现在我们已经可以采集任意环境下的任意协议流量，以及这些流量依赖的数据关系，也可以在测试环境回放这些流量，包括线上真实采集的流量。这里依赖两个关键点：一是流量采集，这里涉及很多技术方案，这里分享主要是作为一个基础设施；二是有了全链路Mock能力，我们才能在测试环境进行各种流量的回放和验证。

另一个重要基础设施是环境隔离技术，经过快速发展，它已经具备了泳道级别的数据复制隔离，也支持一站式数据消息和部署环境的即拿即用。从最开始通过泳道降低人工测试相互影响，到现在一站式拉出一套环境，能支持各类专项检查独立运行，使用线下数据且不污染主干环境。

基于流量采集和环境隔离这两个能力的成熟，给自动化领域带来了很多新可能。流量采集信息包含了请求参数、返回值和调用链路等信息；环境隔离技术支持数据隔离、消息隔离、各种协议以及部署版本隔离。

在这种情况下，海量的业务流量可以直接转化成基于规则验证的接口自动化用例，也可以应用到基于业务模型的场景级用例，模式在这里更像是两者之间的“折中”，我们希望通过这种“折中”来解决可靠性治