我在 AWS Elastic Beanstalk 上运行一个应用程序。如果某个实例过于频繁地响应 500（服务器错误）范围内的 HTTP 状态代码，AWS 会将此实例标记为运行状况不佳并从负载均衡器中删除该实例。
我理解这一点，也同意这实际上是一种好的行为。但不幸的是，这导致我的应用程序出现问题。
我的应用程序需要连接到多个外部 API 并汇总它们的数据。其中一个外部 API（不受我控制）不稳定，经常以 500 状态代码响应。
目前，如果 API 引发错误，我的应用程序只会将该错误返回给用户。这导致 AWS 认为我的应用程序出现错误，因此终止该实例并启动新服务器。但实际上，只有一个端点导致恒定的 500 错误率，而所有其他端点仍然正常。
一方面，外部服务器错误导致我的应用程序仅返回该错误是正确的。另一方面，这种外部服务器错误是不我的应用程序，我可以捕获它。但即使我捕获了错误，我也无法向用户返回任何有用的信息，因此仍然需要返回错误代码。
如何处理？避免使用服务器错误状态代码，以免触发不健康的实例，但同时不使用客户端错误状态代码，因为用户无能为力，他们只需要重试？
您有什么建议？或者还有其他选项可以微调 AWS Elastic Beanstalks 行为？
答案1
那么问题主要是：当对该 API 的请求失败时，您的应用程序工作流程是否要求您的客户/用户
a) 收到通知
b) 需要采取后续行动
c) HTTP 错误响应是否是通知他们的唯一方式？
如果是这样：那么请考虑当远程 API 生成 500 内部服务器错误时让您的应用程序返回 408 错误响应，这在某种程度上是合适的，因为它允许客户端稍后重新提交相同的请求。（如果没有以下限制，“502 Bad Gateway”会更好：）
此外，您还可以配置先进的健康规则在 Elastic Beanstalk 中，您可以指示 elastic beanstalk 忽略 4xx 错误，因为这些错误表明健康状况不佳。遗憾的是，在撰写本文时，您无法对 5xx 或更具体的 http 状态代码执行相同操作。