微服务和数据库连接

小开

当性能或延迟不太重要时(是的，我们不太重要总是需要它们)使用简单的 RESTful API 是完全可以的查询所需的其他数据。如果您需要执行多个调用不同的微服务并返回一个可以使用的结果 API 网关模式
在通晓多国语言环境中有冗余是完全可以的。例如，您可以为您的微服务使用消息传递队列，并在每次更改某些内容时发送“ update”事件。其他微服务将监听所需的事件并在本地保存数据。因此，不需要查询，而是将所有必需的数据保存在适当的存储中，以用于特定的微服务。
另外，不要忘记缓存:)您可以使用像雷迪斯或 Memcached这样的工具来避免过于频繁地查询其他数据库。

小开

服务可以从其他服务获得某些引用数据的只读复制副本。

考虑到这一点，在尝试将单片数据库重构为微服务(而不是重写)时，我会这样做

为服务创建一个 db 模式
在该模式中创建版本化的 * 视图 * * ，以将该模式中的数据公开给其他服务
对这些只读视图执行连接

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

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

这将是在正确方向上的渐进式进展，建立组件的接缝，稍后可以转向 REST。

* 视野可以扩展。如果需要重大更改，则创建相同视图的 v2，并在不再需要旧版本时删除旧版本。 * * 或表值函数，或 Sprocs。

小开

在 Microservices 中创建 diff。阅读模型，例如: 如果你有两个差异。有限上下文和有人想搜索这两个数据，然后有人需要监听来自两个有限上下文的事件，并创建一个特定于应用程序的视图。

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

小开

CQRS ——-命令查询聚合模式是 Chris Richardson 提供的答案。让每个微服务更新自己的数据模型并生成事件，这些事件将更新具体化视图，其中包含来自早期微服务的所需连接数据。此 MV 可以是任何 NoSqlDB 或 Redis 或经过查询优化的 elasticsearch。这种技术产生的最终一致性绝对不错，避免了应用程序端的实时连接。希望这个能给你答案。

小开

我将把使用领域的解决方案分开，比如说操作和报告。

对于那些为需要来自其他微服务的数据的单个表单提供数据的微服务(这是操作案例) ，我认为使用 API 连接是可行的方法。您不需要大量的数据，您可以在服务中进行数据集成。

另一种情况是需要对大量数据进行大查询以进行聚合等(报告情况)。对于这种需要，我会考虑维护一个共享数据库——类似于您最初的方案，并使用来自您的微服务数据库的事件来更新它。在这个共享数据库上，您可以继续使用存储过程，这将节省您的工作并支持数据库优化。