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

如果无法正常显示，请先停止浏览器的去广告插件。

1. 基于模式挖掘的可靠性治理探索美团优选事业部

2. 自我介绍孙玉鑫，2018年加入美团专注于服务端质量保障和效率提升，在自动化建设、稳定性治理等方向积累了较多经验

3. 目录 1. 可靠性治理的痛点 2. 什么是模式 3. 大数据下的尝试 4. 典型实践分享

4. 为什么要做可靠性治理安全性和可靠性都是信息系统的固有属性，却很容易成为换取更快交付速度的代价，而事后则需要高昂的修复成本。对照Google可靠性七层模型，我们日常在设计和开发阶段的可靠性相关投入较低。而这一阶段积累的问题，需要在后续的容量规划、测试、发布、复盘、应急和监控等多个环节投入更高成本来发现。基于这个现状，我们需要找到低成本且有效的方式来发现和治理这些问题。

5. 可靠性治理的挑战面向弹性的设计幂等性、健壮性、一致性… 模糊度超时、限流、熔断… 面向失败的设计模糊度 … 面向变化的设计容量规划、容量验证…

6. 最常见的两种情况 Overfitting：很多时候我们只能Case By Case的处理单点问题，无法解决潜在的同类问题。例如一个接口存在幂等性问题，那么我们可以很快修复问题，并添加幂等性相关的用例。但还有哪些接口有问题是无法穷举的 Underfitting：我们清楚知道某一类问题需要被关注，但不能确定具体的解法。例如主从延迟会带来一致性风险，我们会强调相关验证的重要性，并制定规范，但由于没有确定的规则，并不能保证这一类风险得到控制

8. 目录 1. 可靠性治理的痛点 2. 什么是模式 3. 大数据下的尝试 4. 典型实践分享

9. 模式的定义维基百科中的定义： A pattern is a regularity in the world, in human-made design, or in abstract ideas 「模式」揭示了这个世界上，人工设计和抽象思想中的规律。 1904年，瑞典数学家柯赫构造了 “Koch曲线”几何图形

10. 软件工程中的模式 1991年Erich Gamma获得博士学位后去了美国，在那与Richard Helm, Ralph Johnson、John Vlissides合作出版了Design Patterns - Elements of Reusable Object-Oriented Software 一书。在此书中共收录了23个设计模式。这四位作者在软件开发领域里也以他们的匿名著称Gang of Four （简称GoF），并且是他们在此书中的协作导致了软件设计模式的突破。

11. 软件工程中的模式 2017年，微软AzureCAT模式和实践团队在Azure 架构中心发布了9个新的微服务设计模式，并给出了这些模式解决的问题、方案、使用场景、实现考量等。 • 外交官模式（Ambassador） • 防腐层\防损层（Anti-corruption layer） • 后端服务前端（Backends for Frontends） • 舱壁模式（Bulkhead） • 网关聚合（Gateway Aggregation） • 挎斗模式（Sidecar）

12. 技术场景中的模式 Cache-Aside (Lazy Loading) Write-Through

13. 如何找到这些模式业务数据、用例积累、专业知识、故障复盘等，都是有效的输入，其中来自真实用户行为的海量业务数据蕴含巨大的潜力。

14. 目录 1. 可靠性治理的痛点 2. 什么是模式 3. 大数据下的尝试 4. 典型实践分享

15. 流量采集技术的成熟随着JVM非侵入式运行期AOP解决方案的成熟，我们可以进行任意环境下各种协议流量和依赖数据的采集。也可以在测试环境回放线上的真实业务流量。

16. 环境隔离技术的发展依托分布式弹性块存储服务，测试数据隔离已经具备一站式解决方案，如存储编排快速构建和销毁、存储编排管理、数据隔离与自动路由、数据同步/导入等，业务在使用时只需做简单的配置即可做到测试环境数据“即拿即用”。

17. 自动化测试还有哪些可能流量采集和环境隔离的能力，给自动化测试带来了新的可能，也让可靠性治理有了新的思路。流量采集请求参数返回值调用链路 ...... 环境隔离数据隔离服务隔离消息隔离 RPC隔离 ...... 规则（接口用例）模式模型（场景用例）

18. 为什么是模式业务测试可以结合代码逻辑和业务模型，进行功能覆盖。但可靠性治理不同，我们需要识别技术选型，挖掘潜在模式，面向不同业务解决一类问题。相较于规则测试有更高的模糊度挑战，相较于模型测试有更高的通用性要求。 • 变更识别模型 • 功能覆盖 • … • 幂等测试模式 • 健壮性测试 • … • 接口测试规则 • Diff测试 • …

19. 目录 1. 可靠性治理的痛点 2. 什么是模式 3. 大数据下的尝试 4. 典型实践分享

20. 案例一幂等性治理

21. 幂等性治理-背景维基百科中的定义：Idempotence is the property of certain operations in mathematics and computer science whereby they can be applied multiple times without changing the result beyond the initial application 一元运算中，当运算f满足f(f(x))=f(x)时被认为是幂等的。二元运算中，为集合S的元素x配备二元运算∗，则∗在满足x∗x=x for all x ϵ S时被认为是幂等的。 HTTP/1.1规范中的定义：Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request

22. 幂等性治理-背景业务场景中的幂等：在大规模分布式系统中，请求超时、网络抖动等随时可能发生。幂等性设计是保证服务在高并发的情况下高可用的关键。对于每天产生海量订单的零售业务，库存、交易、支付和财务等系统更需要通过幂等性来避免超卖、重复支付、重复打款等问题的发生。技术场景中的幂等：幂等性除了对业务场景至关重要，同时也是消息队列、定时任务、分布式事务等技术类场景稳定运行的基础。 Non-Idempotent Idempotence Key

23. 幂等性治理-模式挖掘由于幂等性的实现方案有很多种，不同的实现方案需要不同的检查策略。在对获取的流量进行幂等性检查之前，我们需要确定哪些流量是要检查的，同时也需要结合流量的调用过程等信息标记检查的策略和优先级。唯一索引 • 通过在数据库中的表设置唯一索引，保证索引相同的请求只能有一次写成功，可以通过先查后写，或者处理 DuplicateKeyException保证幂等性悲观锁 • 可以通过版本或者其他状态条件来实现，在数据库查询和更新操作时锁表乐观锁 • 乐观锁只在数据更新时锁表，其他时候不锁表，所以比悲观锁效率高 • 有限状态机（FSM）也是乐观锁的一种，以单据相关业务为例，当状态机已经处于下一个状态，这时来了之前状态的改变是不能成功的，就保证了有限状态机的幂等性 Token • 由一组有业务含义的参数组成UniqueKey，通过UniqueKey检查保证不会出现重复提交分布式锁 • 对于分布式系统，构建全局唯一索引比较困难，这时候可以引入分布式锁，同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁（分布式锁要第三方系统提供）

24. 幂等性治理-模式挖掘分析调用链路发现，当链路上某个节点不幂等而对资源产生副作用后，其后的多个节点都可以检测到相关变化。例如，前序节点通过 DB的写入生成了新的单号，后序节点的参数和返回值很可能会出现这个新单号。这样，我们就可以构造多次同样的请求，之后检查链路上的这些变化来验证幂等性。

25. 幂等性治理-模式挖掘调用链路节点的类型包括了MYBATIS、RPC（Pigeon/Mtthrift)）、HTTP、Mafka（消费端）、Crane等，不同类型节点的检查策略和优先级都不同。我们会将调用过程中不同类型的节点分开检查，通过对实际检测结果的数据分析，我们发现MYBATIS节点的有效性更高。

26. 幂等性治理-节点检查策略节点类型优先级检查策略 Ø 比对：验证有增/删/改操作且成功的节点信息是否有变化 MYBATIS Ø 降噪：高 • 识别幂等表、主键冲突、抢锁失败等命中幂等性方案情况 • 识别log后缀的日志表、history后缀的历史表等 Ø 比对： THRIFT • 识别leaf.IDGen等随机ID生成接口中 • 验证接口的请求和返回是否有变化 Ø 降噪：识别请求参数和返回值中的时间戳字段、随机字段等 SQUIRREL/ MAFKA … Ø 比对：验证节点的请求和返回是否有变化低 Ø 降噪： • …

27. 幂等性治理-应用场景场景自动化接口自动化流量自动化

28. 案例二依赖治理

29. 依赖治理-背景伴随分布式微服务的发展功能被分解到各个离散的服务中，系统正在变得越来越复杂、调用链路越来越长，如提单接口的下游依赖可以多达上百个，任何外部依赖的抖动都会成为核心业务的威胁，而提升交易服务可用性需要提升系统容错能力，即保障交易系统能够在链路中的某些一个或多个组件故障发生时继续正常运行，系统容错能力在高可用性或生命攸关的系统中尤其重要，如面向用户端的服务。依据“Chain of threats（威胁链）”，Error（错误）和Failure（故障）Fault（故障）之间存在因果关系。可以笼统地解释故障发生之前产生几个错误，通过传播最终会引起故障。起因为系统内部的或外部的错误被激活，经过裁定后定义为服务编排内部错误，这时对外部用户是无感知的，但是错误在服务内部不断传播，导致系统偏离正确的服务状态造成服务失败，最终会导致业务失败引起外部用户可感知的故障。对于可用性高达99999的服务，当服务规模大于10000时，小概率的硬件故障每天都会发生。

30. 依赖治理-模式挖掘业务上可以通过依赖分级和熔断策略，保障弱依赖故障后核心流程可用。依赖治理的关键在于如何自动化的完成分级合理性及熔断策略有效性的验证。

31. 依赖治理-检查策略依据接口和依赖的关系，构造指定依赖的故障场景。 1. 注入异常后，故障没有被捕获，直接抛到了外层入口或接口的返回值信息异常，则认为此依赖是一个强依赖 2. 注入异常后，后续调用链被阻断（通过路径对比，判定依赖是否被阻断）则认为此依赖为强依赖 3. 注入异常后，后续调用链未被阻断则认为此依赖为弱依赖

32. 依赖治理-应用场景运营主要包括两方面，配置检查和业务验证。针对配置正确与否的检查每周运行，发现依赖等级与熔断策略不符合的推动修改，业务验证每日运行完成后产出业务验证报告，针对强依赖业务未阻断、弱依赖业务处理异常等问题推动修改。

33. 案例三越权治理

34. 越权治理-背景越权访问是WEB应用程序中一种常见的漏洞，由于其存在范围广、危害大，被OWASP列为WEB应用十大安全隐患的第二名。对于商户、用户规模大，交易频繁的线上业务来说更是存在较大的安全及合规风险。水平越权垂直越权

35. 越权治理-模式挖掘典型的有越权处理的接口在收到请求前会经历以下三个阶段： 1. 身份认证：身份认证目的是让系统明确当前登录的用户是谁，是后续进行鉴权的基础条件 2. 系统角色判断：基于当前登录的用户，根据身份权限，判断是否可以继续访问 3. 数据权限验证：需要判断当前数据是否是该用户所属，即数据归属判断系统未做角色权限判断时，就容易发生垂直越权问题；系统未做数据归属判断时，就容易发生水平越权问题。

36. 越权治理-检查策略对采集到的业务流量，我们可以进行如下操作来验证接口是否有权限控制。 1. 第一次回放，结合识别到的鉴权方式修改Mock信息，构造无权限账户信息回放，其余依赖数据不变 2. 第二次回放，结合识别到的鉴权方式修改Mock信息，构造有权限账户信息回放，其余依赖数据不变 3. 返回值对比：比对两次回放接口的返回值，验证接口有鉴权能力 4. 调用链路对比：对比两次回放以及原始流量调用的链路，应对那些仅靠返回值不足以验证权限的场景

37. 越权治理-应用场景目前越权检查经过优化适配业务，已经可以自动化、常态化的对新增流量进行检测并将结果同步至自动化建设平台进行日常运营，包含问题确认、加白、一键创建工单等。

38. 建设收益以上治理能力已对部门核心服务默认开启，低成本、自动化的实现了相关问题的常态治理及运营，并被接入到公司内多条业务线。覆盖服务 500+ 覆盖接口 20000+ 覆盖下游依赖 8000+ 发现问题 1000+

39. 未来展望建设通用的基础设施，迭代流量分析和模式挖掘的底层能力，构建更丰富的可靠性治理场景。

40. Q&A

41. 招聘：测试开发岗位邮箱： sunyuxin03@meituan.com 更多技术干货欢迎关注“美团技术团队”