我看过很多关于 SO 的旧文章。所以我再问一次。截至 2012 年 4 月,EC2 中的 Elastic Load Balancing (ELB) 有多好。EC2 服务器的 ELB 替代方案是什么。优缺点都有什么。
EBL 也是一把可以自行完成所有操作的魔法剑,即我不需要对我的应用程序进行任何更改
PS:我对所有这些都是新手
我看过很多关于 SO 的旧文章。所以我再问一次。截至 2012 年 4 月,EC2 中的 Elastic Load Balancing (ELB) 有多好。EC2 服务器的 ELB 替代方案是什么。优缺点都有什么。
EBL 也是一把可以自行完成所有操作的魔法剑,即我不需要对我的应用程序进行任何更改
PS:我对所有这些都是新手
我在 ELB 上遇到的最大问题是每个请求有 60 秒的硬性限制。如果您的用例需要任何连接持续超过 60 秒,ELB 将不适合您。附录:如果您的连接可以进行某种“保活”流量,那么 ELB 不会杀死它。对于一般的、长时间运行的 HTTP 响应,60 秒就可以了。
另一个问题是,如果 ELB 未能通过您在不健康阈值中设置的健康检查次数,ELB 会立即终止与实例的所有连接,因此如果不将不健康阈值保持在高于最长运行进程的水平,则在 apache 中进行优雅停止之类的事情是很困难的,或超过 60 秒,这两者似乎都是一生,具体取决于您的应用程序和预期的响应能力。
编辑:ELB 现在支持连接耗尽:http ://aws.amazon.com/about-aws/whats-new/2014/03/20/elastic-load-balancing-supports-connection-draining/
另一个常见错误是忘记将实例的可用区添加到 ELB 或错误配置运行状况检查。
从管理的角度来看,ELB 非常好,但肯定仍然缺少一些不错的功能。在 ELB 上终止 SSL 可能是最大的“杀手级功能”,相比之下,所有缺点都变得微不足道和不重要。
Elastic Load Balancing 可以检测 Amazon EC2 实例的运行状况。这是一个非常好的功能。我们将 ELB 与 Auto Scaling 结合使用,效果非常好。此外,ELB 会根据您的负载自动扩展。我们从来没有遇到过 ELB 的问题。阅读此内容可能对您有用