追溯微服务架构中的异常

Question

我想问一个与架构有关的问题。这个问题是在采访中问我的，但我无法回答，也无法在网上找到任何令人信服的答案。

问题是：- 假设您有四个相互通信的微服务，数据流的工作方式如下：-

微服务1->微服务2->微服务3->微服务4->微服务1

现在假设微服务3中有一个异常，您如何跟踪该异常并告诉微服务1这是异常，它是从微服务3中发生的。

谢谢！

Answer 1

微服务体系结构的特性之一是将关注点分开，这意味着在理想的世界中，微服务1不应意识到微服务3的存在。它可以与M2一起使用，而仅重要的是-来自它的响应是否有效。

无论如何，如果您想跟踪呼叫，可能有多种方法：

M3生成异常时，会将其发送回M2，M2将其按原样传播到M1（或包装它而不丢失信息）。

另一种变体是具有单独的跟踪信息存储空间，因此M1将生成唯一的ID，该ID被发送到M2，M2将其发送到M3以表明它是单个请求。然后，每个服务都使用此ID来存储有关执行或任何其他指标的信息（通过调用某些X服务）。

Answer 2

一种常见的方法是-将所有异常报告给集中式异常跟踪服务，该服务汇总并跟踪异常并通知开发人员。

此模式的好处是-可以更轻松地查看异常并跟踪其解决方案。

此模式的缺点是-异常跟踪服务是附加的基础结构。

在Careem中，我们使用ELK stack-我们使用Logstash，它是服务器端数据处理管道，它同时从所有微服务中提取数据，并将其转换并发送到{{3 }}。 Elasticsearch使我们能够使用具有广泛过滤，搜索等功能的图表和图形来可视化数据。

此外，如果Microservice 1 --> Microservice 2 --> Microservice 3的通信方式是同步的，则您随时可以在Microservice 1中从Microservice 3到Microservice 2生成并接收一些自定义的错误响应。但是要获取整个异常的堆栈跟踪信息，最好将异常日志汇总到某个集中的位置。

Answer 3

首先，您需要在开始处理的第一个服务之前或之前分配一个唯一的请求ID。

如何为分布式跟踪生成唯一的请求ID？ 使其结合实例ID /名称和时间戳。

如果微服务正在同步通信，则可以将其作为http响应发送。但是，如果微服务通过像kafka这样的流异步通信，那么您可以使用流来提供回调机制。该流可能是例外，请求ID成为分区键。

Answer 4

  

微服务1->微服务2->微服务3->微服务   4->微服务1

     

现在假设微服务3中有一个异常，您怎么可能   追溯此异常并告诉微服务1这是   异常，它是由微服务3引起的。

房间里有一头大象。为什么Microservice1应该关心Microservice 2之外的情况？只要Microservice 2保留了合同的一部分（标准HTTP错误代码也是合同的一部分），为什么Microservice甚至应该知道Microservice 3的存在。另一方面，如果您对Microservice 1有业务需求应该知道Microservice 3的错误，那么您可能需要重新访问系统架构。

微服务通过网络相互通信，通常使用HTTP。因此，在微服务的边界处，异常将转换为标准HTTP错误代码（对于客户端错误4XX，对于服务器错误5XX等）和可选的错误消息。当您调用上游服务时，如果响应不成功（HTTP2XX），则您的消费者服务只需要查找关于错误代码/消息的约定并转换为有意义的操作（对消费者服务有意义）。

出于调试/跟踪的目的，如果 YOU 想知道请求跟踪发生了什么，那就是另一回事了。就像其他建议一样，您可以使用集中式日志记录机制（例如ELK）将日志从服务中推送或拉出，并具有请求Correlation UUID http标头，以便在不同的微服务之间关联http请求。