【问题标题】:Microservices waiting on responses from other services微服务等待其他服务的响应
【发布时间】:2017-03-31 10:57:56
【问题描述】:

我最近遇到一个问题,有人问我在以下情况下你会怎么做:

您有服务 A、服务 B 和服务 C 相互交互。服务 A 只有在收到 B 和 C 的响应后才能执行其全部功能。但是,C 有很多请求排队,需要很长时间才能响应。服务 A 将如何处理这种情况?服务 A 会一直等到 C 得到 B 的响应后才响应吗?您将如何让这个架构更快?

【问题讨论】:

  • 答案很大程度上取决于需求和上下文。这里有很多问题要问: 1. A 获得这些请求的速率是多少。 2. 数据的陈旧程度。 3. 万一出现故障怎么办。 4. 我有什么资源。 (例如,我可以创建一个新服务,添加一个兑现层,修改 A/B/C 等)。

标签: soa restful-architecture microservices


【解决方案1】:

我发现这个陈述存在一个根本问题:

服务 A 只有在收到 B 和 C 的响应后才能执行其全部功能

如果您的组件(服务)不是自治的,那么您在初始设计中就会存在严重缺陷。在分解系统时,您希望最终有一个逻辑边界,该边界允许每个“服务”/“组件”自治并明确地拥有它所拥有的系统部分的技术权限。

所以Service A 将完成它的工作并发布一个Service B 订阅的事件并将执行它的位然后B 将发布一个事件C 将订阅一个 ddo 它是业务流程的一部分.

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

实际设计非常依赖于上下文,因此如果没有具体细节就很难分解域。

这有意义吗?

【讨论】:

    【解决方案2】:

    您的 C 服务是您系统的瓶颈。解决方案是:

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

    【讨论】:

      猜你喜欢
      • 2016-03-27
      • 2020-09-27
      • 2019-11-15
      • 2019-11-23
      • 2013-10-25
      • 2015-05-22
      • 2017-07-23
      • 2017-06-28
      • 1970-01-01
      相关资源
      最近更新 更多