导读

eBay[1]支付核心账务系统FAS[2]（Financial Accounting System）通过之前的百万TPS实验（详见：eBay支付核心账务系统之直冲云霄），证明了其强大的水平扩展能力。随着eBay业务的全面发展，FAS系统将扩展出更多的集群。为保障eBay支付业务的健康发展，FAS团队着眼于系统的稳定性建设。本文将讲述FAS团队如何利用混沌工程检验并提升FAS系统的健壮性，以达到“混沌”不摧。

1

背景

作为金融级的软件产品，FAS系统的软件质量一直是FAS团队的工作重心。FAS团队构建一整套功能测试和性能测试框架，以保证代码更新的可靠性。然而，现有的测试框架不能覆盖FAS系统在基础架构层面发生故障时的可用性测试。

早在2020年FAS系统上线之初，FAS团队就开始了分布式系统稳定性测试的探索。鉴于当时eBay内部缺乏强大的分布式测试平台，FAS团队引入简易版本的Jepsen[3]测试

。采用每隔5分钟停止一个集群节点等方式，测试FAS系统的可用性。然而，这种测试粒度比较粗，无法覆盖分布式系统环境中更为复杂的异常场景。

2010年，Netflix公司提出混沌猴子[4](Chaos Monkey)来提升系统的稳定性，并发展出混沌工程[5](Chaos Engineering)的概念。随着云原生的兴起，混沌工程理论迅速发展，且被证明是发现系统弱点并验证系统能否处理异常情况的有效手段。混沌工程向目标系统进行随机的故障注入，完美匹配云原生规模庞大、结构复杂且可靠性要求高的特点。

时至2022年，FAS系统绝大部分组件已迁移到基于Kubernetes[6]的Tess平台。Sherlockio团队也在Tess推出混沌工程平台(Chaos Platform)。Chaos Platform基于CNCF[7]孵化的LitmusChaos[8]开发，提供了一系列功能强大的开箱即用通用混沌测试，在应用层、系统层和平台层提供众多业务方无需介入的故障注入场景，并且可以做到基于命名空间进行安全隔离。这就为FAS系统的分布式稳定性测试提供了更多的可能。有了强大的故障注入工具，FAS团队开始了系统稳定性测试的混沌工程之旅。

2

方案设计

混沌工程是一套在系统基础设施上进行实验，主动找出分布式系统缺陷环节的方法学。经过多年发展演化，混沌工程总结出一套最优实践原则[9]。

1. 构建基于系统稳定状态的假设：当稳态的系统有特定异常情况发生时，系统表现出可预期的行为；

2. 模拟真实世界的事件：注入实际生产环境可能发生的异常事件，对系统的稳定性测试更有意义；

3. 在生产环境中运行混沌实验：在线上系统中进行混沌实验，更能暴露真实生产环境的潜在问题；

4. 控制爆炸半径：混沌实验需要控制对系统的破坏程度，以免影响系统的正常运行。

在混沌实验中，FAS团队依据混沌工程理论，采用科学有效的实验方法：提出FAS系统稳态的假设、开展混沌实验，观察系统行为并验证假设。

2.1 环境部署

根据混沌工程最佳实践原则，混沌工程实验推荐在生产环境中进行。在实际对FAS系统进行混沌实验时，考虑到FAS账务系统的特殊性，FAS团队选择搭建一套与生产环境有完全相同配置的系统，并部署版本一致的构件(manifest)，以规避在生产环境进行故障注入的测试风险。实际测试环境的部署如图1所示：

图1 测试环境部署

(点击可查看大图)

测试环境中的各个组件简要描述如下：

1. FAS Traffic Simulator从远端存储(NuObject)中拉取FAS系统产生的历史数据，经过反向工程转换为正常的FAS系统输入；

2. FAS Gateway根据特定的流量路由算法，将请求转发至下游FAS PU集群的领导者(Leader)节点；

3. 在流量正常发送过程中，通过Chaos Platform向FAS系统注入故障；

4. 监控系统(Monitoring System)从FAS系统拉取监控指标(Metrics)并决定是否触发异常告警。

在测试环境中，FAS系统正常处理FAS Traffic Simulator以近似恒定的速率发送的请求，以此构建出系统的稳态。

2.2 混沌实验

FAS系统的核心——PU(Processing Unit)是由一组基于Raft共识算法的有状态服务集群组成(详见：超越‘双十一’|ebay支付核心账务系统架构演进之路)。PU集群的健壮与否将直接影响FAS系统的可用性，因此FAS系统的混沌实验主要围绕PU集群进行。FAS团队通过Chaos Platform对FAS系统的可用性(Availability)、自愈能力(Self healing)以及监控系统(Monitoring & Alert)进行了多轮全方面的测试。

2.2.1 可用性实验

单个PU集群采取三地五中心(2-2-1)的部署方式。只要集群的多数派节点能正常处理请求，整个集群就可以保证高可用，因此单个PU集群最多可以允许2个节点同时出现故障。

为验证节点不可用对FAS系统的影响，FAS团队模拟了多种灾难场景：对集群的两个节点分别同时注入重启、宕机、网络不可达等故障。故障注入期间，FAS系统均能正常处理线上请求，达到高可用。其中，注入故障前的监控如图2所示；对同一个数据中心的1号节点和2号节点分别同时注入pod delete和pod restart故障的监控图如图3、4所示。

图2 故障注入前

(点击可查看大图)

故障注入前，集群的领导者节点是2号节点。整个集群状态正常。领导者节点接收并处理线上请求，并将处理结果同步给集群里的跟随者(Follower)节点。

图3 故障注入中

(点击可查看大图)

故障注入期间，整个集群由新选举产生的领导者节点继续处理线上流量。其中，1号节点和2号节点由于故障注入导致短时间内不可用。

图4 故障注入后

(点击可查看大图)

故障注入完成后，整个集群通过新一轮Raft选举产生新的领导者节点，持续处理线上请求。1号节点和2号节点在故障恢复后自动加入集群，并从领导者节点同步最新日志。这验证了我们之前的假设——PU集群可以容忍2个节点同时宕机。

2.2.2 自愈实验

在可用性实验中，PU集群在少数派节点出现故障期间依然能正常接收线上流量。但FAS团队发现，故障节点恢复后，PU集群TPS短暂下降（如图4所示）。同时，故障节点恢复期间，集群发生多次选主(领导者选举)（如图5所示），造成FAS集群处理性能的下降。

图5 领导者选举

(点击可查看大图)

根据Raft算法，集群节点上线后默认处于跟随者状态。只要该节点选主超时前收到领导者节点的心跳信号，就不会触发集群选主，但频繁选主违背了这一原则。FAS团队经后续实验和分析，发现该问题是由集群节点之间gRPC避退(backoff)参数配置过大造成

。

混沌实验注入期间，领导者节点无法向故障节点发送心跳，触发了gRPC连接的避退功能。实验结束后，故障节点无法在选主超时前收到来自领导者节点的心跳，从而向集群发起新一轮的选主。FAS团队将集群gRPC连接避退参数修改为小于选主超时后，成功解决该问题，进一步提升了PU集群的稳定性。

2.2.3 监控系统实验

分布式系统中，故障的发生往往出乎预料，而完整的监控和报警系统是及时发现线上潜在故障的利器。FAS团队针对PU集群的节点存活与异常的TPS下降等异常均有报警配置。

为验证单个集群节点的报警是否完备，FAS团队对PU集群的单个节点注入网络延迟(network latency)故障以模拟慢速网络的情况。故障注入前的监控如图6所示。

图6 网络延迟故障注入前

(点击可查看大图)

此时，整个集群处于健康状态，各个跟随者节点从领导者节点同步日志(raft log)，各个节点日志的提交索引(commit index)相差在合理范围内。网络延迟故障注入后，集群监控如图7所示。

图7 网络延迟故障注入后

(点击可查看大图)

对3号节点注入网络延迟故障后，整个集群依然可以正常响应线上的流量请求。但网络故障导致3号节点的提交索引落后于集群其他节点，使整个集群处于非健康状态。如果网络延迟持续恶化至其他节点，可能会造成整个集群不可用。FAS团队将跟随者节点与领导者节点之间的提交索引差距纳入报警，以提前规避可能的线上故障。

2.3 多故障注入协同

要更加完备地测试FAS系统的健壮性，就需要考虑不同类型故障同时发生的场景。对于每一种类型故障的注入，eBay Chaos Platform会在目标命名空间里创建新的Pod来执行具体的故障注入工作。然而，Tess平台上Pod的创建是基于事件驱动机制的异步过程，涉及事件侦听、准入控制、资源调度、运行环境准备等一系列复杂步骤。因此，通过eBay Chaos Platform可能无法将多个故障同时注入目标系统。

eBay Chaos Platform在设计之初就考虑到可扩展能力。FAS团队利用其提供的Hook机制，设计和开发了故障注入编排程序(FAS Chaos Orchestrator)，增强了多类型故障注入的控制力度。加入编排服务的故障注入流程如图8所示：

图8 故障注入同步服务

(点击可查看大图)

多故障注入同步过程描述如下：

1）FAS系统管理员通过Rest API向故障注入编排服务(FAS Chaos Orchestrator)注册需同步的故障信息；

2）管理员在故障注入的配置文件中配置FAS Chaos Orchestrator提供的同步API地址以实现回调通知后，通过Chaos Platform注入故障；

3）执行故障注入任务的Pod先后向FAS Chaos Orchestrator发送注入通知；

4）FAS Chaos Orchestrator判断所有故障注入是否均准备完毕；如果是，向所有Pod返回开始注入通知；否则等待直至收到所有预期Pod的回调通知。

2.4 红蓝对抗

为提升FAS团队分析问题和在压力下迅速解决线上故障的能力，培养员工在设计分布式系统时多方面考量的意识，FAS团队举行了多次红蓝对抗。

红蓝对抗中一共有三个角色：蓝方(攻击方)、红方(防守方)和裁判。蓝方利用eBay Chaos Platform和脚本模拟各种故障，在授权范围内对FAS系统的数据和服务进行攻击；红方需要在规定时间内，通过系统监控、日志、流量分析以及命令排查等手段，及时发现系统异常，定位系统故障点，并给出合理的解决方法；裁判在演练期间进行适当引导，并给出胜负结果。

红蓝对抗结束后，参与人员会对整个攻防演练过程进行复盘，沟通攻防过程中发现的系统薄弱环节，并讨论后续优化方案。

FAS团队通过红蓝对抗演练对FAS系统进行全面摸底，全方位检验FAS系统监控、报警、系统恢复、集群稳定等能力。

3

总结

随着云原生的发展和成熟，混沌工程将会越来越多的应用于分布式系统的稳定性测试。借助混沌工程的实验方式来持续探索和发现系统中的脆弱环节，增强系统抵抗各种异常的能力，从而适应和满足多场景下对系统韧性的要求。

混沌工程检验FAS系统稳定性的同时，也增强了FAS团队对FAS系统容灾的信心。本文通过对混沌工程在FAS系统实践的介绍，希望对稳定性要求高的分布式系统的测试，提供一些参考。

4

展望

目前FAS混沌工程的应用需要较多的人力介入，包括混沌实验参数设置，以及故障注入终端命令的手工执行。未来FAS系统将支持混沌测试的自动化，并和持续集成与发布(CICD)系统融合。当有代码变更提交时，自动部署一套新的FAS系统并执行一系列业务功能测试和混沌测试，来保证代码更改的安全性。融合自动化混沌测试的FAS系统将具有更高维度上的系统稳定性。

参考文献/资料

[1] https://www.ebay.com/

[2] eBay支付核心账务系统架构演进之路: https://mp.weixin.qq.com/s/O5_Rde5uUXvmBS2B7w2hOQ

[3] https://jepsen.io/

[4] https://netflix.github.io/chaosmonkey/

[5]https://en.wikipedia.org/wiki/Chaos_engineering

[6] https://kubernetes.io/

[7] https://www.cncf.io/

[8] https://litmuschaos.io/

[9] https://principlesofchaos.org/

END