字节跳动混沌工程实践之场景化主动实验

文章讲述了字节跳动如何通过场景化主动实验平台验证服务调用链的强弱依赖关系,以提升服务的高可用性和稳定性。文章强调了混沌工程中的自动化和通用性原则,以及在服务标准和技术规范方面的考虑,展示了如何通过实验来优化服务依赖关系并持续保证服务的弹性和可靠性。
摘要由CSDN通过智能技术生成

在字节跳动,主动实验落地的第一个场景是验证服务调用链的强弱依赖关系。所谓强弱依赖关系,就是当访问的下游服务异常(服务宕机、响应超时、接口返回失败等)时,调用方的稳定性和可用性是否会受到影响。例如,查询缓存 miss 或失败后可以继续回源访问数据库,缓存的问题并不会影响服务可用性,这个缓存就是个弱依赖。

为什么要选择这个场景呢?公司的很多线上运营事故都是因为不合理的依赖关系导致的。字节跳动有很多高 QPS 的海量服务系统,为了保证用户体验,对高可用高稳定性的要求很高,会通过各种缓存、服务兜底、数据兜底等容灾策略来减少强依赖服务的数量。另外,在字节跳动的服务治理体系中,会根据服务间的强弱依赖调用关系为某些故障场景预设自动容灾降级的策略。比如,当服务治理系统检测到系统负载过高时,能够自动对弱依赖的下游执行降级,通过 FailFast 来缓解系统的负载。因此,业务负责人通常都会比较关注服务的强弱依赖关系。

服务依赖调用链

自动化

主动设计和执行实验意味着将业务侧的人力成本转嫁给了混沌平台,混沌平台必须要借助通用化、自动化的执行能力来降低人力成本。需要强调的是,这里的通用化和自动化一定是和混沌工程的终极目标一致的,能够承载过渡阶段的职责。

可以从混沌工程的高级原则[2]进行剖析:

  • 服务的稳定状态假设:找出能够描述服务稳定状态的通用指标,可以是 metrics、告警等。执行实验前,这些稳定状态指标应处于稳定状态;执行实验时,如果服务的可用性或稳定性受到影响时,稳定性指标会发生变化,比如 metrics 曲线的剧烈波动、触发告警等;当实验结束后,稳定性指标又会恢复到之前的稳定状态。如果执行实验时,稳定状态假设发生了变化,说明这是个强依赖。

  • 生产环境运行实验:在风险可控的条件下推荐在生产环境运行实验,因为系统的行为会根据环境和流量模式的不同而有所不同,系统用户也不会像你所预期的那样与你的系统进行交互。当然,在生产环境执行混沌工程实验很可能是有损的,为了避免对用户体验产生较大影响,一定要控制好实验的爆炸半径,比如筛选出少量的实验流量,这就要求混沌平台具备实验流量筛选与调度的能力。

  • 多样化现实世界事件:也就是各种故障的模拟能力。因为是场景化实验,所以对多样化的诉求倒不像 FIT 那样强烈。

  • 最小化“爆炸半径”:如果选择在线上环境执行实验,需要具备筛选实验流量的能力,即筛选出满足实验所需的最小流量即可,严格控制“爆炸”的影响范围。

  • 持续自动化运行实验:通过工程化能力将实验目标过滤、实验流量筛选、执行实验、稳定状态检测、生成实验报表、实验结果反馈收集等流程串联成自动化的执行流,减少人力依赖。另外,混沌工程实验从来都不是一锤子买卖,应该通过常态化的运行实验来持续的保证服务的高可用和弹性机制符合预期。

混沌工程高级原则

服务标准与技术规范

一个公司内部通常会有很多条产品线,每个产品又会包含很多微服务,还会依赖到中台服务或基础组件,这些不同模块的开发语言、服务框架、技术栈等可能五花八门。要想实现混沌工程通用化与自动化的能力,就必须制定一些通用的服务标准和技术规范。

混沌工程不仅需要了解业务系统当前的技术栈,还要能够预测未来的技术发展趋势,帮助业务提前规划切实可行的技术规范并协助进行建设。

举个例子,如何定义服务的稳定状态?

在字节跳动,我们以调用方视角定义了一个服务级别的 metrics 指标来描述服务的稳定性状态:

  • 被调方在响应包中添加一个通用的 stability 字段来标识本次请求的处理结果是否成功

  • 调用方从响应包中解析出 stability 字段并上报 metrics。某些异常场景(如被调方无响应)导致调用方无法解析出 stability 字段,会上报一个特殊的不稳定值。

之所以要在响应包中单独定义一个 stability 字段是为了区分开系统错误和业务错误。因为业务错误并不表示服务出现了问题,所以我们更关注系统错误。举个例子,删除好友时被调方返回好友不存在的错误,这个错误并不表示系统的稳定性出现了问题。

这个规范最开始只在字节跳动的少数核心服务中使用,其他服务通常都有自己的稳定性指标,有些服务可能需要多个 metrics 指标一起来描述服务的稳定性。因为混沌工程的通用性要求应该具备一种通用的指标来描述所有服务的稳定性状态,经过评估,我们将 stability metrics 作为了混沌工程的服务通用稳定性描述指标,并计划将其推广到全公司的业务,无论什么服务框架和开发语言都可以低成本的快速实现。

字节跳动的混沌工程概况


字节跳动的混沌工程体系主要包括场景化主动实验平台、FIT 平台和红蓝对抗平台。

  • **场景化主动实验平台:**以平台视角主动对业务发起混沌实验,在验证业务系统的高可用和弹性能力的同时推动服务标准化和技术标准化建设,提升混沌工程价值产出和影响力,为实现混沌工程的终极目标做好铺垫。

  • **FIT 平台:**业务同学自助验证服务容灾机制的正确性,具备各种异常事件和故障模拟能力,提供了灵活的可视化实验编排能力。

  • 红蓝对抗平台**:**以第三方视角,用系统化、随机化的对抗实验方式来验证业务系统的高可用水平、监控和告警的有效性,以及异常情况下人工介入时机、故障定位和故障恢复时间是否达标等。

字节跳动混沌工程整体架构图

字节跳动的场景化主动实验建设方案


场景化主动实验的流程图

1. 实验目标

同时推进混沌工程建设的“熟练度”和“应用度”,以生产环境自动执行混沌工程实验为目标构建场景化主动实验的流程和标准,实验场景选定为验证服务间的强弱依赖调用关系,可自动化运行实验,具备实验爆炸半径控制能力。

通过验证强弱依赖调用关系的正确性反推服务的稳定性指标是否规范,推动稳定性指标的规范落地。

2. 实验对象

优先在字节跳动的核心服务落地,树立模范标杆,然后扩展到更大范围。

3. 稳定性指标&波动自动化检测

  • 稳定指标:

因为 stability metrics 已经被多数核心服务当做通用的稳定性描述指标,所以场景化主动演练将 stability metrics 作为稳定性描述的核心指标,同时辅助判断接口成功 qps、失败 qps、调用下游成功 qps、失败 qps、pct99 等指标。

  • 指标波动检测方案:

自动化执行实验要求混沌平台能够自动检测稳定性指标的变动,因为不同服务的指标曲线是不一样的,同一服务的不同时刻的指标曲线也是不一样的,所以预置曲线波动的阈值上限的效果肯定不会太好。因此,在项目启动阶段我们就直接探索自动化的动态检测 metrics 曲线波动的方案:

  • 一种是 Netflix 介绍的 AB test 方案,对比实验曲线和样本曲线的差异

  • 一种是实时计算曲线的变化趋势

由于方案一要求具备更灵活的流量筛选能力和实验环境隔离能力,当前阶段的建设难度和成本较高,所以我们选择了方案二。

  • 自动化波动检测:

起初我们参考线上报警的检测方案:在执行主动演练时,先通过机器学习为稳定性指标实时训练检测模型,然后用模型实时检测指标曲线的变化。但是,因为主动实验的时间较短(一个实验节点只有 60~120 秒)、metrics 数据点稀疏(一个节点的实验时间只能采集到 2~4 个数据点)、实验流量较低(爆炸半径控制在 5~10 QPS),所以基于机器学习的检测效果并不理想。

于是,我们改成组合多种统计规则的检测算法,根据最近一段时间的历史数据动态生成曲线的合理波动范围阈值,然后在实验过程中实时检测增量数据点的波动范围。如果数据点超出了波动范围阈值,就被判定为不稳定。

经过不断调优,最终把这个场景下的指标检测效果优化到了预期水平。

  • 优化方案:

在实践中,我们发现单个稳定性指标的曲线会偶现非预期的波动噪音,这些噪音会影响曲线检测结果的准确率。

于是,我们增加了一个噪音过滤策略:通过对比有相关性的多条稳定性指标曲线的波动相似度来过滤噪音。举个例子,对下游依赖服务注入故障后,调用下游服务失败的 metrics 曲线会上升,如果稳定性指标曲线也上升,而且这两个曲线的变化趋势也相似时,才会认为曲线变化是受实验的影响。这个策略能够比较有效的过滤掉偶现的曲线波动噪音。

具备了稳定状态的检测能力,在场景化主动实验时就可以根据稳定状态的检测结果自动推断下游依赖服务是强依赖还是弱依赖。

4. 最小化爆炸半径控制

为了保证实验的通用性和降低构造实验流量的成本,我们选定在生产环境执行实验,因此最小化爆炸半径控制能力就非常重要了。

字节跳动的生产环境有个用于服务灰度上线的金丝雀集群,在服务上线时会先升级这个集群来验证服务的正确性。这个集群的实例比较少,且支持通过修改集群权重来调整进入集群流量。

经过验证,实验流量在 5~10QPS 时就可以保证稳定性 metrics 指标检测的准确率。所以,执行实验时,先从服务的金丝雀集群中随机选择一个实例作为实验目标,计算实例流量与预期流量的偏差重新生成权重值,然后通过修改集群权重来调整实例流量。

5. 验证方式

字节跳动的微服务管理平台通过聚合服务的 Trace 日志生成了服务间的调用拓扑图,通过 OpenAPI 可以查询到某个服务的所有一级下游依赖服务列表。

然后,逐个对下游依赖服务注入一段时间的宕机故障,同时检测服务的稳定性指标是否出现异常波动来推断下游依赖服务是强依赖还是弱依赖。

需要注意的是,因为是逐个对下游依赖服务执行实验,为了避免前一个实验对下一个实验产生干扰,我们在两次实验间增加了一个间隔时间,具体的间隔时长依赖所使用的指标检测算法。

6. 实验报告

实验执行结束,平台会将下游依赖服务的强弱依赖推断结果、执行上下文、稳态指标监控视图和检测结果等汇总成一个实验报告发送给服务负责人。

服务负责人确认实验报告,如果发现实验结果不符合预期,可以通过执行上下文和监控视图等信息来辅助定位问题。同时,可以在实验报告中备注不符合预期原因、问题修复方案和修复进度等,平台会定时跟进修复进度并提醒服务负责人更新结果。

如果实验结果符合预期或问题已完成修复,实验报告会进入结单状态,同时记录服务的强弱依赖推断结果,并输出给服务治理平台,应用于服务在线治理。

7. 实验结果自动保准

业务系统是持续迭代的,下游依赖关系也是动态变化的。如果非预期的引入了强依赖,会给系统增加可用性风险,因此场景化主动实验也需要常态化执行。

已完成的主动实验都可以开启试验结果自动保准,每隔一定时间会自动执行实验验证下游依赖服务的强弱依赖关系,并与历史实验结果进行对比,并将变动的部分通过实验报告发送给服务负责人。

经过服务负责人确认后,新的验证结果会被更新到存储和发送给服务治理平台。

8. 完整的实验流程

场景化主动实验流程图

场景化主动实验的价值


我们的验证范围从核心服务开始、逐渐向外围服务扩张。

核心服务的验证结果基本符合预期,但还是有少数个案存在稳定性指标不规范、容灾逻辑不符合预期的情况。通过实验结果自动保准机制,也多次及时发现因代码变更所导致的容灾逻辑失效情况。

外围服务验证出来的问题就比较多了,稳定性指标严重不规范导致无法评估服务的稳定性、容灾逻辑覆盖率低导致过多的强依赖使得服务可用性风险较高等等。需要持续的推动业务进行优化升级,并给予一些高可用弹性系统的建设思路或参考方案。

场景化主动实验近期工作


最近,我们新上线了在结果保准时自动对弱依赖服务注入随机故障来进一步探索弱依赖的抗风险能力。我们认为弱依赖服务在任何故障场景下都不应该影响服务的可用性。

另外,场景化主动实验还接入了服务的上线流程,在服务灰度上线时就触发实验,让服务负责人能够更及时的发现不符合预期的系统变更,如果有必要可立刻终止或回滚上线变更。

场景化主动实验的未来规划


通过场景化主动实验,我们已具备持续保障字节跳动核心服务的稳定性指标规范性、强弱依赖正确性,以及弱依赖的抗风险能力等等。

接下来,我们会把场景化主动实验扩展到更大服务范围和更多业务场景,让场景化主动实验发挥出更大的价值。

另外,我们也在思考打通服务上下游,从点到线再到面,以更高维度的系统视角来探索启发式的智能混沌实验。

参考文献


  1. Netflix 混沌工程开源项目 - Chaos Monkey:

https://github.com/Netflix/chaosmonkey

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

img

img

img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)

最后

总而言之,Android开发行业变化太快,作为技术人员就要保持终生学习的态度,让学习力成为核心竞争力,所谓“活到老学到老”只有不断的学习,不断的提升自己,才能跟紧行业的步伐,才能不被时代所淘汰。

在这里我分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司20年的面试题,把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,这里以图片的形式给大家展示一部分。

还有高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料 帮助大家学习提升进阶,也节省大家在网上搜索资料的时间来学习,也可以分享给身边好友一起学习。

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门即可获取!

相关的几十套腾讯、头条、阿里、美团等公司20年的面试题,把技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,这里以图片的形式给大家展示一部分。

[外链图片转存中…(img-7xEkrq9k-1712398334145)]

[外链图片转存中…(img-OiehzTpH-1712398334146)]

[外链图片转存中…(img-rnj9RUeM-1712398334146)]

还有高级架构技术进阶脑图、Android开发面试专题资料,高级进阶架构资料 帮助大家学习提升进阶,也节省大家在网上搜索资料的时间来学习,也可以分享给身边好友一起学习。

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》,点击传送门即可获取!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值