按子域分解（微服务问题）答案

【问题标题】：Decompose by subdomain (Microservice question)按子域分解（微服务问题）
【发布时间】：2021-09-08 02:11:35
【问题描述】：

我发现这个resource 解释了按子域分解，其中一个缺点是“可以创建太多微服务，这使得服务发现和集成变得困难。”

我对这在外行术语中的真正含义有点困惑，所以很高兴听到对相同缺点的不同解释。

提前谢谢你！

【问题讨论】：

【解决方案1】：

第一个问题是假设每个子域都应该由单独的微服务处理。一些子域可以捆绑在一个模块化的单体中——尤其是那些需要快速响应或/和有大量通信的子域。

现在我们明白为什么了：

微服务通过网络进行通信 - 您是否处理所有与此相关的问题 - 超时、无响应、服务无法访问
不可能进行交易。然后，您应该为作为初始操作一部分的每个微服务生成大量事件 - 接受主题、拒绝主题。如果出现问题，应该在每个微服务中恢复每个操作，生成更多要处理的事件:)
当您需要从另一个微服务获取一些数据并且经常这样做时，通过网络进行通信的成本很高，那么应该比单体应用更早地在查询端创建缓存。

基本上通过将网络层添加到您的应用程序不允许您使用事务，而每个微服务可变请求应该仍然是原子的（事务性的）。与单体相比，拥有太多微服务会产生更多复杂的问题。

顺便说一句。如果你不能在一个单体应用中拆分你的域，你会因为添加网络问题而在微服务中失败。

【讨论】：

感谢您的评论，但是，“服务发现问题”仍未得到解答。如果服务发现/注册使用某种模式实现自动化，每个微服务都会响应并将其位置存储在某个表中，为什么拥有更多微服务会成为劣势？
因为你需要处理更多的网络问题而不是一个微服务 - 没有通信问题

【解决方案2】：

这个缺点的核心概念依赖于术语subdomain，它有时可能很难真正理解，主要是因为它位于业务和工程之间的边界。它的一个类似术语是bounded context，this article 给出了很好的解释。

例如，在一个电子商务应用程序中，我们可以有以下子域，这些子域可以很容易地映射到各个微服务：

但是，在一个更复杂的应用程序中，大多数组件都是紧密耦合的（单体），在哪里绘制一些子域之间的边界并不总是那么清楚。您需要业务知识和良好的文档（或者理想情况下，可以访问应用程序的原始作者），才能正确地做到这一点。

因此，您最终可能会创建太多的子域，这可能会转化为太多的微服务（一个子域可以有多个微服务），这有其自身的缺点（我们这里谈论的是数十个微服务甚至更多）。

其中之一是将请求路由到适当的微服务，或者在您接到需要转换为多个下游调用的调用时正确编排调用，例如（在电子商务应用上）：

当然可以缓存一些东西以避免额外的调用，但这只是一个可能的顺序，所以你可以做出一个想法。

【讨论】：

您的示例流程不正确。 1：身份验证微服务不应该是流程的一部分——他的唯一作用是创建身份验证令牌。令牌已签名并具有到期日期，每个微服务都应该有一个私钥来检查令牌是否有效，而无需询问身份验证微服务。 2：搜索应该是请求的唯一接收者（在 API 网关中路由之后） 3：配置文件是保存购物车的错误域名，它不是用户要求的一部分。如果你想显示做一个单独的请求。
@Cosmin，感谢您的详细回答。根据我的理解，真正的缺点是“创建了太多的子域，这可能会转化为太多的微服务”。但除了额外的电话，你没有提到缺点是什么。你介意详细说明一下吗？
@MahirHiro 多个微服务仅涉及您的系统具有多个移动部件，可能具有不同的性能要求或不同的集成协议。跟踪并简单地管理它们是一项具有挑战性的任务。这是拥有多个微服务的主要缺点。让我知道这是否有帮助
@MaciejPyszyński 感谢您指出这一点，您完全正确 - 我在尝试制作示例时有点着急。但是，在我的示例中，我试图强调单个请求可以生成的调用数量，以说明拥有多个微服务的影响。