微服务讲堂--【4】风洞系统

一、系统特性

    风洞是以人工的方式产生并且控制气流，用来模拟飞行器周围气体的流动情况，并可测量气流对飞行器的作用效果以及观察物理现象的实验设备。这个定义来自百度百科，微服务和飞行器压根就搭不上边，之所以要在微服务架构中借用风洞的概念，用于形象描述一种自动化测试的解决方案，主要在于风洞有这么几点特性和这个解决方案极为相似。以下称飞行器模拟测试环境为【风洞】，称微服务模拟测试系统为【风洞系统】，两者容易混淆，其阅读时注意区分。

1、人工产生和控制气流。自动化测试中，要将微服务置于一个运行环境中，而这个环境就是要人工构造出来的模拟生产环境。

2、飞行器是独立的，而并不必须是完整的，即便只有外壳。置于测试环境的微服务是被单独剥离出来的，所依赖的其他上下游环境不是必须的。

3、效果是可测量的，结果是可观察的。这个特性是风洞对于飞行器设计最核心的价值，也是这个解决方案要实现的目标。

4、风洞中气流的流动状态，通过驱动系统高度模拟现实环境。这也是该解决方案一个重要特性。确保在测试环境中，微服务所需要面对的运行环境和数据处理，与生产环境高度一致，减少意外情况发生。

5、环境是可重复的。风洞本质上是现实模拟系统，这意味着，这种环境是可重复的出现，不受时间和地域限制。在风洞系统中，可以截取生产环境中，一段时间内发生的过程和数据进行模拟，重复出现，供微服务测试使用。

二、系统价值

    已经存在很多测试系统，为什么还要再重新设计一个新测试系统呢？在微服务架构下，遇到了全新测试的问题，这个问题在传统的测试框架和技术下，代价较高。

    微服务架构下，因为服务被细分，导致服务数量增加，调用链变长，因此服务间依赖更加复杂。同时服务本身更加简化，重构代价也变小，那么重构的频率也增大了。由此带来的一个直接结果就是测试案例数量激增，同一功能重复测试的次数也增加。

    在不增加测试人力资源情况下，回归测试成了一个奢侈品。而在服务上线后，由于时间相对比较紧张，冒烟测试能够覆盖的功能点也大大被制约。在微服务数量增多，服务变更概率增大的情况下，受到测试资源的限制，测试覆盖率也会随着下降。

    如何解决测试效率问题，构建一个高效的自动化测试系统，是微服务架构必须要面对的问题。而这个问题，在很多文章中，没有成系统的论述和完整的解决方案。

    当风洞系统被建成之后，可以很方便的为微服务构建一个独立的测试环境，即使该微服务还没有被实现。在微服务实现过程中，可以随时接入该系统进行测试，确保代码最终能够符合设计需求。即使未来重构变更该微服务，该测试环境依然可以复用。

    随着不断运行验证，还可以将新遇到问题加入到该测试环境，不断累积丰富测试案例。而不常遇到的边界条件，也可以人工编写成案例，加入到案例库。同样案例库，可以被用于回归、压力、冒烟等不同测试用途中，不需要重新编写，还可以自动运行，这样大大降低了测试人员的工作量，节约测试资源，缩短测试时间。

    测试人员可以根据产品需求和接口定义就可以自行建设测试案例库。开发人员只需要根据测试案例库，独立完成开发过程中的测试，降低对单元测试强度和覆盖率的要求。

三、系统构成

    风洞是由洞体、驱动系统、测量控制系统。与此相对应，洞体对应于风洞系统本身运行环境，包括操作系统、网络等；驱动系统对应于数据播放和接收系统，称之为数据交互系统；测量系统对应于数据比对和校验系统，称之为数据验证系统；控制系统则对应于发送速度和过滤控制，称之为数据控制系统，也可以作为数据交互系统一部分。

    除此之外，风洞系统还需要一个数据生成系统，为测试环境准备数据，并且清洗和格式化该数据，使数据更好的适配测试需求。风洞中的风流是单一的元素，而数据是复杂而多样，他们之前多数是存在业务逻辑关联，因此厘清这些关联，降低测试过程中的噪音和影响，确保测试结果符合期望，对于整个风洞系统是非常必要的。

四、幂等性

    幂等性在自动化测试的验证环节非常关键，业务逻辑的幂等性却是非常难以保障。多数解决方案都是引入逻辑验证，甚至干脆只简单判断是否有返回结果，而不是数据精确验证。或者精心构造了一些特定案例，强化数据验证精度或者降低验证难度。

    逻辑验证本身要编写代码或者配置，加大难度，自动化测试效率大打折扣，而且精确度也无法保证。而构造特定测试案例，要投入过多的精力，也降低了普适性，广度上也得不到保障。

    如果将时间序列引入到数据中，那么幂等性难题就转换为时序性难题，复杂多样的业务逻辑不再对数据验证产生影响，只剩下技术难题等待解决。因为，只要微服务的数据输出和预期时序是一致的，结果就是正确的，不需要去关心微服务所实现的业务逻辑究竟是什么。

    在微服务架构中，我一直强调引入消息总线。消息总线有很多优势，在这里最关键优势在于，消息队列是FIFO模式，天然确保时序性。一个典型的微服务，从消息队列中接收消息，将处理结果推送到消息队列，这两者都可以在时间轴上标记出时间戳和顺序关系。

    影响微服务结果输出时序性的因素有几个：1、进程内部多线程的竞争；2、存在和时钟强关联的处理逻辑，比如计算执行时长；3、和其他微服务共享数据，比如直连数据库。这些技术难题留待有兴趣的同学深入讨论，不在这里赘述。

五、数据生成

    一个灵活易用的测试数据生成系统，对风洞系统的推广至关重要。和传统自动化测试系统不一样，风洞系统除了系统本身架构设计之外，将数据生成系统的重要性，上升到和整个测试系统同等重要的地位。

关于数据生成的重要构想，是捕获微服务在网络上传输的内容，包括输入输出。将输入内容作为测试数据，将输出内容作为数据验证的参照系。根据上一节的论述，只要未来的测试结果，在时序上和参照系数据是一致，那么就是正确的。

    在这里，再一次强调下消息总线。基于消息总线的微服务，可以通过旁路复制消息队列的数据，无侵入导出所有的输入输出。

    数据生成系统和其他系统有非常强独立性，他们之间只需要通过数据文件进行交换。数据生成系统可以从日志中提取数据，也可以用程序生成数据文件。数据交换系统从数据文件中读取测试数据，向微服务推送。数据验证系统从数据文件中读取参照数据，与微服务数据进行时序比对。

    数据生成系统的高度独立性，允许测试人员使用更简便的程序语言，如python，perl来生成包含复杂业务逻辑的数据。消息队列的旁路导出，是一种更加简便的方法，测试人员可以通过图形界面发送，或者手工编制消息文本，都是可以的。