我们目前有一个简单的 3 服务器设置：
- 云 NGinx/Apache Web 服务器（NGinx 提供静态服务，动态代理至 Apache/PHP 后端）
- 专用数据库服务器
- 云端外发邮件+监控服务器
我们正处于需要扩展/扩展 Web 服务器的阶段。我们希望实现以下目标：
- 如果 Web 服务器发生故障，尽量减少停机时间
- 在高峰时段提供额外容量
- 允许我们在不关闭网站的情况下升级一个网络节点
- 也允许 SSL 服务
我想添加一个额外的 Web 节点，其容量与原始节点相同，而不是将现有 Web 节点的容量加倍，因为这将为我们提供一个故障转移/镜像节点（负载平衡时）以提高容量并提供冗余。
我深入研究了这些选项，目前 HAProxy 似乎是不可能的，因为我想处理 SSL（并且不想在负载均衡器处终止，所有 SSL 流量都必须端到端加密）。
我的选择似乎是：
答：在两个 Web 节点前面的自己的节点上添加软件负载平衡器（例如 Nginx）。这里的问题是，当用户上传 UGC 时，它将无法在另一个节点上使用。使用粘性会话时，这个问题就不那么严重了，但最终我们需要同步上传的内容，否则节点将不同步。可以使用 Rsync，但由于我们正在查看主主 Web 配置，因此需要双向……很棘手！
B：与上文相同，但使用负载均衡器来提供静态内容。这样就可以减轻 Web 节点的部分处理负担。我们可以将所有上传从 Web 节点 rsync 到负载均衡节点，这样就只是从 Web 到负载均衡器的单向 rsync。任何非静态请求都会被负载均衡到 Web 节点。这样可以将所有静态内容放在一个地方，但我的目标是拥有一个小型的负载均衡节点，而这最终可能会变得非常大？
c：与 A 类似，但使用 NGinx 将任何可能上传的访问者流量（这很容易细分）导向一个“主”服务器进行上传，并在其他节点之间公平地平衡“只读”流量的负载。这使得同步变得简单，因为它是单向的（主 Web 节点->从属 Web 节点），允许我们更好地利用 Web 节点上的磁盘空间，并使静态内容远离负载平衡器。然而，这意味着如果主节点发生故障，我们需要手动将“上传”区域的流量切换到剩余的服务器（nginx 可能能够进行此切换，我们只是对上传区域进行了不同的负载平衡配置）
B 似乎是一个不错的配置，我可能会将负载平衡器节点与我们现有的电子邮件/监控服务器结合起来，因为它处于空闲状态。负载平衡节点有一个单点故障，但在紧急情况下，我们可以启动一个新的云实例来替换它。但是我不喜欢静态图像只在一个节点上的想法，因为我们没有固有的备份。我也喜欢 C 的想法，因为它意味着它保持非常简单。如果负载平衡器发生故障，我们可以将流量直接引导到其中一个 Web 节点而不会出现任何问题（因为它们都具有一整套静态文件）。
任何关于上述解决方案的意见都将不胜感激
答案1
我会选择 B，因为你说出的优点是正确且令人信服的。
当您拥有两台 Web 服务器时，您已经必须解决在多台机器上保持内容同步的问题；添加第三台服务器是微不足道的，因此将静态内容从任何来源同步到负载均衡器的成本很容易。
一般来说，磁盘空间非常便宜 - 而且如果您大幅增长，您可能还是想将静态内容推送到 CDN（例如：S3、Akami），因此让负载平衡知道它在哪里并适当地引导客户端是一个合理的中间步骤。
鉴于两个主节点之间同步内容的问题是难的在大多数情况下，我会先将所有上传流量导向一台机器，然后对其他服务器进行只读复制。这样可以减少更改，并且在负载平衡器安装到位、运行和测试后，您可以在主/主模型上工作。