前言
先说一下，什么是高可用？高可用是分布式系统架构设计中必须考虑的因素之一。它通常是指，通过设计减少系统不能提供服务的时间。如果系统能一直提供服务，我们就说该系统的可用性是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、最新获取锁的时间等字段。当有节点获取锁时，需要先比对数据库表中的字段信息。通过校验则获取分布式锁成功，不通过校验则获取分布式锁失败。而在做高可用测试的过程中，正是因为修改系统时间导致获取分布式锁失败，且系统时间恢复后获取分布式锁仍然失败。具体原因不再赘述，总之，时钟不同步是我们需要考虑的一个重要方向。
7. 网络故障等：即模拟各个微服务之间网络故障（比如丢包率50%时系统的表现情况、网络延迟2s时系统的表现情况）；
测试工具
混沌工程chaosblade：使用该工具来模拟故障，这款工具可以模拟CPU满、磁盘满等故障；
jmeter：在高可用测试过程中，通常会测试故障发生到故障恢复后是否会对系统的TPS产生影响，因此我们会带着压力跑。
复盘
高可用测试过程中避免其他系统的干扰，测试开始后必须保证只有1个故障在模拟，避免故障重合，即A系统依赖B系统，A系统在执行高可用案例时，B系统同时也在进行，这种情况下，如果产生错误，较难复盘；
时间的统计精确到秒级，便于衡量系统处理能力（部分场景需要统计服务故障恢复的时间长短）；
排期中需要预留发现问题解决问题的时间。对于组件较多较为复杂的系统，一旦出现问题，复现的成本较高，需要留出充足的时间给相应的开发和测试人员；
发现问题后及时处理，避免再做过多的改动，减少盘查问题的成本；
测试用例（未完待续）
