一、介绍

上一章咱们简略的说了一下对于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
咱们能够在配置文件中配置策略

<code class="java">service-product: #服务提供者的名称  
    ribbon:
        NFLoadBalancerRuleClassName:com.netflix.loadbalancer.RandomRule  #策略

这样咱们就实现了负载平衡。
前期会在这个我的项目上一直增加，喜爱的请点个start~
我的项目源码参考一下分支220126_xgc_loadBalance
Gitee：https://gitee.com/coderxgc/sp…
GitHub：https://github.com/coderxgc/s…

喜欢 (0)赏

[搞代码]

分享 (0)