回顾
上一遍总结了注册中心的作用,咱们继续总结一下ribbon的作用。
什么是Robbin
Ribbon是一个客户端负载均衡器,可以让您对HTTP和TCP客户端的行为进行大量控制,功能如下:
- 负载均衡
- 容错
- 异步和反应模型中的多协议(HTTP,TCP,UDP)支持
- 缓存和批处理
![30d400b0d12d6495aef618a38a14d44c.png](https://img-blog.csdnimg.cn/img_convert/30d400b0d12d6495aef618a38a14d44c.png)
Robbin有什么用
先回顾一下之前的业务,之前只有一家外卖。
![7f3c01120de852c4dc2b80460c088660.png](https://img-blog.csdnimg.cn/img_convert/7f3c01120de852c4dc2b80460c088660.png)
现在有两家外卖
![c2b89509f758aa5640449fec9a302ed1.png](https://img-blog.csdnimg.cn/img_convert/c2b89509f758aa5640449fec9a302ed1.png)
现在你的问题就来了,现在这么多选择,我到底该选哪一家呢?此时如果你有选择恐惧症的话,正好。请个秘书,这种点餐的小事情就交给他做了。这个秘书常见的点餐手法就是轮询,一家一家挨着来点,雨露均沾就是这个意思。
启动两个user-service实例
一个8081,一个8082
![db315de3199150c5bc063e127c95bf27.png](https://img-blog.csdnimg.cn/img_convert/db315de3199150c5bc063e127c95bf27.png)
eureka监控面板
![915bcb29d7d2ebaccf14abe96520d7ed.png](https://img-blog.csdnimg.cn/img_convert/915bcb29d7d2ebaccf14abe96520d7ed.png)
配置user-consumer的负载均衡
无需单独添加依赖,因为在eureka中已经依赖了。
在RestTemplate bean上加上@LoadBalanced注解就ok
![951164f4e55d2efa1500a2b628fb5b20.png](https://img-blog.csdnimg.cn/img_convert/951164f4e55d2efa1500a2b628fb5b20.png)
修改UserDao,不再手动获取ip和端口,而是直接通过在eureka中注册的服务名称调用:此处为USER-SERVICE
![087a3262d09e00cd29bdf655c4cff523.png](https://img-blog.csdnimg.cn/img_convert/087a3262d09e00cd29bdf655c4cff523.png)
重启user-consumer,访问http://localhost:8080/consume?id=1
![85f7a1c66a9525be4ed1651f387e4f46.png](https://img-blog.csdnimg.cn/img_convert/85f7a1c66a9525be4ed1651f387e4f46.png)
以上就已经开启了user-consumer负载均衡,真的是超级简单。
测试负载均衡策略
![d32ace54a1bee263794e6d63bc278d6e.png](https://img-blog.csdnimg.cn/img_convert/d32ace54a1bee263794e6d63bc278d6e.png)
打印结果:
![5f8786462166aee042da7e01a507a6a3.png](https://img-blog.csdnimg.cn/img_convert/5f8786462166aee042da7e01a507a6a3.png)
以上结论得出,确实是轮询机制。一个一个的来。
修改负载均衡策略
将策略改成随机
![26d3d05e229988df4a95c71913b640a4.png](https://img-blog.csdnimg.cn/img_convert/26d3d05e229988df4a95c71913b640a4.png)
再次运行结果
![d7ea4e1d7bf6500a0d4696823f82934e.png](https://img-blog.csdnimg.cn/img_convert/d7ea4e1d7bf6500a0d4696823f82934e.png)
关掉一个user-service服务测试
访问第一次,发现报错了。
![7cec14b38bf9c9499d07cd3427014c5e.png](https://img-blog.csdnimg.cn/img_convert/7cec14b38bf9c9499d07cd3427014c5e.png)
说明ribbon正好随机到刚才关闭的实例。这种情况明显不是我们想看到的,能不能达到这种效果:ribbon自动判断该实例服务是否可用,如果不可用的话,自动去访问另一个实例,如果还不可用,继续去连另一个。
ribbon当然有这种重试功能,作为一个秘书,这点能力是必须的。
开启ribbon重试功能
加入retry依赖
![e764f8c69ef545959839b791b11167b3.png](https://img-blog.csdnimg.cn/img_convert/e764f8c69ef545959839b791b11167b3.png)
加入日志依赖
![e77feec29b21d108aa7640dfa967f0a5.png](https://img-blog.csdnimg.cn/img_convert/e77feec29b21d108aa7640dfa967f0a5.png)
配置application.yml
![ce710e36134a90df6d6247ac323bfed0.png](https://img-blog.csdnimg.cn/img_convert/ce710e36134a90df6d6247ac323bfed0.png)
关掉一个user-service,测试
![5e56a6e0f7fa990a7c4e6e328cc45deb.png](https://img-blog.csdnimg.cn/img_convert/5e56a6e0f7fa990a7c4e6e328cc45deb.png)
打印的重试次数=1。并没有报错。这样一来就可以保证另一台挂了,也不影响其它实例的正常使用。
总结
Ribbon是一个客户端的负载均衡器,用于保证客户端调用集群服务的高可用性。