3.2 网络负载均衡功能的实现

网络负载均衡功能的实现，可基于负载均衡器，也可基于“名字服务+客户端策略”。下面对这两种实现方式进行说明和对比。

3.2.1 机制说明

1.基于负载均衡器的方式

所有的网络流量都先发送给负载均衡器，再由负载均衡器转发给下游的服务实例，如图3.2所示。在这种方式下，负载均衡的功能都由负载均衡器来完成。

2.基于“名字服务+客户端策略”的方式

客户端通过 DNS（或其他名字服务）获得服务实例的地址列表，然后客户端把网络流量直接发送给服务实例，如图3.3所示。在这种方式下，负载均衡的功能都由客户端和名字服务配合完成。名字服务在返回服务实例地址列表时，有一定的策略；客户端在获得服务实例的地址列表后，在发送网络流量时也可以有一定的策略。

图3.2 基于负载均衡器的方式

图3.3 基于“名字服务+客户端策略”的方式

3.2.2 两种方式对比

表3.1对以上两种方式进行了对比。

（1）基于负载均衡器的方式适用于对流量控制要求比较高的场景，可以实现单个连接/请求粒度的精细转发控制，而且这种方式对客户端的要求很低，客户端不需要实现任何策略，也不涉及客户端 SDK（Software Development Kit，软件开发工具包）的引入。这种方式的弊端是需要在负载均衡器方面投入额外的资源，在使用时需要计算所需要的资源成本。

（2）基于“名字服务+客户端策略”的方式的好处是不需要额外的资源消耗，从客户端直接访问服务。但是这种方式的执行效果强依赖于客户端的配合，在客户端上要实现较复杂的策略，通常要引入客户端 SDK，从而带来了客户端升级的成本。对很多公司来说，客户端软件的种类很多，分属不同的团队，要做到及时升级是很困难的。另外，这种方式的执行粒度比较粗，客户端和名字服务之间的交互不可能过于频繁，秒级的交互频率已经是很高了，即使这样也不可能做到单个连接/请求粒度的控制。

在某些场景下，无法使用负载均衡器，而只能使用“名字服务+客户端策略”的方式，如在“外网调度场景”下，就只能使用 DNS的方式。

表3.1 两种方式对比