近年来，尽管微服务非常火爆，但仍有不少人不喜欢微服务，甚至抵制它。其主要原因在于其成本高、难度大。对困难来说，主要是遇到了一些难以解决的问题，其中包括以下三个与测试数据和测试环境有关的问题：问题1:测试环境由多个团队共同使用。

在大型微服务系统中，一些核心服务往往由多个团队共同调用，可能也有多个依赖服务。当一个服务的某个测试环境被多个团队(服务)共同使用时，主要存在以下两个难点。同一个测试数据可能会被不同的团队修改。有些团队通过创建多个测试环境来解决这个问题，但是成本很高。对于很多技术强大的互联网公司来说，Docker等技术手段可以降低一些成本，但是对于很多传统企业来说，很难实现高成本的多环境。

同一个测试数据可能被其他团队占用。所谓占用，就是一个测试数据一旦被某人意外使用，他可能会根据自己的场景使用。这个时候你用的时候，很可能会受到影响，得不到想要的结果。第二个问题：准备测试数据需要很多时间。当测试一些业务不是很复杂的系统时，准备测试数据可能并不难。然而，在一些传统行业的复杂系统中，准备测试数据非常困难，如银行、保险、通信等复杂系统。

我曾经测试过一个保险系统，在测试环境中准备一套数据甚至需要几个小时，因为整个系统的业务非常复杂，数据库设计也非常复杂，很少有人知道如何直接操作数据库来准备数据。因此，系统本身必须创建准备数据。系统本身是基于MainFrame的，用户界面都是Console下的用户界面，操作非常复杂，导致创建一套测试数据需要很长时间。许多银行和保险公司的核心系统至今仍然保留着这种模式。因此，在这样一个传统行业的系统中，测试数据的准备是一个非常大的问题。

其次，在许多系统中，测试数据一旦使用，状态就会发生变化，无法重复使用。因此，重新测试需要重新创建测试数据，这也是一个常见的严重问题。问题3:服务部署或网络导致测试环境不稳定，版本不匹配。这也是经常遇到的情况。对某些稳定且无变化的系统来说，这可能不是一个问题，但对某些正在开发过程中，或有大量修改或自身不稳定的系统来说，这是非常普遍的。

有些服务部署和网络问题很容易理解，就是依赖服务部署。其次，依赖服务正在调试中，在调试过程中，服务本身的一些状态可能会不断变化。或者依赖服务有错误，导致服务有问题。最后，消费者可能只需要版本1.0来依赖服务，但是在测试环境中已经部署了2.0版的服务，导致服务对消费者不可用。

解决方案:服务虚拟化。服务虚拟化(ServiceVirtualization)技术可用于解决上述问题。下面是服务虚拟化的简单示意图：虽然服务虚拟化看起来很简单，但它实现了非常丰富的功能，如Hoverfly，从而解决了上述一系列问题。

Hoverfly是一款开源免费服务虚拟化工具，它的虚拟数据是Simulation，可以重复使用Json格式。这是基于Go开发的，重量轻，效率高。并支持Python和Java的扩展，以及RESTAPI的控制。并暂时提供模拟网络延迟、随机错误和限定速度。但它所支持的协议有限，暂时只支持HTTP和HTTPS。但它最重要的是它支持六种工作模式，即：Capture模式、Simulate模式、Spy模式、Synthesize模式、Modify模式、Diff模式。这六种模型基本上可以实现服务虚拟化的各种功能。首先，通过Capture模型，可以获得手动测试和系统正常使用时各种服务的交互数据，然后进行分析和修改，可以获得更多类型的数据。这些数据通过Spy、Synthesize、Modify和Simulate模型进行不同类型的服务虚拟。不同的团队可以根据基本类型的数据快速定制自己团队的私有虚拟数据集，也可以根据不同版本的服务定制不同版本的虚拟数据集，从而隔离不同版本服务之间的数据，避免不同团队之间的测试数据冲突。