【问题标题】:Microservices: detecting a failed service ( root of all problems )微服务:检测失败的服务(所有问题的根源)
【发布时间】:2019-12-24 14:28:39
【问题描述】:

我想了解如何检测失败的服务(以快速/可靠的方式),即服务是所有 5xx 响应的根?

让我尝试详细说明。假设我们有 300 多个微服务,它们仅通过 GET 请求进行同步 http 交互,没有任何数据修改(为了简单起见,我们假设它)。每个客户请求可能会转换为调用约 10 个不同的微服务,而且它可能是请求的“调用链”,即 API 网关调用 3 个不同的微服务,每个微服务调用 1-5 个,这 1-5 个中的每个调用 1-还有5个等等。

我们密切监控每个微服务上的 5xx 错误并对这些错误做出反应。

现在其中一个微服务失败了。它似乎位于“调用链”的末端,这意味着依赖它的其他微服务也将开始返回 5xx。

是的,有断路器,是的,它们被“触发/打开”,而不是调用下游服务,它们也会立即返回错误(在大多数情况下,我们无法像空响应一样返回良好的回退)。

所以我们看到相对大量的微服务返回 5xx。就像 30-40 个微服务返回 5xx,我们看到 30-40 个触发/打开的断路器。

如何快速检测失败的微服务,万恶之源? 有人遇到过这个问题吗?

问候

【问题讨论】:

  • 您可以在起点(客户端请求)创建 request-id,将日志写入 elk 堆栈(或类似物),然后抓取结果,例如,给定 request-id 的第一个异常。

标签: microservices


【解决方案1】:

您将需要实施一个分布式跟踪解决方案,该解决方案使用全局 ID 跟踪原始事务。此全局标识符的名称通常称为 Correlation ID,它由创建请求的第一个服务生成并传播到协同工作以完成请求的所有其他微服务。

查看OpenTracing 以满足您的实施需求。它为您提供库以添加在分布式环境中识别故障微服务所需的工具。

但是,如果您确实有 300 个微服务都使用同步调用...也许是时候考虑使用异步通信来消除同步通信中固有的时间耦合了。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2017-12-31
    • 2021-07-02
    • 2017-04-27
    • 2021-06-05
    • 2020-10-14
    • 2014-03-06
    • 2021-12-18
    相关资源
    最近更新 更多