选择微服务vs库作为依赖？

Question

我有两个模块（带有DB1的mod1和带有DB2的mod2）作为微服务托管。两个模块都有一些共同的功能，可以与DB1和DB2进行交互。

Approach_1： - 将另一个mod3作为公共组件的共享库jar，并将其注入两个模块，以避免重复代码

方法2： - 为公共组件而不是共享库jar创建另一个微服务。

不确定哪种方法在设计方面更好，我需要考虑哪些标准？

根据我的理解，它应该是一个共享库而不是微服务，因为它将与多个DB交互。如果它是共享jar，那么该模块在逻辑上与业务智能调用模块有关。

Answer 1

如果您有两个微服务都访问相同的两个数据库，并且您正在考虑将公共数据库访问代码分解到库中，那么您至少应该考虑到您实际上只有一个微服务的想法。

想想如果您更改其中一个数据库的架构会发生什么。您必须更新两个微服务才能处理更改。如果你有一个库，你必须更新库，然后构建和发布两个微服务。你通过维护两个微服务而不是一个微服务获得了什么？这似乎更多的工作。

你可能会说，有时候我可能会做一个只影响一个微服务逻辑的改变，然后我可以构建和发布这个服务。这是真的，但如果你有一个微服务，你仍然只是在构建和发布一个微服务。仅仅因为存在一些你没有构建和发布的其他微服务，构建和发布一个微服务并不容易。

Answer 2

如果您具有使用两个不同微服务的DB的通用功能，请执行以下两个步骤：

1. 重新检查有界上下文，即您最初的理解和假设，根据您的设计决策将功能分为两个微服务。也许你需要在那里进行一些重构或者不需要进行重构。
2. 如果您确信您的有界背景是正确的。尝试将常用功能合并到适当的微服务（两种服务之一）中，这样您就可以直接更新本地微服务DB，也可以通过从其他微服务公开的API更新其他微服务DB（这肯定会导致紧密耦合但是可能适合在某些情况下）或使用流媒体，如本answer中所述。

请注意，更新第二个微服务DB的轻微延迟（可能是几秒）可能没有最初可能出现的那么糟糕。 “道歉”在这里发挥着重要作用。许多电子商务网站向客户发送道歉，即使订单成功提交也无法履行订单。从那个角度看，Saga模式可能很有用，如果它不能应用第二个微服务中的变化，它将在第一个微服务中进行补偿事务，因为在流事件到达第二个微服务时业务逻辑不再保持。

简而言之，您提到的两种方法与微服务架构背道而驰