您应该在使用之前测试外部系统吗？

Question

注意：这不适用于单元测试或集成测试。这适用于应用程序运行时。

我正在开发一个与多个后端系统通信的系统，可以将其分为三种类型

• 关系数据库
• SOAP或WCF服务
• 文件系统（网络共享）

由于环境会运行，因此无法保证在运行时可以使用其中任何一个。事实上，其中一些看起来非常脆弱，每天都会多次下降:(

我们的想法是在实际代码之前运行一小段测试代码。如果出现问题，则保留请求并轮询直到目标系统，直到它可用为止。可能会在代码中重新运行测试，以检查它是否仍可在逻辑点上使用。最终目标是拥有一个非常稳定的系统，无论其通信系统的稳定性（或缺乏稳定性）如何。

我对这个设计的疑问是：

1. 它有重大问题吗？ （在测试完成和代码运行之间可能会失败的事实是可以理解的）
2. 有更好的方法来实现这种设计吗？
3. 使用传统的异常处理和/或交易会更好吗？

更新

• 系统需要以协调的方式与后端系统通信。
• 系统本质上非常异步，因此使用排队技术等方法很好。
• 即使一个或多个后端系统出现故障，系统也必须运行，因为其他系统可能已启动，并且可能会处理某些信息。

Answer 1

你将需要传统的异常处理，无论如何，因为你指出在你的最后一次检查和实际请求之间总是有可能失败。因此，我认为您找到的任何解决方案都应该尝试与此进行顺畅的互动。

您并未说明这些片状资源是否需要以某种协调方式进行交互，这表明您可能应该使用某种类型的事务管理器来执行此操作。我不相信您希望在应用程序代码中进入事务管理的步法以满足大多数需求。

有时我也看到人们使用AOP将重试逻辑封装到失败的后端系统（例如由于超时问题）。谨慎使用这可能是一个不错的解决方案。

在某些情况下，您还可以使用消息排队技术来缓解不稳定的后端。例如，您可以将消息队列作为事务的一部分提交，并且仅在成功时弹出队列。但是，只有当您能够使用异步过程时，才能实现此设计。

与往常一样，真正的稳定性只能通过攻击问题的根本原因来实现。我修复了大型机TCP / IP堆栈中修复了25年的错误，因为我们已经超出它，因此 可能。

Answer 2

Microsoft Smartclient框架提供了ConnectionMonitor类。应该易于使用或重复。

Answer 3

我们解决这类问题的方法是在提出主要应用程序之前运行一个非常基本的“理智测试程序”。这是胖客户端，所以我们可以在每次应用程序启动时运行测试。这种健全性测试会出现并检查数据库可用性和外部网络（外部网）访问等内容，并且可以扩展为执行Web服务。

如果失败，则通知用户，并且至关重要的是还向支持/开发团队发送了一封电子邮件。这些电子邮件很快变得不合适，因为有很多正在创建，但我们然后设置过滤器，所以我们知道什么时候真的很糟糕。整体而言，这种方法运作良好，我们最大的胜利就是能够告诉用户系统在输入数据之前已经关闭，并且在漫长的过程中获得了部分。他们非常喜欢它。

在技术层面，理智是用C＃编写的，它以常规方式使用异常处理，而不是找到它正在寻找的问题。理智计划本身就变成了一个迷你应用程序，它独立于主应用程序。如果我再次这样做，我会使用日志框架来捕获问题，这比我们的硬编码方法更灵活。