design-patterns - 选择微服务与库作为依赖项？
问题描述
我有两个作为微服务托管的模块（带有 DB1 的 mod1 和带有 DB2 的 mod2）。这两个模块都有一些共同的功能，可以与 DB1 和 DB2 交互。
Approach_1：- 将另一个 mod3 作为公共组件的共享库 jar 并将其注入两个模块以避免重复代码
Approach_2：- 为公共组件创建另一个微服务，而不是共享库 jar。
不确定哪种方法在设计方面更好，我需要在这里考虑哪些标准？
根据我的理解，它应该是一个共享库而不是微服务，因为它将与多个数据库进行交互。如果它是共享 jar，则该模块在逻辑上与调用者模块业务有关。
解决方案
如果您有两个访问相同的两个数据库的微服务，并且您正在考虑将公共数据库访问代码分解到一个库中，那么您至少应该考虑您实际上只有一个微服务的想法。
想想如果您更改其中一个数据库的架构会发生什么。您必须更新这两个微服务才能处理更改。如果您有一个库，则必须更新该库，然后构建和发布这两个微服务。通过维护两个微服务而不是一个微服务，您获得了什么？这似乎是更多的工作。
你可能会说，有时候我可能会做出一个只影响一个微服务逻辑的更改，然后我可以构建和发布那个服务。没错，但如果你有一个微服务，你仍然只是在构建和发布一个微服务。仅仅因为存在一些您没有构建和发布的微服务，就构建和发布一个微服务并不容易。