微服务：检测失败的服务（所有问题的根源）

Question

我想了解如何（以快速/可靠的方式）检测失败的服务，即该服务是所有5xx响应的根源吗？

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

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

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

是的，有断路器，是的，它们被“触发/打开”，并且它们不调用下游服务，而是立即返回错误（在大多数情况下，我们无法像空响应一样返回良好的后备状态）。

因此，我们看到相对大量的微服务返回5xx。就像30-40个微服务返回5xx一样，我们看到30-40个触发/断开的断路器。

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

致谢

Answer 1

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

看看OpenTracing是否满足您的实现需求。它提供了一些库，供您添加用于在分布式环境中识别故障微服务所需的工具。

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