CA Service Virtualization 社区版
5.00/5 (1投票)
在本文中，我将通过设置和使用 CA Service Virtualization 社区版来处理 API，来对该产品进行评测。具体来说，我将在 Windows 10 上运行 CA Service Virtualization 社区版 1.0.3 版本。
在过去的三年里，我作为一名开发人员的工作重点之一是为将一个庞大的电子商务系统迁移到 AWS Cloud 而开发 API-first 的微服务。
在这个角色中，我面临的挑战之一是找到一个服务虚拟化产品，它足够简单，易于学习，同时又提供足够的功能来实现您进行全面软件测试所需的各种响应。
这就是为什么我很高兴能评测 CA Service Virtualization 社区版。该产品可在软件开发过程中模拟不可用的资源，从而实现更快的软件交付和更高效的并行工作流程。它是一个便捷的工具，可以提高软件交付生命周期的效率，而无需增加团队规模或进行其他重大新投资。
在本文中，我将通过设置和使用 CA Service Virtualization 社区版来处理 API，来对该产品进行评测。具体来说，我将在 Windows 10 上运行 CA Service Virtualization 社区版 1.0.3 版本。
安装和入门
注册和下载社区版的过程似乎非常直接。考虑到下载的大小，我渴望了解它提供了哪些功能以及我将如何使用它们。
我对 入门 社区页面的初步印象是，它有点令人不知所措。该页面信息量很大，并且显然是为比我最初打开时更宽的视图设计的。
“立即免费注册！”按钮似乎将我带回了产品下载的注册页面。但是，我能够返回并使用“登录”链接找到注册社区的位置。主页上“入门”的实际链接并不明显。也许直接将用户引导至入门页面，并提供社区介绍以及直接从该页面注册的链接，可以让开发人员更轻松地上手。
在首先点击入门链接后，文档与我的体验并不完全匹配。我假设要按照步骤进行，我需要创建一个新项目。我还不确定文档中是否应该包含链接，或者当文档说明我应该“单击任意一项以继续执行特定方法”时，默认项目中是否会有选项。
文档在解释主屏幕的各个部分方面做得非常出色。我发现导航相对直观，并且能够相对轻松地重命名项目并开始我的第一组任务。
在本评测中，我将重点关注服务虚拟化主页上突出显示的四种用法，具体是：
- 使用内置 API 资源管理器
- 录制实时事务
- 使用 API 设计规范
- 使用示例数据（我有一些从 CodeSV 评测中获得的请求-响应对。）
使用示例数据
我决定从示例数据选项开始，因为我有一些由 CodeSV 生成的请求/响应对，并且我想看看它们在这个产品中如何工作。
选择“文件”选项后，我点击了“浏览文件”按钮，然后回到了主屏幕。（我不确定这是因为我将页面打开了一段时间，还是在我打开时更改了项目名称。）一旦我返回并再次点击“文件”，我就得到了一个用于向项目添加文件的对话框。
我成功地将这些对导入到项目中，并识别并删除了一个重复的对。此时，我回到了文档，因为我不确定下一步该做什么。
我能够使用请求/响应对创建一个虚拟服务。但是，我遇到了一些困难。我试图虚拟化的调用是到 https://www.zipcodeapi.com。请求的 URL 包括一个 API 密钥和几个额外的路径参数。一个完整的请求看起来是这样的：
在事务包中，我可以看到完整的 URL；但是，当我启动虚拟服务时，最后两个参数从虚拟服务 URL 中省略了。当我编辑包并删除最后两个参数，然后保存、删除、重新创建并重新启动虚拟服务后，它似乎按预期运行。
我还注意到，我导入的两个请求/响应对都有相同的基本 URL，这是基于似乎存在的字符限制。倒数第二个参数是 URL 的区分部分。这在 Bundle Manager 中似乎并未区分它们。
我确实喜欢从包创建的虚拟服务似乎是不可变的。直到那时，我还没有在文档中读到任何说明这一点的内容，但我认为这是一个非常理想的功能。
我还注意到，主事务似乎是默认事务（如果最后一个参数未与包中的任何其他事务匹配，前提是仅更改了最后一个参数，而不是 URL 的其余部分）。
内置 API 资源管理器
API 资源管理器易于使用，并且是一个便捷的工具。我发现界面非常简洁直观。我通常使用 Postman 来执行 API 调用并进行测试，但我发现 API 资源管理器更直观，将来可能会使用它。我还发现其“保存”功能类似于 Chrome 在浏览器中实现书签的方式，这有助于使其更加直观。
我确实发现，内容在发送请求之前不会保存，这最初并不明显。界面也没有指示请求是否已更改但未保存。（我用过的其他应用程序会使用星号或其他小指示器来表示已添加但尚未保存的更改。）
将保存的查询用于 Bundle Manager 简单直观。
在我日常的开发活动中，我通常完全与 REST Web 服务进行交互。（在我职业生涯的某个时候，我可能与 SOAP Web 服务进行过通信，但那已经是很多年前的事了。）SOAP 资源管理器很方便，如果我需要与 SOAP 服务进行交互，我认为它将是一个很棒的工具。我也能够与 SOAP Web 服务进行交互，并更好地了解 API 以及可用的选项。
录制实时事务
当我开始使用该应用程序时，实时事务录制被突出显示为一个功能，但界面上并不清楚在哪里进行，而且在入门文档中也没有提到。通过 API 资源管理器，我录制了实时事务并将它们添加到“保存事务”窗口。然后，我可以将它们导入到 Bundle Manager 中。
在探索 Bundle Manager 时，我遇到了实时录制选项。它并不清楚如何工作，所以我进行了一些额外的探索。我假设如果我设置了一个本地 Web 服务，我可以使用录制器来拦截和录制对该服务的调用。
我在本地开发机器上启动了一个小的 Spring Boot 应用程序并启动了录制器。对 Web 服务的调用似乎没有被录制器捕获。
事务录制工具听起来很有用，但我无法确定它究竟应该如何工作。
API 设计规范
当我读到 API 设计规范这个主题时，我想知道是否可以将 API 规范馈送到服务中并用它来虚拟化服务。与实时事务录制一样，此功能在入门文档中并未标明，我不得不四处摸索才找到它。
我导航到 Bundle Manager，点击“文件”，发现我可以导入请求/响应对以及 Swagger 和 WSDL 文件。我使用了我本地系统上的一个 Swagger 文件，Bundle Manager 立即充满了文件中指定的端点。这可能是我使用该工具的体验中的亮点。
我确实尝试使用此结果运行一个虚拟服务。虚拟服务在端口 8080 上启动，或者至少它尝试在端口 8080 上启动。没有迹象表明虚拟服务存在任何问题，但我与之交互的尝试均未成功。
在几次不成功的尝试后，我意识到我之前在我机器上启动了一个 Web 服务来测试事务录制功能，它也在端口 8080 上运行。关闭该 Web 服务并重新启动虚拟服务似乎解决了我的问题。
我对这次经历注意到了一些小的意外。首先，我不确定虚拟服务为什么会在端口 8080 上启动。Swagger 文件中似乎没有任何指示，所以这可能只是一个内置的默认设置。其次，虚拟服务在尝试启动时必定失败了，但没有给出任何警告。理想情况下，它不应该静默失败，但更糟糕的事情也发生过。
运行虚拟服务
总的来说，我创建和运行虚拟服务的经历非常积极。我确实遇到了一些问题，这些问题似乎是由我使用的 URL 的长度或路径参数的数量引起的。
混合使用 SOAP 调用和我在最初使用 Bundle Manager 进行实验时使用的请求/响应对，似乎会创建一个处于奇怪状态的虚拟服务。复制 URL 按钮会响应，并且似乎我尝试使用的所有 URL 都默认使用 SOAP 查询，即使它是列表中的最后一个事务。我不认为像这样混合使用 SOAP 和 REST 请求是该服务的有效用例，但看到应用程序如何处理它很有趣。
结论
服务虚拟化填补了任何依赖于开发团队之间以及与外部服务提供商之间 API 调用之服务的组织的需要。对工具的沮丧常常导致开发出内部解决方案和其他措施，以便在存在依赖关系的情况下继续开发和测试，但这很少是最佳实践。
我认为 CA Service Virtualization 提供的解决方案满足了我对虚拟服务解决方案的大部分（如果不是全部）需求。我特别喜欢能够导入 API 文档，并通过几次点击就能让虚拟服务提供响应。
我也喜欢该工具存储事务并允许创建和管理多个服务的方式。就个人而言，我很有兴趣了解该工具如何能协助我们团队的日常开发活动。