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