分布式系统测试的几个关注点

肖恩

现在系统都向云平台、分布式、微服务的技术方向发展，越来越多的系统开始在这些方面付诸实施或者在原有架构上进行迁移。那么，对于分布式的系统，不同于集中架构的系统，除了业务功能层面，测试时候还需要关注哪些点呢？经过这几年经验和教训的积累，总结以下几点，供测友参考。

一、数据库层面：唯一键设置。

分布式系统有不同的阶段，对于部分分布式系统来说，可能是应用层面实现了分布式，而数据库层面还没有完全的分库分表。比如原系统是集中式架构，在实现分布式迁移中鉴于数据库迁移的复杂性，暂时只实现了应用层的分布式架构和横向扩展；或者应用和数据库都是分布式架构，但是为了后续业务处理和查询方面，还是有一些集中存放的数据表。对于这种情况，要特别关注数据表唯一键的设置是否有防重考虑。往往这些唯一键中有一些时间戳、自增序列、节点标识等，那么测试时候需要关注这些要素，是否会存在多节点重复的情况。比如自增序列，是全局自增，还是单节点自增；自增到上限后是否有归零处理，归零处理后又会引发什么状况。唯一键设置如果没有考虑分布式多节点的情况，随着交易量、节点数、并发数的增长，很可能引发多个应用节点处理的交易，在记库的时候冲突的情况。

二、任务调度，负载均衡策略。

分布式系统必然要面对的一个情况就是任务调度和负载均衡。任务调度的时候一般会选取一个或者多个交易要素，然后根据这些交易要素或者其哈希值进行任务调度。测试时候需要关注，这些作为调度的要素，是否具备散列特征。比如如果单纯选取商户号或者机构号进行交易处理的调度，那么因为每个商户的交易量有多有少，每个节点处理的任务数不均匀，那就会导致拖尾现象，系统整体的处理性能不高。另外，测试时候需要关注，调度规则是否存在“死角”，就是一些特殊的交易，如果规则选取和定义不严谨，就会导致所有调度规则都走不到的情况，那么这种情况，就要求我们在设计调度规则的时候，考虑默认处理节点，及“兜底”处理。

三、关联交易处理。

在一个业务系统里面，一般都有相互有关联的一些交易，这些交易可能要求在同一个节点上进行处理。如果不在同一个节点，有可能会引起关联交易信息找不到或者不同交易节点之间频繁进行消息传递（和系统设计相关）。测试时候需要关注这些相关关联的交易，在分布式系统中交易记库、交易处理是否都落在了同一节点。特别是关联交易之间，任务调度相关的交易要素存在变化或者不同的情况，需要更多关注。

四、节点故障，避免“雪崩”效应。

分布式系统一方面享受节点冗余带来的弹性伸缩、快速扩容，以及灾备接管的便利，另一方面因为节点众多、调度复杂，如果错误侦测、异常隔离等方面做的不够完善，可能会因为一个节点的问题，引发灾难性的“雪崩”效应。测试时候要关注单节点的故障，是否能够快速侦探到，并且快速隔离故障节点。避免节点故障引发数据库或者队列的堵塞，引起大面积交易处理失败。

五、公共资源、公共服务的容量限制。

相对于集中式部署的系统，分布式系统节点数会多出很多，对于周边的一些公共资源、公共服务来说，会带来一定的压力。比如数据库连接、加密机连接、以及一些公共服务（比如用户系统、日志系统等）也需要针对性的对连接进行扩容处理。在测试过程中，需要评估当前周边公共资源和公共服务的容量限制、连接限制，是否能够满足分布式系统节点数，并留有一定的冗余，以应对节点横向扩展。如果不同节点之间有共用存储空间、Redis资源等，也需要在测试过程中关注不同节点之间如何做到隔离，避免节点间数据的相互覆盖。