通过微服务传播错误的良好做法 [英] Good practices to propagate errors through micro services

问题描述

我们有一个微服务架构，我们正在讨论如何向客户端公开内部错误.

We have a micro services architecture and we are having some discussions about how to expose internal errors to the client.

这是一个例子:

假设我们有 3 个服务，服务 A、B 和 C.当客户端向公共服务 A 发送请求时，该服务向服务 B 发送请求，该服务向服务 C 发送请求(这是内部的，需要身份验证，但凭据像环境变量一样在内部存储，它们是不是由客户端发送).

Let's suppose we have 3 services, service A, B and C. When the client sends a request to the service A, which is public, this service sends a request to service B that sends a request to service C (which are internal and needs authentication, but the credentials are stored internally like environment variables, they are not send by the client).

由于某种原因，B 和 C 之间的通信收到 401(可能是 422、403 或任何与客户端相关的错误)，这意味着该请求未经授权.

And for some reason the communication between B and C receives a 401 (could be 422, 403 or any client related errors), which means that the request was not authorized.

类似的东西:

B 和 C 之间的通信是内部的，用户不知道这些服务.我应该公开我们的内部结构向客户端发送 401 吗?鉴于这不是客户的错?我应该发送 500 吗?

The communication between B and C is internal, the user don't know about these services. Should I expose our internal structure sending a 401 to the client? Given it's not the client's fault? Should I send a 500?

推荐答案

最好避免显式暴露 500 状态，但在某些情况下这是必要的.用户使用你的系统而不是特定的服务，对他来说里面是什么并不重要.内部系统实现可能会有所不同，但用户交互可以保持不变.

It's better to avoid exposing 500 status explicitly but in some cases it's necessary. A user works with your system not with particular service and for him it doesn't matter what is inside. Internal system implementation can vary but user interaction can stay the same.

让我们 A 将例如电子商务服务，B - 计费服务和 C - 计费网关.用户通过 A 购买产品，A 向 B 发送计费请求，B 与 C 通信以执行交易.B 和 C 之间的 401 可能出于不同的原因.如果只是内部配置问题(未更新密码、过期证书等)，则是内部系统错误，您需要告诉用户服务现在不可用或类似的事情，当然不要传递所有内部错误详细信息.在这种情况下，您可以使用 5xx 代码.也许服务 B 可以将请求放入某种队列并告诉服务 A 一切正常，您的请求将在稍后处理.但如果是因为用户尝试使用不良信用卡或没有足够的钱(未授权请求)A 需要显示正确的消息和 4xx 响应代码.

Let's A will be for instance a e-commerce service, B - billing service and C - billing gateway. User buys a product via A which send billing request to B and B communicates with C to perform transaction. 401 between B and C can be for different reasons. If it is simply internal configuration problem (not updated password, expired certificate and so on) it is an internal system bug and you need to tell user that service is unavailable now or something like that, not to pass all internal error details of course. You can use 5xx code in this case. Perhaps service B can put request to some kind of queue and tell service A that's everything is OK, your request will be processed later. But if it is because of user tries to use bad credit card or don't have enough money (not authorized request) A needs to show the proper message and 4xx response code.

一般来说，服务公开资源，它背后有多少内部或外部服务、数据库、数据源等并不重要.也许 B 和 C 之间的 401 意味着 B 转到 D 服务(C 替代)，而 A 服务根本不应该知道 401.因此，这取决于您需要向用户公开什么以及您需要如何处理不同的情况.

In general a service exposes resources and it doesn't matter how many internal or external services, databases, data sources and so on are behind it. Perhaps 401 between B and C means for B to go to D service (C alternate) and A service shouldn't know about 401 at all. So, it depends on what you need to expose to user and how you need to handle different cases.

这篇关于通过微服务传播错误的良好做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！