微服务的其他服务

Question

等待回答，我最近遇到一个问题，当一个人问我，你会在以下情况下做到：

你有服务A，服务B和C业务彼此互动。如果服务A收到来自B和C的响应，它只能执行其全部功能。但是，C有很多请求排队，并且需要很长时间才能响应。服务A将如何处理这种情况？服务A会等待，等到C收到B的回应后再回应？你将如何使这个架构更快？

Answer 1

您的C服务是您系统的瓶颈。解决方案如下：

1. Scale C服务。你应该有一个负载平衡器和更多的C服务节点。
2. 将缓存用于C服务结果。
3. 通过将C逻辑拆分为2个微服务来更改您的体系结构。

Answer 2

有解决这个问题的方法很多，但也许是最简单的一个是这样的：

确保服务A已经从C业务需要在 它需要它时的数据。这样它就不必在 的第一位。

这将要求在过去的某个时候，服务C不得不对其自己的状态发生变化，以便其他服务可以使用这些更改。这种安排促进了服务的自主性，这是一种说服务不依赖于其他服务的当前状态的方式。

实现此目的的常用方法是让服务C在发生内部状态更改时发布事件消息。

Answer 3

我看到一个根本性的问题有这样的说法：如果它收到来自B和C

响应

服务A只能执行其全部功能。如果您的组件（服务）不自主在初始设计中你有一个严重的缺陷。分解系统时，您希望最终形成一个逻辑边界，允许每个“服务”/“组件”自治并明确指定它拥有的系统部分的技术权限。

所以Service A将做的工作并公布事件Service B订阅并会做它的位，然后B将发布一个事件，C将认购的DDO它是业务流程的一部分。

如果他们可以并行完成工作，那么创建者（发送带有数据的初始命令的客户端）可以直接将命令发送给每个组件，并且您可能有一个组件通过订阅事件来跟踪业务流程状态该组件将在完成其工作单元时发布。

实际的设计是非常依赖于上下文的，所以如果没有特定的细节就很难分解域。

这有道理吗？