decoupling - 数据库好的系统解耦点？

Question

我们有两个系统，系统 A 将数据发送到系统 B。要求每个系统都可以独立于另一个系统运行，并且如果另一个系统宕机，则任何一个系统都不会崩溃。问题是在满足解耦要求的情况下，系统A与系统B通信的最佳方式是什么。

系统 B 当前有一个进程轮询数据库表中的数据并处理已插入的任何新行。

一个建议的设计是系统 A 只将数据插入系统 b 的数据库表，并让系统 B 通过现有进程处理新行。问题是这个方案是否满足两个系统解耦的要求？数据库是否被视为系统 B 的一部分，可能变得不可用并导致系统 A 崩溃？

另一种解决方案是系统 A 将数据放入 MQ 队列，并有一个进程从 MQ 读取数据，然后插入系统 B 的数据库。但这只是额外的开销吗？最终，MQ 队列是否比数据库表更容错？

Answer 1

一般来说，数据库共享是一种紧密耦合，除非可能出于速度目的，否则不是首选。不仅出于可用性目的，还因为系统 A 和 B 将在未来的几个时间点进行更改和升级，并且彼此之间的依赖性应该最小 - 消息传递是一种明显的依赖性，而共享数据库往往会咬你(或你的继承人)在最意想不到的时候在后面。如果你走数据库共享路线，至少要用专用表或 View 明确共享接口(interface)。

有四种常见的集成级别:

1. 数据库共享
2. 文件共享
3. 远程过程调用
4. 消息传递

可以在各种情况下应用和组合，具有不同的可用性和可维护性。您在 enterprise integration patterns site 上有一个很好的概述.

与任何中央集成基础架构一样，MQ 应该托管在具有高可用性、完全故障转移等的环境中。还有其他队列解决方案允许您分配队列协调。