我正在尝试使用以下场景实现一些分散的负载平衡和资源管理：
每个服务器定期（例如每分钟或 30 秒）发送 UDP 广播或多播，以让附近的其他服务器知道它提供的服务及其运行状况或负载（例如 cpu % 或内存使用情况，或网络流量等）。
具有可用于帮助过载服务器的资源的服务器可以为其广播/多播添加额外的服务，从而减少过载服务器的负载。
UDP 流量的额外开销会降低已经繁忙的网络中的性能吗？减少冗余和更集中的方法会更好吗？
我打算将其用于不只是传统的负载平衡（例如在必要时启动新的云服务器）。
另一种变化是仅在达到某个负载阈值时才广播/多播。
任何建议或其他选项/建议将不胜感激，特别是关于对底层网络和相关设备等的影响。
具有服务器当前使用级别的小型 UDP 数据包不会导致网络瘫痪，即使是已经很忙的网络。TCP 在这方面做得更好，因为丢失的数据包会导致重传，从而产生更多的流量，但即便如此，这也不会成为问题，原因有几个。
首先，您的客户端流量可能通过与您的服务器用于相互通信的网络不同的网络到达。如果您愿意，您可能会决定创建一个心跳 LAN。
即使所有流量都驻留在同一个网络上，客户端流量也会受到您的 WAN 容量的限制，而您的 WAN 容量总是小于您的 LAN 容量。这意味着您将拥有备用的 LAN 容量（除非有其他东西将流量引入您的本地网络）。
我认为在分散模型中进行负载平衡很有趣，但会带来许多挑战，事实上是否可能，更不用说可取取决于您尝试负载平衡的应用程序......
我假设您知道正常的负载平衡是如何工作的。在没有首先了解它所取代的东西的情况下尝试这样做意味着你真的会很挣扎。
因此，作为第一步，关键是拥有一个可以将其客户端发送到另一台服务器的应用程序。您描述的广播将允许服务器知道是否有其他服务器也可以重定向客户端，如果满足某些阈值。
正如您所说，如果服务器真的受到重创，它可能无法处理它接收到的数据包。在理想状态下，服务器会在达到该限制之前将工作转移到另一台服务器，但是您可以选择，您是否希望服务器在连接被 100% 使用之前开始拒绝连接？不利的一面是，您永远不会充分利用您的硬件，并且您可能会达到所有服务器都拒绝用户的地步，而您仍然有 cpu 周期可供使用。请记住，即使使用 IaaS，如亚马逊的 AWS，也有一个启动时间，用户请求的突然增长并不少见。
您将面临的另一大挑战是容错。
首先，如果服务器与实时客户端断开连接，他们会联系谁，他们正在与之交谈的最后一个服务器（假设有一个）？如果客户端离开该服务器的原因是因为它超载了怎么办？也许他可以用一个非常轻量级的“给我一个新资源”请求去他的旧服务器。如果旧服务器的负载下降，它可以指定自己，如果没有，它可以将其推送给其他人。但请记住，虽然这一切都在发生，但用户并没有得到他们想要的服务。
容错的第二个方面是保持其他服务器的健康状态准确。您说您希望您的服务器广播或多播它们的健康状态，有多少丢失的数据包构成服务器停机？网络一直在丢弃数据包，这就是它们的工作方式，但是如果您将客户端推送到 duff 服务器，只会让该客户端请求超时并再次返回给您，这对客户端来说是糟糕的服务。如果客户端和服务器在同一个 LAN 上，您不会受到太大影响，但是您将在 Internet 上获得的那种延迟添加到客户端/服务器通信中，您的用户可能很快就会感到厌烦。
您必须克服的下一个问题是，仅仅因为服务器正在发送它的状态，并不意味着应用程序运行正常。使用集中式 SLB，对每台服务器运行测试请求，检查所有应用程序是否正常运行，如果不正常，则将服务器从池中取出。我认为您不希望每台服务器都在测试其他每台服务器的运行状况。这会消耗你的大量资源。我通常不相信服务器会提供它自己的健康状态，但我认为如果你想完成这项工作，你必须在某种程度上做到这一点。但是，缺点是您正在消耗资源来运行查询，回答它们然后检查结果。这些都是可以服务用户请求的周期。
我能想到的最后一个问题是初次接触。如果您使用 DNS 循环，您必须确保这些地址上的服务器是健康的。您不希望用户在开始之前必须等待超时。我不确定将地址列表或 DNS 主机名写入您的客户端是否会有很大帮助。客户仍然会一直按照列表的顺序工作，而不是按照他们的目标行事。
仔细考虑这一切很有趣，我希望它有所帮助。但是我要问的问题是，你想通过分散负载平衡来实现什么？我提出的所有问题可能都有解决方案，但是在不知道您的目标的情况下，很难说是否没有更简单的解决方案。
不过，希望这会有所帮助，亚历克斯