本文由作者陈诚授权网易易盾发布
在业务快速发展的今天，系统的稳定性成为重中之重，没有系统的稳定性，我们的业务将无法持续进行，无法快速发展。容灾测试和压力测试作为保障稳定性的手段之一，与功能测试等其他测试手段一起，构筑了我们的基础测试防线，是我们质量保障体系的重要组成部分。
容灾测试针对不同的部署架构、不同的容灾要求有不同的测试重点。异地部署且异地容灾对涉及应用的架构设计和业务链路设计有极高的要求，其中的网络链路更是重要，因此对我们的测试也提出了更高的要求。在异地部署异地容灾的情况下，一般主要测试业务的异地高可用。高可用是指在某地所有机房突然不可用的情况下，能将请求处理失败的影响降至多少影响面，能在多长时间内恢复业务，并且保证业务处理的幂等性和一致性。业务处理的幂等性和一致性包含三个方面，一个是原来处理过的业务不再重复处理，二是原来正在处理的业务能继续处理，第三是新请求能在新机房正确处理。异地部署的其他方案比如两地三中心，其测试核心内容大致与此相同，针对其架构不同会增加一些其他测试点。
针对本地部署集群，如果是双机房，一般要求互为灾备，这种情况下的容灾测试是验证在其中一个机房不可用的情况下流量能否迅速切到另外一个机房，不影响可用性。而单机房的容灾测试一般就是单台机器出问题时应用的一种异常处理，检验在这种异常情况下业务的表现和异常对业务的影响，就是故障演练，一般是针对CPU、网络、进程、磁盘等的异常情况处理，例如CPU满载、网络抖动或延迟对应用处理的影响，新的请求是否能成功、正在处理的请求是否能保证一致性等。容灾测试对于我们设计与分析应用的异常处理提供了重要参考。
压力测试的测试方案也是类似的，针对不同的部署架构进行全链路、单个机房或整个集群的压测有不同的测试重点。一般是先进行过全链路的压测，解决上下游应用的性能卡点后再进行集群压测，对整个集群的各项性能指标进行摸高。在线下环境进行的压测一般是部署同类型的物理机器，等比例缩小机器数量进行压测，梯度加压，在监控总流量的同时监测链路上所有应用的指标，例如CPU利用率、磁盘读写速度、数据库链接池等，一旦某个应用出现失败率上升或某项指标异常则停止加压，排查性能问题。一般的应用性能问题可以通过异步化、加缓存等方式解决。在解决了性能问题之后再次进行压测，直到各项指标达标。
故障演练和压力测试-以Nydus为例
在中间件测试中，我们对Nydus使用了磐石平台进行容灾测试和NPT进行压力测试。Nydus采用同城双机房部署方案（如下图，仅画出关键应用）。我们在机房1上做功能测试，在机房2上做故障演练，由于Nydus是基于nameserver分发broker地址的，所以这2个机房的消息发送与消费完全隔离。
磐石平台平台通过chaosBlade工具支持CPU、网络、进程、磁盘和docker的故障注入。在使用的时候需要先导入环境，指定应用部署的集群或机器，然后在机器上安装chaosBlade；之后创建演练任务，根据演练的不同故障设置对应的参数，例如CPU满载需要在目标策略中指定满载CPU的机器，网络延迟或丢包除了指定机器外还需要指定服务的网络端口号。设置完参数之后就可以执行任务进行故障注入了。
在配置好故障注入任务之后，原本计划写代码在本机上启线程发起业务请求，但是考虑到后面还需要NPT做压测，根据Nydus的部署方式，我们决定直接使用NPT发起业务请求，然后进行故障注入的方式来进行容灾测试。使用NPT进行压测首先需要创建接口，正好可以使用功能测试时候我们编写的测试接口。因为没有特定的业务场景，所以直接使用快速任务的方式新建压测任务，配置任务名称和其他压测参数之后就可以进行压力测试了。
由于在2个平台上是做不同的测试，所以关注指标也不一样。在磐石平台上进行容灾演练主要关注机器指标信息，在哨兵系统上面观察各项指标较为方便。
NPT平台已经集成了各项压测指标的展示，所以在压测过程中我们能实时看到各项指标的情况。
注意点：
1.在使用磐石平台进行容灾测试时，如果chaosBlade安装不成功可以找PE手动安装，手动安装成功之后，再在平台上进行安装会提示安装成功，否则手动安装不成功
2.在使用磐石平台执行故障注入任务时，如果设置为手动模式，在任务执行时是不会自动清理的，需要手动操作，在一台机器上如果上一个故障注入任务没清理会导致下一个故障任务无法执行。
3.在使用NPT进行压测时需要判断压力机是否能够压到对应的请求数，以及被压机器能否处理对应请求数的请求，可以通过梯度的曲线模式进行摸底，压不到对应请求数是无法进行应用摸高的。
Nydus测试结果简析-以故障演练为例
在测试结束之后，我们需要根据各项指标进行结果分析，例如业务需要实时写磁盘的，在磁盘写满的情况下，会导致应用数据写不进去，可能会丢数据，此时磁盘IO会升高；需要网络请求的业务，在请求处理端网络延迟的情况下，发起请求机器的TPS会降低。这些情况不一而足。
Nydus的测试过程中由于一些限制，我们仅做了Nydus的单机房场景下的故障演练和压测，测试结果符合预期。测试情况如下：
Nydus网络延迟的测试我们是通过NPT平台发起的请求，网络延迟时间3000ms，超时时间7000s。由于网络延迟不涉及到其他硬件方面的指标观测，所以我们直接采用了NPT平台的结果，如下图：
1）Nydus故障演练-网络延迟
采用磐石平台进行故障注入，时间点如下图：
结果分析：由图中可以看到，在差不多10点48分39秒的时候TPS和响应字节数都开始下降，这也是我们在磐石平台开始注入网络延迟故障的时间，此时机器已经几乎无法处理请求了，没有请求自然也没有了响应，所以2个指标都是下降的；在差不多10点49分43秒时TPS和响应字节数开始上升，和故障回收的时间能对应上，故障注入结束之后TPS和响应字节数马山开始提升到正常水平，恢复速度很快。从响应码上也可看出中间请求出现错误。由以上表现可以看出Nydus对网络依赖极高，网络的好坏直接决定了业务的稳定性，网络恢复之后业务也能快速恢复。网络丢包和网络延迟测试表现相同，不再单独分析。
2）Nydus故障演练-CPU满载
故障注入时间点：
此场景我们同样使用NPT平台发起请求和监测结果，如下图：
结果分析：观察故障注入时间点和NPT的业务监测结果，可以看出CPU满载对Nydus接收消息几乎无影响，CPU满载了也能正常的接收消息，可能处理时间稍慢，但是几乎没有失败。我们当时也登录到机器上观察CPU利用率，8核的机器利用率大概在700%多，说明故障注入实际上也可能没真正注满，留有一点缺口，可能刚好是这点缺口让Nydus能够正常处理业务，说明Nydus对CPU依赖性不高。
3）Nydus故障演练-磁盘写满载
磐石平台故障注入时间点：
NPT平台请求发送及结果曲线：
结果分析：在测试磁盘写满载时，我们发送的是普通消息，Nydus是非读写一致的部署。对比故障注入时间点和NPT平台的监控结果，可以发现磁盘写操作对Nydus接收消息没有影响，消息发送100%成功，Nydus接收消息后异步写磁盘，对发送影响较小，也从另外一个方面说明此时如果发生断电或其他原因导致的宕机会导致消息丢失。
4）Nydus故障演练-磁盘读满载
磐石平台故障注入时间点：
NPT平台请求发送及结果曲线：
小结：从上图可以看出，在没有消息堆积的情况下，磁盘读满对消息接收没有影响，接收消息之后直接在内存中处理，也不会从磁盘中读取其他内容，所以此时磁盘读对Nydus接收消息没有影响。但是消息大量堆积之后再消费时Nydus会读取磁盘，磁盘读满会影响消息拉取与发送的速度，发送可能会失败。
结果汇总分析与建议
从以上测试结果中可以看出，在当前的测试场景中，Nydus消息接收功能对网络依赖较大，对CPU有依赖，对硬盘读写无依赖，根据这些结论和上述结果图我们可以给Nydus的消息接收功能绘制如下硬件依赖图：
被测试的Nydus及其部署架构在网络故障和宕机故障时会导致业务不可用以及数据丢失，对业务影响较大，建议故障保障部分重点关注Nydus的网络和宕机。
反思
以上测试数据和分析结果是针对固定业务和固定部署架构获得的，使用其他业务或部署架构获得得数据可能会不相同。
经过这次使用磐石和NPT平台之后发现功能很强大，同时也期待后续有更强大的数据分析功能。
相关阅读：