选择微服务与库作为依赖项？答案

【问题标题】：Select micro services vs library as dependency?选择微服务与库作为依赖项？
【发布时间】：2019-07-06 19:33:07
【问题描述】：

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

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

Approach_2:- 为通用组件创建另一个微服务，而不是共享库 jar。

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

根据我的理解，它应该是一个共享库而不是微服务，因为它将与多个数据库进行交互。如果它是共享 jar，则该模块在逻辑上与调用者模块业务相关。

【问题讨论】：

为什么你认为微服务不能与多个db交互？
另外，我想您了解微服务和库调用之间的延迟差异
或方法 3 使 mod1 和 mod2 成为微服务？
软件设计应根据其满足要求的程度来判断。对您的要求一无所知，我们不能说哪个选项更适合您，但我可以告诉您，集成样式的选择将影响更多领域，不应仅根据您拥有的数据库数量来做出。跨度>
这个 ^... 投票结束，基于意见

标签： design-patterns microservices solid-principles

【解决方案1】：

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

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

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

【讨论】：

【解决方案2】：

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

重新检查有界上下文，即您做出将功能分离到两个微服务中的设计决策所基于的初步理解和假设。也许您需要在那里进行一些重构，也可能不需要。
如果您确信您的有界上下文是正确的。尝试将通用功能合并到适当的微服务（两个服务之一）中，这样您就可以直接更新本地微服务数据库，并通过从另一个微服务公开的 API 更新另一个微服务数据库（这肯定会导致紧密耦合，但在某些情况下可能合适）或使用answer 中解释的流式传输。

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

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

【讨论】：