我正在设计一个托管在云端的网站/网络服务（特别是AWS，虽然这几乎是无关紧要的），而且我花了很多时间考虑“设计失败”。我希望我的系统能够无缝地处理节点故障，即没有任何重大的用户影响或工程师干预。
在大多数情况下，很容易看到如何处理突然的节点故障。如果我的应用程序有一个由负载均衡器后面的4个服务器处理的API，由AJAX或iPhone应用程序轮询，则轮询器可以简单地检测失败的TCP / IP传输并重试...假设负载均衡器行为正常，它将达到健康的实例。
如果应用程序更加面向处理，则可以使用SQS之类的队列服务来允许无状态节点获取故障节点停止的位置。
我看到的难点在于“入口点”，其中没有重试/轮询是可能的，因为应用程序尚未加载，并且失败意味着应用程序永远不会启动。例如，网页上的index.html ...如果节点在传输该文件时失败，用户的浏览器可能会挂起而不会自动重试（他们需要刷新）。
Load Balancer也是一个“进入/失败点”。但是，在这种情况下，我们可以通过创建多个负载均衡器来解决问题，并使用DNS负载均衡负载平衡它们，如下所述：http://blog.rightscale.com/2012/10/23/dns-load-balancing-and-using-multiple-load-balancers-in-the-cloud/
这是一个适用于更简单的index.html案例的解决方案吗？总的来说，如何在无法进行轮询/重试/排队的情况下创建冗余？
编辑：另一个想法是让index.html静态托管在CDN，S3等上（资源可用性更可靠），尽管这会阻止使用动态内容。如果页面使用JS填充自身，则可以添加动态内容，但这会增加对JS的依赖性以及用户的延迟。