一、介绍

上一章咱们简略的说了一下对于 Nacos 的应用，这次咱们首先做从 Nacos 获取微服务地址和端口的操作，而后再进行引出负载平衡的问题。

二、咱们开始吧

首先咱们在订单 Controller 持续编写

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

咱们能够通过随机数，随机获取一个微服务序号，而后进行调用。

这样也会有一个问题，咱们要应用其余的负载平衡条件，个别是实现不了的，那有没有其余的负载平衡的组件呢？
答案必定是有的，那就是 Ribbon。
那咱们接下来就是应用这个 Ribbon 进行对咱们的代码优化。
咱们关上 OrderApplication 在 restTemplate 增加一个负载平衡注解


而后咱们关上地址 http://localhost:8091//order/…

刷新两次进行日志查看：


咱们能够看到两次别离落在了两个端口，这样就实现了咱们根本的 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~
我的项目源码参考一下分支 220126_xgc_loadBalance
Gitee：https://gitee.com/coderxgc/sp…
GitHub：https://github.com/coderxgc/s…