我们有一个微服务架构，我们正在讨论如何向客户端公开内部错误。
这是一个例子：
假设我们有 3 个服务，服务 A、B 和 C。 当客户端向公共服务 A 发送请求时，该服务向服务 B 发送请求，服务 B 向服务 C 发送请求（这是内部的，需要身份验证，但凭据像环境变量一样存储在内部，它们是不是由客户端发送）。
由于某种原因，B 和 C 之间的通信收到 401（可能是 422、403 或任何与客户端相关的错误），这意味着该请求未经授权。
Something like that:
B和C之间的通信是内部的，用户不知道这些服务。我是否应该公开我们的内部结构并向客户端发送 401？既然这不是客户的错？我应该寄500吗？
最好避免显式暴露 500 状态，但在某些情况下这是必要的。用户使用您的系统而不是特定的服务，对他来说，里面有什么并不重要。内部系统实现可能会有所不同，但用户交互可以保持不变。
例如，A 是电子商务服务，B 是计费服务，C 是计费网关。用户通过A购买产品，A向B发送计费请求，B与C通信以执行交易。 B 和 C 之间的 401 可能出于不同的原因。如果只是内部配置问题（未更新密码、过期证书等），则这是内部系统错误，您需要告诉用户服务现在不可用或类似的信息，当然不要传递所有内部错误详细信息。在这种情况下，您可以使用 5xx 代码。也许服务 B 可以将请求放入某种队列并告诉服务 A 一切正常，您的请求将在稍后处理。但如果是因为用户尝试使用不良信用卡或没有足够的钱（未经授权的请求），A 需要显示正确的消息和 4xx 响应代码。
一般来说，服务公开资源，无论其背后有多少内部或外部服务、数据库、数据源等。也许 B 和 C 之间的 401 意味着 B 转到 D 服务（C 备用），而 A 服务根本不应该知道 401。因此，这取决于您需要向用户公开什么以及您需要如何处理不同的情况。
