⑴ 服务器负载均衡的几种部署方式
路由模式部署灵活，约60%的用户采用这种方式部署；桥接模式不改变现有的网络架构；服务直接返回（DSR）比较适合吞吐量大特别是内容分发的网络应用。约30%的用户采用这种模式。 1、路由模式（推荐） 路由模式的部署方式如上图。服务器的网关必须设置成负载均衡机的LAN口地址，且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小，能均衡任何下行流量。2、桥接模式 桥接模式配置简单，不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP（WAN口与LAN口是桥连接），所有的服务器与负载均衡均在同一逻辑网络中。 由于这种安装方式容错性差，网络架构缺乏弹性，对广播风暴及其他生成树协议循环相关联的错误敏感，因此一般不推荐这种安装架构。 3、服务直接返回模式 这种安装方式负载均衡的LAN口不使用，WAN口与服务器在同一个网络中，互联网的客户端访问负载均衡的虚IP（VIP），虚IP对应负载均衡机的WAN口，负载均衡根据策略将流量分发到服务器上，服务器直接响应客户端的请求。因此对于客户端而言，响应他的IP不是负载均衡机的虚IP（VIP），而是服务器自身的IP地址。也就是说返回的流量是不经过负载均衡的。
⑵ 《见“微”知“着”系列——<负载均衡>篇》（四）Ribbon + Nacos Client 实现负载均衡
Ribbon是基于客户端的负载均衡器，需主动开启负载均衡功能。本文详细介绍了如何通过Ribbon与Nacos Client结合实现负载均衡。
项目源码完整地址：ribbon-nacos-client-demo子项目。
项目结构如下：ribbon-nacos-client-api模块为公共接口模块，ribbon-nacos-client-provider-demo为服务提供者模块，ribbon-nacos-client-consumer-demo为消费者模块。
POM文件包含了父模块及四个子模块的配置。
Ribbon-nacos-client-api模块核心代码为RibbonNacosService接口，其中getLocalIp方法返回当前服务IP和端口信息，验证负载均衡是否生效。
ribbon-nacos-client-provider-demo模块的application.yml入口类中启用@EnableDiscoveryClient注解，该注解可使服务自动注册至注册中心，服务消费者可通过此中心发现可用服务。
controller提供getLocalIp方法测试接口调用。
ribbon-nacos-client-consumer-demo模块同样配置@EnableDiscoveryClient用于服务发现。
NacosRibbonRuleConfig初始化NacosRule，RestTemplate实例，GlobalNacosClientConfig配置全局负载均衡。
controller提供getLocalIp方法测试负载均衡。
部署3台服务器，每台服务器上部署服务提供者实例，192.168.10.1部署服务消费者实例。Nacos控制台显示服务信息，服务实例权重相同或不同情况下负载均衡效果明显。
通过调整服务实例权重可验证负载均衡算法，所有服务实例权重设为0时，负载均衡失效，服务提供者无可用实例。
分析Nacos负载均衡算法源码，Spring Cloud Alibaba使用NacosRule类定义算法，根据权重随机选择服务实例。具体实现逻辑在getHostByRandomWeight2方法中，使用Balancer类的getHostByRandomWeight方法获取服务实例。
刷新方法refresh将服务实例包装，真正计算权重在Ref类的refresh方法中。randomWithWeight方法源码实现随机选择服务实例。