发送作为ELB一部分的实例的http状态代码是不健康的。

Question

根据https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.healthstatus.html，web服务应该使用200 OK HTTP状态代码来响应，以向健康的应用程序或任何其他发出不健康的信号。

我的问题是哪种HTTP状态最适合于不健康的应用程序？

在下面的所有HTTP状态类中

• 1xx Informational response
• 2xx Success
• 3xx Redirection
• 4xx Client errors
• 5xx Server errors

简单的逻辑表明，这应该是一个服务器错误，而在所有的5xx Server errors代码中，503 Service Unavailable最自然地适合，但是我找不到任何支持它的文档。

Answer 1

我的问题是，哪种HTTP状态最适合于不健康的应用程序？

对于服务来说，503服务不可用，或者更低级别的TCP RST是非常令人满意的方式，可以宣布它目前不可用。如果您想建议等待的时间，可以使用重试-之后。我还没有看到任何文件表明ELB客户端会尊重这个标题。

GCP和Azure是相似的；200健康的，其他的都不是。Azure文档将500内部服务器错误作为一种可能的候选，这当然很好(Y00是所有Yxx代码的粗粒度近似)。

领事支票的协议是相似的-- 2xx用于健康，429太多的请求用于警告(这是一个非常奇怪的选择)，而其他的则是失败。

我不太喜欢使用客户端错误来描述什么是服务器问题；但我不知道它真的会伤害什么。Retry-After的语义实际上只对3xx和429/503进行了明确的定义，因此如果您希望利用这些代码，则应该将自己限制在这些代码上。

否则，您可以深入研究状态码注册表，看看是否有您认为更合适的代码。