我一直很好奇大规模实时 Web 应用程序更新是如何完成的。由于应用程序是实时的，因此一切都变得复杂 - 您不应停止服务，同时应在稍后更新期间将网站上的活动/更改（在数据库等中）恢复到新版本。
首先想到的最自然的技术就是将所有请求重定向到其他复制的服务器，这样您就可以在不关闭服务的情况下更新原始服务器。
我只是想知道是否有其他更智能的技术来处理实时 Web 服务中的更新。请分享你们的经验和意见！
答案1
您是否在单台服务器上加载网站？如果不是，我假设您有某种负载平衡器。如果您确实在单台服务器上加载，请扩展并安装负载平衡器。
拥有这样的服务不仅可以让您获得高度可用性，而且如果您需要处理您的应用程序，您可以禁用其中一台服务器接受到外界的流量，然后在流量不太繁忙的时段升级/测试您的应用程序/网站。
我将我的网站和应用程序（其实是同一件事）加载到 15 台服务器上，并将一些用作“抱歉服务器”，如果我的主服务器很忙，我可以加载到“抱歉”服务器。在这种情况下，我可以处理备用服务器并对其进行升级，然后当我对一切运行感到满意时，我会慢慢地一次从池中取出一个服务器并对其进行处理。
使用 Cacti (www.cacti.net) 之类的工具监控您的网站/网络流量，可以让您根据流量了解您的繁忙时间，然后在繁忙时段之外进行更新。
希望这能给你带来一些启发。
答案2
我们通常使用“滚动升级”来解决这个问题。这意味着您不再只有一台服务器来处理所有负载，而是有 N 台服务器。例如，您可以通过简单地停止 Apache Web 服务器来“停止轮换服务器”。我们需要另一种机制来从 Apache 的角度保持服务器正常运行，但要阻止它接收传入的客户连接。我们使用一个简单的文本文件来实现这一点，该文件的存在会指示我们的负载均衡器将此服务器的权重标记为 0。
为了实现负载平衡，我们使用开源 Linux 虚拟服务器 (LVS)：http://www.linuxvirtualserver.org
它支持“realserver”健康检查。我们定期运行此健康检查，以维护负载平衡器后面的活动 Web 服务器列表。
通过标记要升级的主机、一次升级单个服务器、向其发送测试流量、确认其正常运行，然后将其重新添加到池中，我们能够有效地将升级滚动到实时服务。
答案3
当我们谈论在线模式更改时，在 DB 层上执行起来比较困难......但是也有一些解决方案，例如 MySQL 空间中的 Tungsten Cluster，试图解决这个问题。