一、介绍

上一章我们简单的说了一下关于Nacos的使用，这次我们首先做从Nacos获取微服务地址和端口的操作，然后再进行引出负载均衡的问题。

二、我们开始吧

首先我们在订单Controller继续编写

这样就通过了nacos获取商品微服务ip以及端口等信息。
这样看来 我的list中serviceInstanceList.get(0);
获取的是第一个。那么问题来了如果我要想让随机访问到商品微服务ip以及端口上面。
或者我想循环，那么怎么办呢，但是我们如何进行设置呢？
我们首先启动两个端口的商品微服务。

我们可以通过随机数，随机获取一个微服务序号，然后进行调用。

这样也会有一个问题，我们要使用其他的负载均衡条件，一般是实现不了的，那有没有其他的负载均衡的组件呢？
答案肯定是有的，那就是Ribbon。
那我们接下来就是使用这个Ribbon进行对我们的代码优化。
我们打开OrderApplication在restTemplate添加一个负载均衡注解


然后我们打开地址http://localhost:8091//order/prod/1

刷新两次进行日志查看：


我们可以看到两次分别落在了两个端口，这样就实现了我们基本的Ribbon（默认是轮询）负载均衡
当然还有其他的模式例如
RandomRule随机策略：随机选择server
RoundRobinRule轮询策略：轮询选择， 轮询index，选择index对应位置的Server；
RetryRule重试策略：对选定的负载均衡策略机上重试机制，在一个配置时间段内当选择Server不成功，则一直尝试使用subRule的方式选择一个可用的server；
BestAvailableRule最低并发策略：逐个考察server，如果server断路器打开，则忽略，再选择其中并发链接最低的server
AvailabilityFilteringRule可用过滤策略：过滤掉一直失败并被标记为circuit tripped的server，过滤掉那些高并发链接的server（active connections超过配置的阈值）或者使用一个AvailabilityPredicate来包含过滤server的逻辑，其实就就是检查status里记录的各个Server的运行状态；
ResponseTimeWeightedRule响应时间加权重策略：根据server的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间越短，权重越高，被选中的概率越高，这个策略很贴切，综合了各种因素，比如：网络，磁盘，io等，都直接影响响应时间。
ZoneAvoidanceRule区域权重策略：综合判断server所在区域的性能，和server的可用性，轮询选择server并且判断一个AWS Zone的运行性能是否可用，剔除不可用的Zone中的所有server
具体可以查看相关wiki： https://github.com/Netflix/ribbon/wiki
我们可以在配置文件中配置
service-product: #服务提供者的名称
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #策略

这样我们就实现了负载均衡。
后期会在这个项目上不断添加，喜欢的请点个start~
项目源码参考一下分支220127_xgc_loadBalance
Gitee：https://gitee.com/coderxgc/springcloud-alibaba
GitHub：https://github.com/coderxgc/springcloud-alibaba