先说一下，什么是高可用？高可用是分布式系统架构设计中必须考虑的因素之一。它通常是指，通过设计减少系统不能提供服务的时间。如果系统能一直提供服务，我们就说该系统的可用性是100%。
高可用测试属于非功能测试，是在功能测试完成之后做的测试。本质来看，高可用测试是测架构。在测试前期，需要充分调研被测系统的架构设计，包括系统的内部组件包括哪些，以及外部的依赖有哪些等等。
做系统高可用需要围绕两个维度：
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，而考虑到服务是多节点的方式进行部署，会出现并发执行的情况，所以采用的数据库分布式锁的方式。数据库表中存放 最新获取锁的节点IP、最新获取锁的时间等字段。当有节点获取锁时，需要先比对数据库表中的字段信息。通过校验则获取分布式锁成功，不通过校验则获取分布式锁失败。而在做高可用测试的过程中，正是因为修改系统时间导致获取分布式锁失败，且系统时间恢复后获取分布式锁仍然失败。具体原因不再赘述，总之，时钟不同步是我们需要考虑的一个重要方向。
（注：一般可以通过ATP工具来实现集群主机间时间同步）
7. 网络故障等：即模拟各个微服务之间网络故障（比如丢包率50%时系统的表现情况、网络延迟2s时系统的表现情况）；
测试工具混沌工程chaosblade：使用该工具来模拟故障，这款工具可以模拟CPU满、磁盘满、内存满等故障；
jmeter：在高可用测试过程中，通常会测试故障发生到故障恢复后是否会对系统的TPS产生影响，因此我们会带着压力跑，也就是模拟业务请求对中间件发起调用，来检测整个过程中对业务的影响。
复盘- 高可用测试过程中应避免其他系统的干扰，测试开始后必须保证只有1个故障在模拟，避免故障重合，即A系统依赖B系统，A系统在执行高可用案例时，B系统同时也在进行，这种情况下，如果产生错误，较难复盘；
- 时间的统计精确到秒级，便于衡量系统处理能力（部分场景需要统计服务故障恢复的时间长短）；
- 排期中需要预留发现问题解决问题的时间。对于组件较多较为复杂的系统，一旦出现问题，复现的成本较高，需要留出充足的时间给相应的开发和测试人员；
- 发现问题后及时处理，避免再做过多的改动，减少盘查问题的成本；
| 测试项目 | 测试目的 | 测试步骤 | 预期结果 | 实际结果 |
| 内部组件故障 | A-console宕机1台（A-console部署4台，负载均衡策略为轮询，宕机1台不影响对外提供服务） | 1. 停止1台console节点服务，观察控制台访问情况； 2. 恢复该console节点服务，观察控制台访问情况 | 1. console控制台可正常访问； 2. conosle控制台可正常访问； | |
| A-console全部宕机 | ||||
| A-server宕机1台 | ||||
| A-server全部宕机 |
下文：高可用测试（二）
