周三. 2月 1st, 2023

eBay支付核心账务系统之混沌不摧

作者UU    👁 浏览人数:9 人

12月 28日 2022年

导读

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

作者 UU

此号发布内容皆为转载自其它媒体或企业宣传文章,相关信息仅为传递更多信息之目的,不代表本网观点,亦不代表本网站赞同其观点或证实其内容的真实性。如有侵权请联系删除!13723417500

声明本文由该作者发布,如有侵权请联系删除。内容不代表本平台立场!

发表回复

展会牛
服务平台
跨境人联网
优品出海
选品平台