微服务和数据库联接

对于将单一应用程序拆分为微服务的人们，您如何处理拆分数据库的难题。出于性能和简单性的原因，我从事的典型应用程序进行了很多数据库集成。

如果您有两个逻辑上不同的表（如果有的话，则是有界上下文），但是经常对大量数据进行汇总处理，那么在整体中，您很有可能避免面向对象，而是使用数据库的标准JOIN功能可在将聚合视图返回到您的应用程序层之前处理数据库上的数据。

您如何证明将此类数据拆分为微服务是合理的，因此可能需要您通过API（而不是数据库）“联接”数据。

我读过Sam Newman的《微服务》一书，在有关拆分Monolith的章节中，他举了一个“打破外键关系”的示例，他承认通过API进行联接会比较慢-但他继续说是否您的应用程序是否足够快，是否比以前慢？

这似乎有点不高兴吗？人们的经历是什么？您使用什么技术来使API联接的性能令人满意？

• 当性能或延迟无关紧要（是的，我们并不总是需要它们）时，只使用简单的RESTful API来查询所需的其他数据就很好了。如果您需要对不同的微服务进行多次调用并返回一个结果，则可以使用 API网关模式。

• 在Polyglot持久性环境中具有冗余是非常好的。例如，您可以将消息传递队列用于微服务，并在每次更改某些内容时发送“更新”事件。其他微服务将侦听所需的事件并在本地保存数据。因此，无需查询即可将所有必需的数据保留在特定微服务的适当存储中。

• 另外，不要忘记缓存：)您可以使用Redis或Memcached之类的工具来避免过于频繁地查询其他数据库。

服务可以具有来自其他服务的某些参考数据的只读复制副本是可以的。

鉴于此，当尝试将整体数据库重构为微服务（而不是重写）时，我会

• 为服务创建数据库模式
• 在该架构中创建版本化*视图**，以将该架构中的数据公开给其他服务
• 对这些只读视图进行联接

这将使您独立修改表数据/结构，而不会破坏其他应用程序。

除了使用视图之外，我还可以考虑使用触发器将数据从一个模式复制到另一个模式。

这将是朝着正确方向逐步发展，建立组件接缝的过程，稍后可以迁移到REST。

*可以扩展视图。如果需要进行重大更改，请创建具有相同视图的v2，并在不再需要旧版本时将其删除。**或表值函数或Sproc。

CQRS--命令查询聚合模式是克里斯·理查森（Chris Richardson）的答案。让每个微服务更新其自己的数据模型并生成事件，这些事件将更新具有较早微服务所需的联接数据的实例化视图。此MV可以是经过查询优化的任何NoSql DB或Redis或elasticsearch。这种技术导致最终的一致性，这绝对不错，并且避免了实时应用程序端的加入。希望这个答案。

我将针对使用领域（例如运营和报告）分开解决方案。

对于需要为来自其他微服务的数据的单一表单提供数据的微服务（这是可操作的情况），我认为使用API​​联接是必经之路。您不会需要大量数据，可以在服务中进行数据集成。

另一种情况是您需要对大量数据进行大查询以进行汇总等（报告情况）。为此，我会考虑维护一个共享数据库–与您的原始方案类似，并使用微服务数据库中的事件对其进行更新。在此共享数据库上，您可以继续使用存储过程，这将节省您的精力并支持数据库优化。

在微服务中，您创建差异。读取模型，例如：如果您有两个差异。有界上下文，有人想在这两个数据上进行搜索，然后有人需要侦听来自有界上下文的事件，并创建一个特定于该应用程序的视图。

在这种情况下，将需要更多的空间，但是不需要连接，也不需要连接。