通过微服务传播错误的良好实践 [英] 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发送请求，服务B向服务C发送请求(服务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购买产品，该产品向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屋！