我针对以下问题提出了自己的解决方案，并请网络和服务器管理专业人员验证它或找出其中的漏洞。我对您可能看到的任何明显的攻击媒介或可扩展性问题都很感兴趣。谢谢！
要求：
- HTTPS 支持，由每个应用服务器独立处理
- 近线性水平可扩展性
- 带宽分布在服务器上（响应数据并非全部通过 LB 或代理返回）
- 类似于应用程序服务器和负载平衡器的故障转移
- 客户端与服务器之间的亲和性
- Linux 友好（解决方案非闭源）
- 引导友好！（即初始成本低）
方案：
PUBLIC NETWORK
+-----+------+--------+-----+------->
| | | |
v v v v
+---+ +---+ +--+ +--+
|LB1| |LB2| ... |S1| |S2| ...
+---+ +---+ +--+ +--+
冗余负载平衡器（LB*，通过类似 DNS RR 的方式，或者只是故障转移）：它们的唯一目的是向客户端提供某个应用服务器实例的 URI，然后客户端将永久使用该 URI 来处理其请求。最初，分配将是随机的或循环的。
每个应用服务器实例（S*）都独立地直接处理来自客户端的请求。
无状态架构允许单个服务器停机。如果客户端指定的服务器发生故障，客户端会向负载平衡器请求新的服务器。
新的应用服务器可以快速启动、注册到负载均衡器并分配给客户端。所有 S* 都会有一个子域 DNS 条目来共享通配符证书。
简单的实现可以完全在一台没有冗余的服务器上完成，并根据需要委托扩展职责。
当前关注的问题
防火墙和 DDoS 保护必须在每台服务器上进行管理，而不是像负载平衡反向代理那样集中管理。集中配置管理是我目前为止想到的。
此方案不会像 Anycast DNS 那样利用地理位置或服务器响应时间。这是为提高服务器亲和性而做出的有意识的权衡，并且可能会在以后强行加入。
答案1
从高层次来看，这个方案似乎是合理的，但仍然存在一些缺陷。
- 解释一下如果服务器宕机，客户端如何知道恢复。（我认为这是最大的问题）
- 解释一下您的负载均衡器如何仅提供 URI。这些只是 Web 服务器吗？
- 您如何处理状态数据（例如，可能传递来自前一个服务器的隐式数据的会话 cookie）。否则，您使用普通 cookie？
- 如何向负载均衡器注册？
- 在这个设计中，存储如何工作？如何扩展？
- 在这个方案中，负载平衡器如何真正平衡负载？由于它提供的只是引荐，因此它无法知道服务器端的会话何时结束。
- 负载均衡器如何知道服务器是否宕机？