高可用测试（一）

前言

先说一下，什么是高可用？高可用是分布式系统架构设计中必须考虑的因素之一。它通常是指，通过设计减少系统不能提供服务的时间。如果系统能一直提供服务，我们就说该系统的可用性是100%。

高可用测试属于非功能测试，是在功能测试完成之后做的测试。本质来看，高可用测试是测架构。在测试前期，需要充分调研被测系统的架构设计，包括系统的内部组件包括哪些，以及外部的依赖有哪些等等。

做系统高可用需要围绕两个维度：

1. 大概率不出问题；

2. 出了问题之后缩减它的故障域范围；

因此，在高可用集群测试过程中需要关注两点：

1. 模拟系统中某个部分或者节点发生故障时，不影响系统整体向外部提供服务；
2. 故障恢复后，系统的处理情况（即故障恢复后，能否恢复到之前的状态）

案例设计

通常，可以从以下几点考虑案例的设计：

1. 内部组件故障（单节点故障 / 集群故障）：内部组件故障指的是系统自身某个组件故障（宕机）。微服务架构的系统，通常包含多个组件，这些组件间相互联系。如系统A的内部组件包括组件A-console和组件A-server，A-console为A的控制台，A-server为A处理服务的组件，这些组件之间通过一定的网络通信协议进行通讯；

2. 外部依赖故障：大的复杂的系统通常需要依赖外部系统来扩展自己的功能。而这些外部系统的开发一般都不是自己。外部依赖故障指的是系统自身依赖的外部系统故障，如系统A依赖redis，那么就要考虑redis故障（宕机）对系统A的影响；

3. CPU满：高可用部署的集群中，节点的CPU满也是我们高可用可以考虑的范围。即单个节点或者所有节点CPU被打满后，系统的处理情况（性能测试中做负载测试的时候，我们通常会模拟CPU99时，系统的表现情况。高可用测试和性能测试中CPU满的情况，关注点稍有不同）；

4. 磁盘满：即服务部署的节点的磁盘空间被打满后，对服务的影响；

5. 内存满：即服务部署的节点的内存被打满后，对服务的影响；

6. 时钟不同步：时钟不同步指的是服务部署的节点的系统时间被更改，导致服务间系统时间不一致。通常我们的程序中会有一些获取系统时间的代码段。当系统时间被更改后，需要考虑对我们的服务会有哪些影响。以本次高可用测试中某个系统的测试为例：

    该系统中涉及 数据库分布式锁实现分布式系统定时任务单个执行。简单理解就是服务A需要一个定时任务定时同步数据到服务B，而考虑到服务是多节点的方式进行部署，会出现并发执行的情况，所以利用MySQL来解决分布式锁的问题。

     MySQL表中存放 最新获取锁的节点IP、最新获取锁的时间等字段。当有节点获取锁时，需要先比对数据库表中的字段信息。通过校验则获取分布式锁成功，不通过校验则获取分布式锁失败。而在做高可用测试的过程中，正是因为修改系统时间导致获取分布式锁失败，且系统时间恢复后获取分布式锁仍然失败。具体原因不再赘述，总之，时钟不同步是我们需要考虑的一个重要方向。

 （注：一般可以通过ATP工具来实现集群主机间时间同步）

7. 网络故障等：即模拟各个微服务之间网络故障（比如丢包率50%时系统的表现情况、网络延迟2s时系统的表现情况）；

测试工具

混沌工程chaosblade：使用该工具来模拟故障，这款工具可以模拟CPU满、磁盘满、内存满等故障；

jmeter：在高可用测试过程中，通常会测试故障发生到故障恢复后是否会对系统的TPS产生影响，因此我们会带着压力跑，也就是模拟业务请求对中间件发起调用，来检测整个过程中对业务的影响。

复盘

1. 高可用测试过程中应避免其他系统的干扰，测试开始后必须保证只有1个故障在模拟，避免故障重合，即A系统依赖B系统，A系统在执行高可用案例时，B系统同时也在进行，这种情况下，如果产生错误，较难复盘；
2. 时间的统计精确到秒级，便于衡量系统处理能力（部分场景需要统计服务故障恢复的时间长短）；
3. 排期中需要预留发现问题解决问题的时间。对于组件较多较为复杂的系统，一旦出现问题，复现的成本较高，需要留出充足的时间给相应的开发和测试人员；
4. 发现问题后及时处理，避免再做过多的改动，减少盘查问题的成本；

测试用例（未完待续）

测试项目	测试目的	测试步骤	预期结果	实际结果
内部组件故障	A-console宕机1台（A-console部署4台，负载均衡策略为轮询，宕机1台不影响对外提供服务）	1. 停止1台console节点服务，观察控制台访问情况； 2. 恢复该console节点服务，观察控制台访问情况	1. console控制台可正常访问； 2. conosle控制台可正常访问；	同左
	A-console全部宕机	1. 停止所有console节点服务，观察控制台访问情况； 2. 恢复一台console节点服务，观察控制台访问情况； 3.恢复其余console节点服务，观察控制台访问情况；	1.控制台访问失败； 2.控制台恢复正常； 3.控制台恢复正常	同左
	A-server宕机1台	1.停止1台server所在节点； 2.恢复该server节点服务	1.对用户调用无影响（当时正在该节点处理的请求失败）； 2.对用户调用无影响；	同左
	A-server全部宕机	1.模拟所有server节点宕机； 2.恢复1台server节点服务； 3.恢复其余server节点服务	1.用户调用失败 2.用户调用恢复正常 3.对用户调用无影响	同左
	...
外部依赖故障	依赖的mysql宕机	模拟mysql等数据库宕机	观察系统中的缓存机制是否有效，是否影响业务	同左
	依赖的redis宕机			同左
	依赖的其他中间件宕机			同左
节点所在机器的磁盘/CPU/内存被打满	server所在的机器CPU被打满	模拟CPU打满	观察是否会出现超时或者上层的负载均衡是否会剔除该节点	同左
	server所在的机器磁盘被打满	模拟磁盘打满	观察是否会影响日志输出/其他磁盘I/O相关的任务受影响	同左
	server所在的机器内存被打满	模拟内存打满	观察应用程序处理情况	同左
节点间网络故障（网络延时、丢包等）

下文：高可用测试（二）