使用 .NET 的 Dev Proxy 构建和测试弹性应用

https://devblogs.microsoft.com/dotnet/build-test-resilient-apps-dotnet-dev-proxy/

在构建连接到 API 的应用时，我们通常专注于让应用正常工作。但是，当 API 速度慢、返回错误或不可用时会发生什么？你最不想看到的就是当你的应用程序坏了时，一个愤怒的客户给你打电话。但是，当你不控制集成的 API 时，很难模拟你的应用将如何处理这些场景。除非您使用 Dev Proxy。

连接到 API 的难点

如今，很难想象一个应用程序没有连接到 API。我们将 API 用于所有事情：从获取数据到执行操作。但是，使用 API 不仅仅是发出请求并获得响应。您使用的 API 无法按预期工作只是时间问题。如果你没有考虑过，你会给自己带来麻烦。让我告诉你怎么做。

您发布了一个新的 Web 应用程序，它运行良好。但真的是这样吗？

假设您正在构建一个连接到 API 以获取产品的应用程序。您还可以与外部服务集成以获取其他产品信息。在开发中，你使用这两个 API 的开发版本，只有你和团队中的其他几个开发人员使用。您的应用既快速又可靠。它只是工作。然后，将应用部署到生产环境。它一炮而红。事实上，你的应用非常成功，以至于你集成的外部服务无法再处理负载并开始返回错误。您的应用中断了。客户不满意地离开并去找竞争对手。你能预料到这一点吗？您能否以不同的方式构建应用来处理这种情况？

模拟 API 错误和行为（如速率限制或限制）并非不可能，但很难。通常，你无法控制你集成的 API，所以为了模拟它们的不同行为，你最终会编写复杂的模拟——一堆你不会发布的代码。至少可以说，这是低效的，但这是唯一的方法，不是吗？差一点。

使用 Dev Proxy 模拟 API 行为

如果我告诉你，有一种方法可以让你测试你的应用如何处理你连接到的 任何 API 的任何行为，而不必更改应用中的一行代码，你会怎么样？

Dev Proxy 是一个 API 模拟器，可用于模拟不同的 API 行为，而无需更改应用的一行代码。没错。使用 Dev Proxy，您可以模拟错误、延迟、速率限制等。一直以来，您的应用程序都认为它已连接到真正的 API！Dev Proxy 允许你确保应用在连接到的 API 中断时不会惨遭失败。愤怒的客户或客户经理不再打来电话，要求你放下一切来灭火。

Dev Proxy 是如何工作的？

Dev Proxy 是在开发计算机上本地运行的 Web 代理。在启动它之前，您可以将其配置为监视对特定 URL 的请求。然后，定义它应该如何处理这些请求：它应该返回预定义的响应、引发错误、延迟响应或模拟速率限制，还是其他行为？当您启动 Dev Proxy 时，它会将自身注册为您的系统代理，并拦截与您配置的 URL 匹配的所有请求。然后，它会应用您定义的行为。你的应用不知道它没有与真正的 API 通信。它只是得到回应，就好像它是一样。这使它成为测试应用如何处理不同 API 行为的好方法。让我们看看如何使用 Dev Proxy 在示例 .NET Aspire 应用中模拟 API 行为。

示例案例：使用 Dev Proxy 改进 .NET Aspire 应用

请考虑使用 .NET Aspire 构建的此示例电子商务应用。它由多个服务组成，包括产品目录的 API。它实现默认的弹性模式。让我们使用 Dev Proxy 模拟不同的 API 行为来测试默认应用的配置，并提高应用的弹性。

让我们从启动应用程序开始，找出产品目录 API 的 URL。我们将配置 Dev Proxy 以拦截对此 URL 的请求并模拟不同的行为。产品目录 API 可在 http://localhost:5222 上获得。

模拟 API 限制

让我们启动 Dev Proxy 并将其配置为拦截对此 URL 的所有请求：

devproxy --urls-to-watch “http://localhost:5222/*”

在此示例中，我们将使用默认的 Dev Proxy 配置，该配置模拟了几个常见的 API 错误，以及延迟和限制。您可以通过其配置文件和它包含的插件集合来控制 Dev Proxy 设置。

现在，让我们重新启动 .NET Aspire 应用，将其配置为使用开发代理作为系统代理。它将通过 Dev Proxy 将所有请求路由到产品目录 API，这将模拟不同的行为。

HTTP_PROXY=http://127.0.0.1:8000 dotnet run --project src/eShop.AppHost/eShop.AppHost.csproj

让我们从导航到产品目录开始。报错啦！

回到终端，我们可以看到 Dev Proxy 模拟了 429 个请求过多的错误，指示客户端回退 5 秒钟。虽然该应用程序内置了弹性功能，但它还是并行发出多个请求，这使得它看起来不遵循后退并导致 Dev Proxy 使请求失败。在几次尝试调用 API 失败后，应用放弃并在浏览器中显示原始堆栈跟踪。

我们如何提高应用的弹性以处理这种情况？首先，我们应该考虑捕获 API 异常并以用户友好的方式显示它。它不仅可以帮助我们处理限制，还可以帮助我们处理其他 API 错误。我们还应该考虑以不同的方式处理限制，以确保应用正确回退，并让 API 有时间恢复。

这只是可以使用 Dev Proxy 模拟的一个场景。您还可以模拟其他 API 行为，例如延迟、速率限制等。这样一来，你就可以测试应用如何处理不同的 API 行为，而无需更改应用的一行代码。使用 Dev Proxy 是测试弹性代码在最需要时是否按预期工作的好方法。

总结

当您连接到应用中的 API 时，您需要考虑的不仅仅是让应用正常工作。您使用的 API 失败只是时间问题。当他们这样做时，你要确保你的应用能够正确处理它，并且不会丢失你的客户数据。Dev Proxy 允许你轻松模拟不同的 API 行为，而无需更改应用的一行代码。借助 Dev Proxy，您可以放心地将应用部署到生产环境，而不必担心在应用出现故障时愤怒的客户会打电话给您。

在您的应用程序上 试用 Dev Proxy，并亲自查看如何改进它。

参考

• 安装 Dev Proxy 工具箱