database - 在微服务上解耦数据库的原因是什么？

Question

这是我目前在这个问题上的发现，这些是正确的还是缺少某个方面？

微服务有两大原则:

• 强内聚 -> 相关代码被组合在一起，例如一个类(class)在定义明确的工作上做这就是强/hingh 凝聚力。
• 松散耦合 -> 互连系统中的组件，以便这些组件尽可能减少相互依赖。耦合是指一个元素对另一个元素的直接了解程度。因此，更改一项服务不需要更改另一项服务。

对于共享数据库(如非解耦)架构，这两个原则都没有涵盖。这是由于以下事实:

• 用户与特定技术之间存在固定联系选择以及实际的数据库实现。
• 业务/应用程序逻辑可能分布在多个用户之间。
• 需要编辑的共享信息可以触发更改多个地方的行为。
• 由于共享的架构更加单一数据库故障会影响许多服务器，因为它们都是绑定(bind)的一起，即使是完全的系统故障也可能发生由于耦合。

为避免上述问题:解耦数据库可以与微服务一起使用，而不是共享数据库。所以每个微服务都应该有自己的数据库。这也将简化系统的扩展，提供更多的系统可用性，因为“只有”一个真正受影响的服务会失败。

更新:微服务的另一个好处是它可以提高开发的灵 active 和速度。由于正确分解了微服务，因此可以独立开发和部署，并与其他服务并行。

Answer 1

值得一提的是，微服务不必共享相同的模式，通常称为 Integration Database antipattern。 .但实际上，只要每个微服务使用自己的模式，您就可以在同一个关系数据库中使用不同的模式。这里重要的是能够随时轻松地将一些微服务数据移动到不同的物理服务器。部署和备份 1 个数据库要比部署和备份 7 个左右的数据库简单，这意味着如果您刚刚开始项目并且不想花太多时间管理一堆数据库，则此选项是一个不错的选择.但是您和您的团队必须非常自律，以确保微服务只与来自它们自己的模式的数据对话。

另一件事是耦合。你不能让微服务完全隔离，这意味着它们仍然会在一定程度上相互依赖。仅举一个简单的 Product、Order、Shipment 服务的例子。这些服务必须相互了解，无法将它们完全分开。但是您可以通过使用 certain design strategies 使它们暂时分离 .当服务以这种方式解耦时，它们中的每一个都可以在一段时间内不可用(例如重新部署)，而不会影响其他服务。

Due to the more monolithic architecture which goes with shared databases a failure can affect many servers since they are all tied together, even a complete system failure can happen due to the coupling.

即使您的微服务不共享同一个数据库，时间耦合也会产生同样的效果。要遵循的简单规则:不要从一个微服务同步调用另一个微服务，而是使用异步事件和命令。