我拥有并经营visualwebsiteoptimizer.com/。该应用提供了一个代码片段，我的客户将其插入到他们的网站中以跟踪某些指标。由于代码片段是外部 JavaScript（位于网站代码的顶部），在显示客户网站之前，访问者的浏览器会联系我们的应用服务器。如果我们的应用服务器出现故障，浏览器将继续尝试建立连接，直到超时（通常为 60 秒）。您可以想象，在任何情况下我们都不能承受应用服务器出现故障，因为这不仅会对我们的网站访问者产生负面影响，还会对我们客户的网站访问者的体验产生负面影响！
我们目前正在使用 DNS 故障转移机制，其中一个备份服务器位于不同的数据中心（实际上是不同的大陆）。也就是说，我们从 3 个不同的位置监控我们的应用服务器，一旦检测到它发生故障，我们就更改 A 记录以指向备份服务器 IP。这对大多数浏览器来说都很好（因为我们的 TTL 是 2 分钟），但 IE 会将 DNS 缓存 30 分钟，这可能是一个交易杀手。请参阅我们最近的这篇文章visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/
那么，如果应用数据中心发生严重故障，我们可以使用什么样的设置来确保几乎立即进行故障转移？我在这里读到www.tenereillo.com/GSLBPageOfShame.htm拥有多个 A 记录是一种解决方案，但我们无法承受会话同步（目前）。我们正在探索的另一个策略是拥有两个 A 记录，一个指向应用服务器，另一个指向反向代理（位于不同的数据中心），如果主应用服务器启动，则解析为主应用服务器，如果备份服务器启动，则解析为备份服务器。您认为这种策略合理吗？
为了确保我们的优先事项，我们可以承受自己的网站或应用程序停机，但我们不能让客户的网站因为我们的停机而变慢。因此，如果我们的应用服务器停机，我们不打算使用默认的应用程序响应来响应。即使是空白响应也足够了，我们只需要浏览器完成该 HTTP 连接（而不是其他任何事情）。
参考：我读过这个很有用的帖子serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure
答案1
你的情况和我们的很相似。我们想要分离数据中心和网络层类型的故障转移。
如果您有足够的预算，那么您需要的是两个数据中心，每个数据中心有多个 IP 中转，一对边缘路由器与您的中转提供商进行 BGP 会话，将您的 IP 地址宣传到全球互联网。
这是实现真正故障转移的唯一方法。当路由器注意到通往您服务器的路由不再有效时（您可以通过多种方式做到这一点），它们就会停止通告该路由，流量将流向另一个站点。
问题是，对于一对边缘路由器，您最初需要花费相当高的成本才能完成设置。
然后，您需要设置所有这些背后的网络，并且您可能需要考虑在站点之间建立某种第 2 层连接作为点对点链接，以便在主站点发生部分故障时，您能够将传入一个数据中心的流量直接路由到另一个数据中心。
BGP 多宿主/多位置最佳实践和提高恢复力的最佳方法是什么？是我问过的有关类似问题的问题。
GSLB 的耻辱页面确实提出了一些重要的观点，这就是为什么我个人永远不会愿意选择 GSLB 来完成 BGP 路由工作。
您还应该查看网络中的其他故障点。确保所有服务器都有 2 个 NIC（连接到 2 个独立的交换机）、2 个 PSU，并且您的服务由多个后端服务器组成，作为冗余对或负载平衡集群。
基本上，通过多个 A 记录实现的 DNS“负载平衡”只是“负载共享”，因为 DNS 服务器不知道每台服务器上的负载是多少。这很便宜（免费）。
GSLB 服务对服务器的负载情况及其可用性有一定的概念，并提供了更强的抗故障能力，但仍然受到与 DNS 缓存和挂钩相关的问题的困扰。这不太便宜，但略胜一筹。
在我看来，BGP 路由网络加上坚实的基础设施是真正保证良好正常运行时间的唯一方法。使用路由服务器而不是 Cisco/Juniper/等路由器可以节省一些钱，但归根结底，您确实需要非常小心地管理这些服务器。这绝不是一个便宜的选择，也不是可以轻而易举的事情，但它是一个非常有益的解决方案，让您以提供商的身份进入互联网，而不仅仅是消费者。
答案2
好的，这个问题之前就被问过了，但是我现在才第一次看到。
代码片段是外部 JavaScript（位于站点代码的顶部），在显示客户网站之前，访问者的浏览器会联系我们的应用服务器。
你应该：
- 将您的 Javascript 文件放在优质、专业的内容交付网络上，即从已经具备该专业知识的人员那里购买高可用性 HTTP(S) Javascript 服务。
- 对您的 Javascript 进行编程，以便有一个良好的后备状态，即，如果您的应用服务器没有快速响应，那么最终用户会看到一个正常的、未修改的页面。
做其他任何事情都是不负责任的，真的。我想你已经这样做了。
你应该不是除非您拥有或获得了相关知识，否则不要将您的服务建立在 BGP 路由技巧上。复杂的 BGP 路由方案的实现绝对不是一件容易的事；如果您不具备特定领域的知识，请不要自己这样做。
你的问题本身就有点混乱。如何创建高可用性服务的分析始于应用程序数据，因为这是你的“状态”。无状态部分很容易实现高可用性，而全状态部分则不然。因此，不要专注于你的服务器和 DNS，而是要关注你的应用程序维护状态。从那里开始优化，并可能在 Stack Overflow 上寻求算法建议。您可以在 Javascript 文件 fx 中实现事务和智能服务器重试的概念吗？
答案3
实际上，如果您结合使用 geodns 和 dns 故障转移，您想要的内容也可以升级以帮助您进行拆分测试活动。
将 A 组发送到 ip 1，将 B 组发送到 ip 2，即使它们位于同一服务器上，也可以让您区分测试组。A 组和 B 组来自不同的地理区域。公平起见，第二天/下一周/下个月，您可以翻转组以确保考虑地理差异。只是为了严格遵守您的方法。
geodns/failover dns 服务位于http://edgedirector.com可以做到这一点
披露：我与上述链接有关联，偶然发现这里正在研究一篇关于应用愚蠢的 DNS 技巧进行分割测试的文章。