database - 您应该在使用外部系统之前对其进行测试吗？

Question

注意:这不适用于单元测试或集成测试。这是在应用程序运行时使用的。

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

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

由于运行环境的原因，无法保证其中任何一个在运行时可用。事实上，其中一些看起来很脆弱，一天会掉落好几次 :(

想法是在实际代码之前运行一小段测试代码。如果有问题则坚持请求并轮询直到目标系统可用。可以在代码中重新运行测试，以检查它在逻辑点是否仍然可用。最终目标是拥有一个非常稳定的系统，无论与之通信的系统是否稳定(或缺乏稳定)。

关于这个设计我的问题是:

1. 是否存在重大问题？ (诸如在测试完成和代码运行之间可能会失败的小事情是可以理解的)
2. 有没有更好的方法来实现这种设计？
3. 使用传统的异常处理和/或事务会更好吗？

更新

• 系统需要以协调的方式与后端系统对话。
• 该系统本质上是非常异步的，因此可以使用诸如排队技术之类的东西。
• 即使一个或多个后端系统出现故障，系统也必须运行，因为其他系统可能已启动并且可以处理某些信息。

Answer 1

无论如何，您将需要传统的异常处理，因为正如您指出的那样，在您上次检查和实际请求之间总是有失败的可能。所以我真的认为您找到的任何解决方案都应该尝试与此顺利交互。

您没有说明这些不稳定的资源是否需要以某种协调的方式进行交互，这表明您可能应该使用某种事务管理器来执行此操作。我认为您不想在应用程序代码中进行事务管理以满足大多数需求。

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

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

和往常一样，真正的稳定性只能通过解决问题的根本原因来实现。我在大型机 TCP/IP 堆栈中修复了一个 25 年前的错误，因为我们正在超速运行它，所以它是可能的。