1、介绍上一章我们简单的讲了Nacos的使用。这次我们会先从Nacos获取微服务地址和端口，然后再进行导致负载均衡的问题。2.让我们开始吧。首先我们继续在ordercontroller中写入，这样我们就可以通过nacos获取产品微服务ip和端口信息了。似乎serviceInstanceList.get(0);在我的列表中是第一个。那么问题来了，如果我要随机获取商品微服务ip和端口。或者我想循环，那怎么办，但是我们怎么设置呢？我们首先用两个端口启动商品微服务。我们可以通过一个随机数随机获取一个微服务序列号，然后调用它。这种方式也会有问题。我们需要使用其他的负载均衡条件，一般是无法实现的。还有其他负载均衡组件吗？答案是肯定的，那就是Ribbon。那么我们下一步就是利用这个Ribbon来优化我们的代码。我们打开OrderApplication，给restTemplate添加一个负载均衡注解，然后我们打开地址http://localhost:8091//order/...刷新两次查看日志：可以看到两个端口分别落在了两个端口上，所以它实现了我们基本的Ribbon（默认是轮询）负载均衡。当然还有其他模式如：RandomRule随机策略：随机选择serverRoundRobinRule轮询策略：轮询选择，轮询索引，选择索引对应的服务器；RetryRule重试策略：对于选择的负载均衡策略机器重试机制，如果在配置的时间段内Server选择失败，会一直尝试使用subRule选择一个可用的服务器；BestAvailableRule最小并发策略：一台一台检查服务器，如果服务器断路器开启，则忽略它，然后选择并发连接数最低的serverAvailabilityFilteringRule可用过滤策略：过滤掉已经出现故障并标记为电路跳闸的服务器，并过滤掉那些高并发连接的服务器（活跃连接数超过配置的阈值）或者使用一个AvailabilityPredicate来包含过滤服务器的逻辑。其实就是查看status中记录的各个server的运行状态；ResponseTimeWeightedRule响应时间加权策略：根据服务器的响应时间分配权重。响应时间越长，权重越低。被选中的概率也较低。响应时间越短，权重越高，被选中的概率越高。这个策略很合适，综合了各种因素，比如：网络，磁盘，io等，直接影响响应时间。ZoneAvoidanceRule区域权重策略：综合判断服务器所在区域的性能和服务器的可用性，轮询选择服务器并判断一个AWSZone的运行性能是否可用，剔除所有不可用Zone的服务器.具体可以参考相关wiki：https://github.com/Netflix/ribbon/wiki我们可以在配置文件中配置策略service-product：#Serviceprovidernameribbon:NFLoadBalancerRuleClassName:com.netflix.loadbalancer。RandomRule#Strategy这样我们就实现了负载均衡。后面会继续补充这个项目，喜欢的请点start~项目源码参考分支220126_xgc_loadBalanceGitee:https://gitee.com/coderxgc/sp...GitHub:https://github.com/coderxgc/s...
