我正在为我的公司项目寻找选项和解决方案，我们可以在多台服务器上托管我们的网站，并且可以使用负载平衡。主要问题是，当我更新网站时，我需要重新启动服务器。我们的 Web 项目是用 Djanog/Python 编写的，每次推送更新时都需要重新启动 uWSGI。目前，我们在单台服务器上运行我们的网站，当客户端使用该应用程序时很难更新/重新启动。我一直在互联网上寻找解决方案，并在 DigitalOcean 的网站上找到了一篇好文章。您可以阅读更多相关信息这里。
我们还希望将数据库从同一应用服务器分离出来，在特定机器上使用，并设置主从复制。所以我的问题是，例如，我们的网站 example.com 在 Web 服务器/ip 101 和 102 上运行。这两个网站都连接到数据库 ip 201。所以现在，当我在服务器 101 上推送更新并重新启动应用程序时，我希望 102 处理所有请求而不抛出任何错误或任何东西。101 更新后，我希望它重新启动并在我更新服务器 102 时处理所有请求。我也将对数据库进行相同的设置，因此 201 和 202 作为主服务器，一个正在更新，另一个启动。
我们当前的服务器运行的是 Ubuntu 和 Nginx，MySQL 为 Django 应用程序提供服务。我可能不熟悉行业术语，所以我在解释问题。我不是在谈论像谷歌、微软或 Facebook 这样的公司，因为我知道他们有针对此类问题的定制解决方案，但有人可以指导我寻找术语或任何解释、文章、帖子或教程，我可以阅读这些来处理这个解决方案吗？
谢谢
答案1
有两种主要方法可以关闭服务器
- 您可以将服务器从 Nginx 负载均衡器中取出并重新加载配置
- 您可以依靠健康检查来停止向不可用的服务器发送流量。信息在这里。
您可能需要对数据库稍微小心一点。
- 是主从吗？如果是，当主服务器宕机时，您无法进行更新
- 您会在两个数据库之间进行复制吗？这会导致一致性问题吗？您需要粘性会话吗？
- 一个数据库是否专用于一个 Web 服务器？这会使更新更容易，但复制更困难。
- 如果您更新一个数据库上的数据库模式，然后将其恢复，那么这与复制如何协同工作？
- 您可以使用蓝/绿环境吗？即，将一个 Web/数据库服务器更新为新应用程序版本，然后向其发送越来越多的流量百分比。这仅适用于无状态 Web 服务器。
我可能会使用 Nginx 进行健康检查，使用故障转移代码、数据库复制和蓝/绿部署来感知两个数据库的应用服务器。一定要对故障场景进行良好的测试。
在 AWS 中你只需使用：
- 弹性负载均衡器
- 两个无状态 Web 服务器
- AWS 关系数据库服务。这会保留一个主数据库和一个同步备份。但是，它无法解决数据库架构更新的问题。蓝绿策略会有所帮助。
更新
数据库应与应用/Web 服务器位于同一位置，以减少延迟。如果您愿意，可以将整个环境迁移到云服务，但您需要了解环境，而不是冒险并希望获得最佳结果。
关于数据库主/从设置，我可能不是合适的建议人选。您必须考虑多主、主/从和无主的环境。然后要考虑 NoSQL，在某些情况下，它可能很合适。
我可能会考虑主/从模式，即两个应用服务器都查看一个数据库，另一个保持最新状态。当您想要更新架构时（希望这种情况很少见），您可以停止复制，更新从服务器，然后将新版本的应用程序指向旧从服务器，即新主服务器。在云中，您可能只需为每个部署构建新环境 - 服务器就像牛，而不是宠物。
答案2
在一台服务器仍在服务的情况下更新另一台服务器的方法称为“蓝绿部署”。您可以在 Martin Fowler 博客中阅读有关它的信息：https://martinfowler.com/bliki/BlueGreenDeployment.html
假设你有 web1 和 web2 服务器
您需要采取的步骤是：
- 从 nginx 负载均衡器中删除/禁用 web1，这样你的客户就只能访问 web2
- 使用新代码更新您的 web2 服务器，然后重新启动 web2 服务器。在 web2 中测试应用程序，确保它提供最新代码
- 在 nginx 负载均衡器中添加/启用 web2。现在您的客户有 50% 的机会获得新网站或旧网站。
- 对 web1 服务器重复步骤 1-3
- 现在您的客户只会获得新网站
我对数据库不太熟悉，但如果您使用主从模式进行数据库设置，则可以将网站配置为维护模式，该模式只能读取数据，而不能从从属服务器写入数据。更新主服务器后，更改应用程序中的变量以指向主服务器，并启用读/写