为什么需要服务虚拟化？
当前服务（消费者）依赖的服务（生产者）尚未开发或仍在开发中时。 当服务需要由具有完全不同设置的不同团队并行访问时。 当服务（生产者）由第三方或合作团队控制，并且每天的请求有配额限制。 当生产者服务仅在特定时段可用时。
什么时候使用服务虚拟化？
单元测试 —— 在99%的情况下，使用传统的模拟（mock）和插桩（stub）技术就已足够。 组件测试 —— 这是服务虚拟化大放异彩的地方：你可以测试组件如何相互通信，而不依赖于外部服务。 集成测试 —— 集成测试本质上是针对真实服务运行的。在某些测试场景中，依赖的外部服务可能是个问题（如边界情况、第三方服务等），因此会使用服务虚拟化。 契约测试——当针对生产者测试契约时，你可能需要服务虚拟化来模拟生产者服务的依赖关系。 端到端测试——根据定义，端到端测试不应该依赖服务虚拟化，因为你是在对真实系统进行测试。但在某些罕见情况下，如果你依赖于不可靠的第三方服务，服务虚拟化仍可能是一个可行的解决方案。
服务虚拟化工具 Hoverfly
Hoverfly 工作模式
Capture ——像往常一样对真实服务进行请求。请求和响应被Hoverfly代理拦截并记录下来，以便后续使用。 Simulate ——为提供的请求返回模拟响应。模拟可能从不同类型来源加载，如文件、类路径资源或URL，或使用Hoverfly领域特定语言（DSL）以编程方式定义。这是开发中服务的首选模式。 Capture or Simulate ——结合前两种模式。如果模拟文件不存在，则代理以捕获模式启动；否则，以模拟模式启动。当已开发的服务或第三方服务可用时，优先使用此模式。
1. 使用真实服务执行请求，该服务可能部署在测试运行机器之外。
2. Hoverfly代理重定向流量到真实主机，响应被返回。
3. Hoverfly代理为由真实服务交互生成的匹配请求和响应存储脚本文件。
4. 真实响应被返回给调用者。
simulate 模式
对A发起请求，但调用没有被路由到真实服务，而是被路由到了Hoverfly代理。 Hoverfly代理检查与所提供的请求相对应的响应脚本。 预设的响应被重放给调用者。
往期推荐
