背景：我的Java 7 Elastic Beanstalk应用程序运行良好。它通常只使用一个实例，但如果CPU负载达到70%，就会启动另一个实例；如果负载低于20%，就会关闭它，最多允许两个实例。可以有相当多的用法，因此从一个开始，在需要时最多使用两个在财务上是有意义的。唯一的问题是，在部署时，它必须从S3下载5GB索引文件并将其解压缩，这意味着总部署时间为30分钟。但我认为AWS知道应用程序仍在部署，在正确部署之前不会开始向其发送请求，我有以下配置的扩展
option_settings:
- namespace: aws:elasticbeanstalk:command
option_name: Timeout
value: 1800
最近我部署了一个新版本的应用程序，我注意到AWS有一个新的健康检查监控，可以监控HttpCodes。我认为当应用程序的新实例仍在部署中时，它会返回错误，并导致
实例已连续至少失败UnhealthyThreshold数量的运行状况检查
所以我的服务器出现故障，但我不确定，健康检查是否会导致问题，我该如何检查？
目前的解决方案是部署到更快的实例，但这意味着我现在为不需要的容量付费，所以从长远来看，这在财务上不是一个可行的解决方案。
新的AWS Elastic Beanstalk健康检查正式称为"增强型"健康检查，它收集来自各种来源的数据，并为您提供健康状态和颜色，以及环境和所有实例指定健康的原因。来源包括来自EC2实例、ELB健康检查、ELB、SQS等的cloudwatch度量的数据。
如果您在原因中看到"Instance has failed least the UnhealthyThreshold number of health checks."，则表示该实例未通过负载平衡器健康检查。此处记录了ELB发出此消息的可能原因。为了澄清，如果负载平衡器运行状况检查失败，ELB将不会向您的实例发送流量。这是负载平衡器的行为，无论您是否使用增强的运行状况报告系统。增强健康只是将ELB的这些信息表面化到豆茎健康原因/事件中。如果您的环境中有一个实例，并且进行部署需要30分钟，那么在部署期间，您的环境可能不会为任何流量提供服务。
你能为你的负载均衡器提供健康检查配置吗？您可以在beanstall配置页面的负载平衡面板中找到运行状况检查，如下所示。
如果您的应用程序中有一个可靠的健康检查URL，以通知ELB您的实例已准备好提供流量，那么您应该使用该URL进行健康检查，而不是默认的TCP:80检查。您还可以通过查看AWS管理控制台上的"运行状况"窗格来查看实例在部署期间是否接收流量。
但需要重申的是，如果您只有一个实例，并且部署需要很长时间，那么在此期间，您的环境将无法用于客户流量。对于某些用例来说，这可能没问题。如果没有，则建议您使用至少2个实例和批量大小<实例数。
即使你有一个更快的实例，从S3下载大文件并处理它需要5分钟，那么在这5分钟内，如果你的负载均衡器的健康检查没有通过，你的实例将无法为客户流量提供服务。
下载5 GB文件是运行应用程序的先决条件吗？您是否有必要将此文件作为应用程序部署的一部分下载，或者您是否也可以将其作为应用程序中后台线程的一部分进行下载？如果在更新期间下载文件并不重要，那么您可以进行非常快速的部署，并且您的实例将立即准备好提供流量。
消息"实例已连续失败至少UnhealthyThreshold健康检查次数"只是告诉您ELB认为您的实例不健康(基于您的健康检查配置)，因此没有接收到任何流量。
当你说"所以我的服务器出现故障"时，你的意思是环境的健康状况类似于严重/红色吗？如果是这种情况，那么是的，在负载平衡器后面有一个实例，部署需要30分钟以上，预计在部署过程中，该实例将不会像负载平衡器那样健康。同样，如果您认为您的实例甚至在部署完成之前就可以提供流量(长轮询是从S3下载的)，那么您应该考虑将下载从S3转移到后台线程，这样您的应用程序在更短的时间内不健康，并将停机时间降到最低。
如果你需要进一步澄清，请告诉我。