Question

当我们想要将一个复杂的内部网络架构暴露给公共网络（如 Internet ）时，使用反向代理几乎是必需的。它有助于隐藏复杂性，提供外部应用程序可轻松使用和依赖的单一访问点。但是，如果我们需要扩展仅供内部使用的服务，则我们可以拥有更多的灵活性和控制力。

假设有一个服务 A 依靠服务 B 来实现其功能。服务 B 在多台机器上进行缩放，并且只能在内部网络中使用。我们迄今为止所了解到的是，服务 A 将使用反向代理连接到服务 B，反向代理会将流量分发到实施服务 B 的所有服务器。

但是，还有一个选择。我们可以从图中删除反向代理，并直接从客户端（服务 A）分发请求，该客户端现在直接负责跨服务 B 的各种实例负载平衡其连接。只有服务器 A 知道详细信息关于暴露服务 B 的服务器，并且在内部网络中，这通常是已知信息。通过这种方法，我们基本上实现了对等负载均衡。

下图比较了我们刚刚描述的两种替代方案：

这是一种非常简单而有效的模式，可以实现真正的分布式通信，而不会出现瓶颈或单点故障。除此之外，它还执行以下操作：

• 通过删除网络节点来降低基础设施的复杂性
• 更快的通信，因为消息将通过更少的节点
• 规模更好，因为性能不受负载平衡器可以处理的限制

另一方面，通过删除反向代理，我们实际上暴露了其底层基础架构的复杂性。此外，通过实施负载平衡算法，每个客户端都必须变得更加智能，并且可能也是保持其基础架构最新的一种方式。

点对点负载均衡是 ØMQ 库中广泛使用的一种模式。

实现可以跨多台服务器平衡请求的 HTTP 客户端