我有一个 Python Elastic Beanstalk 负载均衡应用程序。以下是用户请求进入 Elastic Beanstalk 应用程序所采用的路径：
user -> Elastic Beanstalk ELB -> Elastic Beanstalk mod_wsgi
问题：
user新应用程序版本之后的前 2-4 个请求eb deploy将会从 ELB 生成 504 错误。
在这 2-4 个生成 504 的请求之后，一切都正常！总共 200 个。
Elastic Beanstalk mod_wsgi当出现 504 错误时，根据 ，没有请求能够到达应用程序/var/httpd/access_log。在 ELB 决定重新开始工作后，我才看到 200 错误。
我尝试过但没有效果的方法：
- 我将
Elastic Beanstalk ELB空闲超时增加到 300 秒 - 我按照这里的建议将
Elastic Beanstalk mod_wsgiapache增加到 300 秒：KeepAliveTimeouthttp://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/ts-elb-error-message.html
有人可能会说，“只要使用 504 就行了！”
但是，实际问题是，在我的生产设置中，我有和CloudFlare之间的文件。CloudFlare 设置为积极缓存和文件，因为我将 md5 哈希附加到静态文件 URL。当对这些重要文件的请求失败并出现 504 错误时，CloudFlare 似乎将这些失败缓存为 404。对这些文件的进一步请求将出现 404 错误，从而破坏了每次部署时网站的视觉样式。userElastic Beanstalk ELB.css.js
部署 Elastic Beanstalk 应用程序再次使用相同版本的应用程序将解决 CloudFlare 404 问题。这不是一个好的解决方案。我想继续使用 CloudFlare，因为它是一个出色的透明 CDN，所以摆脱它也不是一个解决方案。
很难相信只有我一个人遇到这个问题，但 Google、stackoverflow/serverfault 和 AWS 论坛都没有找到任何解决方案，甚至没有类似的问题报告。我希望我对此行为的描述能引起这里的某些人的注意。提前致谢。
答案1
我遇到了完全相同的问题，我确实认为这是 Beanstalk 部署程序的一个错误。
我使用的是“滚动”部署策略，其中有 2 个实例，批处理大小为 1，理论上应该不会出现停机时间。但实际上，在部署期间，ELB 仍然会以 504 响应约 10 - 15 秒的时间。
查看 beanstalk 配置中的“更新和部署”设置。我发现更改为“使用附加批次滚动”并使用 100% 的批次大小效果很好，并且在更新期间不会出现停机时间。
2018 年 10 月更新- 我不知道它已经工作了多长时间，但 Elastic Beanstalk 滚动更新现在又可以正常工作了，对我来说没有任何停机时间。
答案2
其他人遇到过这种情况吗？我发现，如果您没有正确配置“健康检查”端点，也可能会出现此问题。只有当 EB 从健康检查端点获得“健康”回复时，EB 才会将服务器轮换到负载平衡状态，默认情况下，我认为这只是检查您的服务器（对于 Web 应用程序，则为 nginx/apache/其他）是否响应，而不是您的应用程序是否已正确启动。
在我的例子中，实际的 Web 服务器在我的 Flask 应用程序完全启动之前就已经响应，导致服务器在准备就绪之前就被轮换。我在 Flask 应用程序中添加了一个端点，它只返回 200 和一个虚拟 JSON 主体，并将 EB 指向该端点作为健康检查。从那时起一切都很顺利。