中通的分布式微服体量日益增大,平台框架组决定构筑成双注册中心架构来保障整个生态系统的稳定性。即在原来Zookeeper的基础上增加一个注册中心。项目组将在Nacos1.3.2和Sofa Registry5.4.6(以下简称Nacos和Sofa)之间选择一个更稳定更适合的注册中心来与Zookeeper搭配,组合成双注册中心。
随着分布式的广泛应用,混沌测试的概念也随之兴起。为了比较这两款注册中心的稳定性和高可用性,混沌测试必然是首选。
混沌测试就是以试验的方法尽早揭露系统弱点的测试方法,它更类似于探索性测试,本身没有明确的输入和输出,主要是观察系统的实际反应来进行主观判断。
制定测试方案前,我们需要确立一个可以作为基准的稳定状态,而稳态的确定是对测试需求的进一步细化。结合我们自身的业务,我们定义的稳定状态就是在混沌情况下服务能够正常的注册与订阅,注册中心的各系统节点通信无异常。
Sofa 架构图:
Client
提供应用接入服务注册中心的基本 API 能力,应用系统通过依赖客户端 JAR 包,通过编程方式调用服务注册中心的服务订阅和服务发布能力。
Session
会话服务器,负责接收 Client 的服务发布和服务订阅请求,并作为一个中间层将写操作转发 Data层。Session这一层可随业务机器数的规模的增长而扩容。
Data
数据服务器,负责存储具体的服务数据,数据按 dataInfoId 进行一致性 Hash 分片存储,支持多副本备份,保证数据高可用。这一层可随服务数据量的规模的增长而扩容。
Meta
元数据服务器,负责维护集群 Session 和 Data的一致列表,作为 Sofa集群内部的地址发现服务,在 Session或 Data节点变更时可以通知到整个集群。
Nacos 架构图:
Nginx:由Nginx将请求负载均衡路由到集群中的每台Nacos Server节点。
Nacos Server:提供注册服务、服务治理等功能。
Nacos Client:包括Provider和Consumer,注册服务、获取服务列表、维持心跳信息等功能。
(3)所有的客户端与Registry集群的交互都是通过Session Server进行的,并且客户端信息存储在Session节点内存中。
通过以上的需求分析及架构梳理,混沌场景优先从扩容,缩容,节点异常,内存占用,内存溢出,网络异常,大规模注册,DDOS攻击,CPU满载这几个方面着手。
详情如下:
(1)扩容
a.场景:SessionServer和Nacos节点进行扩容,需要验证在扩容期间对服务的影响。
b.执行:在节点不断新增的过程中,不断增加Client的注册与订阅事件
c.验证点:
i.共通点:
1.新的Client能否注册到新的节点上。
2.客户端订阅是否正常。
ii.Sofa:
1.Sofa中新的节点和Data Cluster交互是否正常。
2.MetaCluster中的Seesion列表是否更新。
iii.Nacos:
1.Nacos Server节点之间数据是否同步。
d.测试结果:
i.新增的Client会在新的节点上注册。
ii.已存在服务订阅无异常。
iii.NacosServer中的节点信息同步成功.
iv.Sofa中新的Session节点与DataCluster交互正常。
(2)缩容
a.场景:节点缩容,与扩容同理。
b.执行:在Session Cluster列表中移除节点,同时不断新增Client的注册与订阅事件。
c.验证点:
i.共通点:
1.存在于原来节点的Client是否成功转移至其他可用节点。
2.是否影响正常的订阅。
ii.Sofa:
1.MetaCluster中的Seesion列表是否更新。
d.测试结果:
i.当节点被停机后,该节点上的Client会重新failover到其他可用节点,不影响后期订阅。
ii.Sofa中MetaCluster中的Seesion列表更新至最新。
(3)节点异常
a.场景:模拟部分节点故障,触发Client failover。
b.执行:可以直接kill -9 杀掉Session进程;或者使用命令断开整个节点的网络,./blade create network loss --percent 100 --interface eth0 --timeout 100。
c.验证点:
i.和缩容的场景验证点相同。
d.测试结果:
i.和缩容的场景测试结果相同。
(4)内存占用
a.场景:SessionServer和NacosServer都对在内存中存储数据,验证占满内存后对已注册和即将注册的Client的影响。
b.执行:使用命令./blade c mem load --mode ram --mem-percent 100 --timeout 200,是机器内存占用达到100%。
c.验证点:
i.Sofa与Nacos:
1.该节点上已经注册的client是否正常。
2.新的Client是否会继续在该节点进行注册。
d.测试结果:
i.新的Client不会在该节点上进行注册。
ii.原先的Client调用正常。
(5)内存溢出
a.场景:针对NacosServer的Leader节点和Sofa的Session节点模拟内存溢出。
b.执行:使用命令./blade c jvm oom --area HEAP --wild-mode true --process nacos-server。
c.验证点:
i.共通点:
1.该节点上已经注册的client是否正常。
2.新的Client是否会继续在该节点进行注册。
ii.Nacos:
1.是否触发新的选举。
d.测试结果:
i.Sofa中没有新的Client进行注册,原服务不受影响。
ii.Nacos中Leader处于OOM状态后,集群无法选举出新的Leader,导致整个集群状态异常。该bug可以在链接中查看详情https://github.com/alibaba/nacos/issues/5385。
(6)网络异常
a.场景:Cluster整个集群网络与外界断开,继而恢复。
b.执行:使用命令./blade create network loss --percent 100 --interface eth0 --timeout 100,使得机器网口eth0对外网络丢失率100%,继而取消实验来恢复网络。
c.验证点:
i.Sofa与Nacos:
1.已经注册和订阅成功的Client的调用是否受影响。
2.网络恢复后Client能否重连,并且通知正常的变更。
3.是否还具备注册与订阅功能。
d.测试结果:
i.网络恢复后,Server正常提供服务。
(7)大规模注册
a.场景: Cluster中的节点大部分处于异常状态时,会发生Client的failover,仅存的节点就会面临大量的注册事件。
b.执行:利用脚本实现随机关停大部分节点。
c.验证点:
i.Sofa与Nacos:
1.新的Client的注册是否正常。
2.原先的Client是否受影响。
3.Client的变更能否正常触发通知。
4.服务调用是否不受影响。
d.测试结果:
i.服务调用不受影响,服务变更能正常收到通知。新的client能在其他可用节点进行注册。
(8)DDOS攻击:
a.场景:针对场景6,我们还可以想到使用DDOS攻击的方式,即在多台肉机上模拟大规模服务注册,验证集群中节点的可靠性。
b.执行:每台肉机上分别使用脚本进行大规模注册,可用Jmeter实现分布式的执行。
c.验证点:
i.Sofa与Nacos:
1.新的Client的注册是否正常。
2.原先的Client是否受影响。
d.测试结果:
i.所有节点正常提供服务。
(9)CPU满载:
a.场景:Server存在一定量的计算工作,所以CPU满载时需要验证其功能性是否正常。
b.执行:使用命令./blade create cpu load --cpu-percent 100 –timeout 100,使服务器CPU利用率到达100%。
c.验证点:
i.Sofa与Nacos:
1.新的Client的注册是否正常。
2.原先的Client是否受影响。
3.Provider信息变更能否正常进行。
d.测试结果:
i.新的Client仍能正常注册,原先服务订阅不受影响。
以上只针对Sofa的session和Nacos的server部分进行了用例场景设计,我们暂且举例这些,其实还有很多其他方面的实验,比如Session Cluster节点大规模重启等其他异常场景,这里暂不做赘述。
对于Sofa而言,其架构中还存在Meta和Data,MetaCluster在SofaRegistry架构中充当类似于哨兵的角色,它的稳定性影响着SessionCluster和DataCluster扩容、缩容、failover等。对于Nacos来说,Mysql的稳定性也会影响整个Nacos集群,这些部分我们同样要针对其特征匹配专门的混沌测试用例,方法都是类似的,本文就不再展开来讲了。
Nacos在第五个场景中没有产生预期结果。当Nacos的Leader节点被模拟OOM后,整个集群无法选举出新的Leader,导致整个集群异常;而在Sofa执行混沌测试过程中,没有出现过明显的异常。项目组最终选择Sofa作为第二注册中心。
在保障系统的稳定性和可靠性上,混沌测试的实践远不止文章所述,还可以做更多,例如:通过打造混沌测试自动化平台来使混沌测试能在整个生态系统中常态化执行;双注册中心架构的稳定性和可靠性在混沌下的表现是否如预期等。期待下一次的分享。
欢迎各位技术大佬向本公众号积极投稿,提升经验分享、信息互通的技术交流氛围,共同解决技术难题、共同进步!(投稿咨询请联系科技与信息中心助理室 徐蕊)