问题描述
我发现这个 resource 解释了按子域分解，其中的缺点之一是“可以创建太多微服务，这使得服务发现和集成变得困难。”
对于外行人来说，这到底意味着什么，我有点困惑，所以很高兴听到对相同缺点的不同解释。
先谢谢你！
解决方法
此劣势的核心概念依赖于术语 subdomain，有时可能会因模糊而无法真正理解它，主要是因为它位于业务和工程之间的边界上。一个类似的术语是 bounded context，this article 给出了很好的解释。
例如，在电子商务应用程序中，我们可以拥有以下子域，这些子域可以轻松映射到单个微服务：
- 支付子域
- 订单子域
- 身份验证子域
- 搜索子域
但是，在更复杂的应用程序中，其中大多数组件紧密耦合（单体），在某些子域之间绘制边界的位置并不总是那么清楚。您需要具备业务知识和良好的文档（或者理想情况下，可以访问应用程序的原始作者），才能正确地做到这一点。
因为这个原因，你最终可能会创建太多的子域，这可能会转化为太多的微服务（一个子域可以有多个微服务），这有其自身的缺点（我们这里谈论的是数十个微服务甚至更多）。
其中之一是将请求路由到适当的微服务，或者在您接到需要转换为多个下游调用的调用时正确编排调用，例如（在电子商务应用上）：
>- 用户已登录并想要搜索产品（向您的 API 网关发出请求）
- 请求首先路由到
authentication微服务以检查请求中收到的令牌 - 然后，请求被路由到
search微服务以检索实际数据 - 向
profile微服务发起最终请求以获取现有购物车项目，并显示在页面右上角。
当然可以缓存内容以避免额外调用，但这只是一个可能的顺序，因此您可以提出想法。
,第一个问题是假设每个子域都应该由单独的微服务处理。一些子域可以捆绑在一个模块化整体中 - 特别是那些需要快速响应或/和需要大量通信的子域。
现在我们来看看为什么：
- 微服务通过网络进行通信 - 您是否处理过与此相关的所有类型的问题 - 超时、无响应、服务无法访问
- 无法进行交易。然后，您应该生成很多事件 - 作为初始操作的一部分的每个微服务接受主题，拒绝主题。如果出现问题，应在每个微服务中恢复每个操作，生成更多要处理的事件:)
- 当您需要从另一个微服务获取一些数据并且经常执行此操作时，通过网络进行通信的成本会很高，那么应该比在单体应用中更早地在查询端创建缓存。
基本上通过将网络层添加到您的应用程序不允许您使用事务，而每个微服务可变请求应该仍然是原子的（事务性的）。 与单体应用相比，过多的微服务会产生更多复杂的问题。
顺便说一句。如果你不能在一个整体中拆分你的域，你会因为添加网络问题而在微服务中失败更多。