我想问一个与建筑有关的问题。这个问题是在一次采访中被问到的，但我无法回答，在网上也找不到任何令人信服的答案。
问题是：- 假设您有 4 个相互通信的微服务，并且数据流是这样工作的：-
微服务 1 --> 微服务 2 --> 微服务 3 --> 微服务 4 --> 微服务 1
现在假设微服务 3 中存在异常，您如何跟踪该异常并告诉微服务 1 这是异常并且它发生在微服务 3 中。
提前致谢！
【问题讨论】：
标签： java architecture microservices
微服务架构的属性之一是分离关注点，这意味着在理想世界中微服务 1 不应该知道微服务 3 的存在。它适用于 M2，唯一重要的是它的响应是否有效。
无论如何，如果您想跟踪通话，可能有多种方法：
当 M3 产生异常时，它会将其发送回 M2，M2 按原样将其传播到 M1（或包装它而不丢失信息）。
另外一个变种是对trace信息有单独的存储，所以M1会生成唯一ID，发给M2，M2发给M3表示是单次请求。然后每个服务使用此 ID 来存储有关执行或任何其他指标的信息（通过调用某些 X 服务）。
【讨论】：
一种常见的方法是 - 将所有异常报告给一个集中的异常跟踪服务，该服务聚合和跟踪异常并通知开发人员。
这种模式的好处是 - 更容易查看异常并跟踪它们的解决方案。
这种模式的缺点是 - 异常跟踪服务是额外的基础设施。
在Careem 中，我们使用ELK stack - 我们使用Logstash，这是一个服务器端数据处理管道，它同时从所有微服务中提取数据，对其进行转换并将其发送到Elasticsearch。 Kibana 让我们通过图表和图形可视化数据，并具有广泛的过滤、搜索等功能。
另外，如果Microservice 1 --> Microservice 2 --> Microservice 3同步的通信方式，你总是可以在Microservice 1中从Microservice 3到Microservice 2生成并接收一些自定义的错误响应。但是要获得异常的整个堆栈跟踪，最好将异常日志汇总到某个集中的位置。
【讨论】：
微服务 1 --> 微服务 2 --> 微服务 3 --> 微服务 4 --> 微服务 1
现在假设微服务 3 中有一个异常，你怎么能 追溯这个异常并告诉微服务 1 这是 异常，它发生在微服务 3 中。
房间里有一头大象；为什么微服务 1 应该关心微服务 2 之外发生的事情？只要微服务 2 保留它是合同的一部分（标准 HTTP 错误代码也是合同的一部分），为什么微服务甚至应该知道微服务 3 的存在。另一方面，如果您对微服务 1 有业务需求应该意识到微服务 3 的错误，那么您可能需要重新审视您的系统架构。
微服务通过网络相互通信，通常使用 HTTP(s)。因此，在微服务的边界，异常将被转换为标准 HTTP 错误代码（对于客户端错误 4XX，对于服务器错误 5XX 等等）和可选的错误消息。当您调用上游服务时，如果响应不成功（HTTP2XX），您的消费者服务只需要查找约定的错误代码/消息并将其转换为有意义的操作（对消费者服务有意义）。
出于调试/跟踪目的，如果您想知道请求跟踪发生了什么，那就另当别论了。正如其他人建议的那样，您可以使用像 ELK 这样的集中式日志记录机制来将日志推送或拉出您的服务，并使用 request Correlation UUID http 标头等来关联不同微服务之间的 http 请求。
【讨论】：
首先，您需要在第一个开始处理的服务时或之前分配一个唯一的请求 ID。
如何为分布式跟踪生成唯一的请求 ID？ 使其成为实例 ID/名称和时间戳的组合。
如果微服务正在同步通信，那么您可以将其作为 http 响应发送。但是，如果微服务通过像 kafka 这样的流进行异步通信，那么您可以使用流来提供回调机制。流可以是请求 id 成为分区键的异常。
【讨论】：