我知道如何扩展我的软件，但是如何防止因networking中断而导致的停机？

假设我正确地理解了您的问题，那么如果主要因任何原因而停机，您希望让客户故障转移到辅助数据中心。 一个可以处理这个问题的产品是f5 Networks的BIG-IP全球stream量pipe理器 。 从本质上讲，当检测到中断来开始将客户redirect到次要networking时，它将立即更新你的DNS。

另一个select可能是使用Anycast之类的东西将路由广播到您的数据中心。

为了补充这个问题，我们确实在多个数据中心进行操作，最后决定最好的方法是让工程师根据中断原因手动将DNS指针移动到备用configuration。 最糟糕的情况是，如果一个数据中心完全脱机，我们可能会减less1小时。 但是，当我们必须切换数据中心时，这是与客户的影响相比的（最近的活动在备用位置不可用）。

最后一个select是不依赖于您的数据中心提供给您的IP连接和带宽。 取而代之的是与全球通信服务提供商（如Global Crossing或Level 3）交谈，让他们处理将入站stream量路由到任一数据中心。 风险在于您正在与单个提供商合作，但其好处是可以在其路由选项中更加灵活（您可以在其networking中使用MPLS来进行后端复制，并且也可以使用相同的连接进行公开IM连接）。

本质上，有2种技术可供select（我知道）：

• 正如OP指出的那样，通过更新DNS故障切换到另一个DC，以便logging指向可操作数据中心中的地址。
• IP Anycast ，也就是DNS发布IP地址，这个IP地址在任何数据中心都可以使用，并且可以在客户的路由器上select最近的数据中心。 请注意，如果一个数据中心发生故障，那么客户离这个数据中心最近的这个数据中心将会短暂中断，直到BGP路由重新调整为止。

因为当服务器closures时切换DNS似乎太慢，除非TTL = 0

您可以将TTL设置为零，但不要期望所有networking都遵守您的设置。 实际上，大约10分钟是TTL的最低值。 当然，这意味着基于DNS的故障转移对于每个客户来说将需要0到10分钟，具体取决于您的caching中的TTL。

降低1000个请求将会很好，但更多是不好的，不应该发生。

据我所知，这仅仅是在今天技术上可行的范围之外。 即使是最大的网站使用基于DNS或任播的技术，并努力保持他们的数据中心接近100％的正常运行时间，因为在全球互联网级别无法实现即时故障切换。

在局域网内部，您可以使用像VMWare VMotion这样的function来切换速度非常快，但这是在您自己的端到端受控局域网上。

我认为 ，全球负载平衡是不切实际的，除了拥有大量技术专长的最大的站点：

• 许多负载均衡设备都将地理位置分布作为要点，但是如果整个数据中心发生故障，您的负载均衡器也是如此？ （ 编辑：我只是重新阅读DLux的答案 ，我想我现在明白了……你得到两个负载均衡器，每个DC都放一个负载均衡器，他们之间build立了一个心跳线，当直streamDC中的LB注意到其在死亡DC中的同事已经脱网，那么现场LB更新DNS以便于故障切换。）
• 使用Anycast是我个人不会尝试的技术 – 技术存在并且可操作，但是如果存在奇怪的，罕见的路由问题呢？ 对networking问题进行故障排除是非常困难的，因为“对BGP优化”应该留给真正的专家。
• 所以剩下的就是基于DNS的故障转移，最好使用全球复制的DNS提供商，提供水平分割DNS作为服务。 这将工作，部署相当简单。 但是，它并不符合近乎即时故障切换的OP目标。

免责声明，我想从一个真正的专家谁input全球冗余系统许多次之前input/更正:-)

您也可以查看内容分发networking（例如，Akamai）。 卸载静态内容并将dynamic内容caching到CDN可以显着减less群集上的负载。

特别是Akamai 非常昂贵，但还有其他更便宜的替代品。