我们有两个系统，其中系统 A 向系统 B 发送数据。要求每个系统都可以独立于另一个系统运行，并且如果另一个系统宕机，任何一个系统都不会崩溃。问题是在满足解耦要求的同时，系统 A 与系统 B 进行通信的最佳方式是什么。
系统 B 当前有一个进程轮询 db 表中的数据并处理已插入的任何新行。
一种建议的设计是系统 A 只需将数据插入到系统 b 的 db 表中，并让系统 B 通过现有进程处理新行。问题是这个解决方案是否满足两个系统解耦的要求？数据库是否被认为是系统 B 的一部分，可能变得不可用并导致系统 A 崩溃？
另一种解决方案是系统 A 将数据放入 MQ 队列，并有一个进程从 MQ 中读取，然后插入到系统 B 的数据库中。但这只是额外的开销吗？最终，MQ 队列是否比 db 表更容错？
一般来说，数据库共享是一种紧密耦合，除非可能出于速度目的，否则不是首选。不仅出于可用性目的，还因为系统 A 和 B 将在未来的几个时间点进行更改和升级，并且彼此之间的依赖关系应该最小 - 消息传递是一种明显的依赖关系，而共享数据库往往会咬你（或你的继承人）在最意想不到的时候在后面。如果你走数据库共享路线，至少使用专用表或视图明确共享接口。
有四个常见的集成级别：
它可以在各种情况下应用和组合，具有不同的可用性和可维护性。您对企业集成模式站点有一个很好的概述。
与任何中央集成基础设施一样，MQ 应该托管在具有高可用性、完全故障转移等的环境中。还有其他队列解决方案允许您分配队列协调。
使用队列进行通信。不要通过数据库将数据从系统 A“传递”到系统 B。您将数据库用作庞大、昂贵、复杂的消息队列。
使用消息队列作为消息队列。
这不是“额外”开销。这是解耦系统的最佳方式。它被称为面向服务的体系结构 (SOA)，使用消息绝对是设计的核心。
MQ 队列远比 DB 表简单。
不要比较“容错”，因为 RDBMS 使用巨大的（几乎无法想象的）开销来实现事务正确完成的合理保证水平。锁定。缓冲。写队列。存储管理。等等等等。
可靠的消息队列实现使用一些后备存储来保持队列的状态。开销比 RDBMS 少得多。性能要好得多。而且它的交互要简单得多。
在 SQL Server 中，我将通过 SSIS 包或作业来完成此操作（取决于记录的数量和我正在移动的内容的复杂性）。其他数据库也有 ETL 解决方案。我喜欢 ETL 解决方案，因为我可以记录更改的内容和处理的错误，我可以将由于某种原因不会发送到其他系统的记录（两个数据库之间的数据结构很少相同）发送到控股公司表而不杀死其余的进程。我还可以在数据流动时对数据进行更改以适应数据库差异（例如查找表值，例如 db1 中的已完成状态为 5，在 db2 中为 7，或者说 db2 有一个 db1 没有的必填字段，而你如果它为空，则必须向该字段添加一个默认值）。