500错误和微服务架构答案

【问题标题】：500 error and microservices architecture500错误和微服务架构
【发布时间】：2017-08-03 12:46:13
【问题描述】：

我有两个微服务“前端”和“/用户”。它们与 REST API 通信当客户端向“前端”发出请求时，它会在内部请求“/users”微服务。

当 /users 回答 500-error 时，应该返回什么样的状态码？

【问题讨论】：

内部服务器错误？也许 503 - 服务不可用？
可能，但是前端服务没有内部错误
但是...如果您的微服务失败并且您的前端仍然可用 - 您不认为它应该显示一个很好的消息来解释您的服务遇到问题吗？
错误应该描述发生了什么。 500 适合这里，因为内部存在错误，即无法与依赖项通信，错误描述可以告诉您
@kharandziuk 您看到返回到“前端”服务的响应是什么？它只是一个 UI 还是一个向其他 Web 服务发出请求的服务器？

标签： rest microservices

【解决方案1】：

500 内部错误在这里很好：https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#5xx_server_errors

如果您不知道在这种情况下该怎么做（如果您的服务在没有底层服务的情况下无法工作），则 500 专门用于此。

【讨论】：

【解决方案2】：

嗯，这取决于！ 微服务应该遵守它的Bounded Context，并且应该独立于其他服务并松散耦合。摘自 Chris Richardson 的Microservices 网站：

微服务 - 也称为微服务架构 - 是一种将应用程序构建为服务集合的架构风格。

高度可维护和可测试

松散耦合

可独立部署

围绕业务能力组织

由一个小团队拥有

在您的上下文中，您应该尝试回答当底层通信用户服务失败时前端服务的有界上下文的预期结果是什么（不仅仅是 500，也可能是其他失败）。你还能回复有意义的回复吗？您返回半水合数据是否可以接受（例如，在没有来自用户服务的数据不可用的情况下返回数据，假设前端服务也从自身聚合了一些数据）。如果是，那么您可能应该处理来自用户服务的 500 响应并返回带有 2xx 响应的半水合数据（取决于请求的目的）。如果答案是否定的，那么最好也从前端服务中冒泡 5xx 错误，就像 answered above 和 Eugene 一样。

【讨论】：