Ribbon负载均衡
在上一节我们引入Eureka的同时，不知读者朋友们是否还有印象：我们在启动类getRestTemplate方法上追加了注解 @LoadBalanced，为什么加这个注解？这个注解解决了什么问题？本节笔者将给读者们做详尽的讲解。
1.负载均衡
1.1 什么是负载均衡
传统架构下的网站，随着流量的增加，高并发、海量数据的挑战逐步而来。为了提升系统的性能，架构师们往往开始从垂直扩展、水平扩展两个角度来解决问题：
垂直扩展
网站发展的早期可以通过增加服务器的硬件处理能力：CPU、内存、磁盘等方面提升服务器处理的能力，然而单机的瓶颈总是存在的，一旦触及瓶颈想再提升，付出的成本会极高，显然这不符合分布式系统的设计理念。
水平扩展
通过集群部署的方式，将一台服务器的请求压力，分摊到多台机器上，集群中的应用服务器通常被设计成无状态。但是如何将流量均匀分摊到各机器上，或优先分配到高性能机器上又成了一个问题，由此引申出“负载均衡”的概念。
负载均衡（Load Balance）是如今高并发、高可用系统中不可或缺的关键组件，目标是：尽力将用户流量按照架构设计分发(并非一定均匀)到集群中多台服务器上，从而提高系统整体的响应速度和可用性。
1.2 负载均衡分类
硬件负载均衡(包括但不限于)
F5
A10
软件负载均衡(包括但不限于)
Nginx
HAProxy
LVS
1.3 负载均衡算法
为不影响章节重点，需做进一步了解的可移步：负载均衡算法
2.Ribbon如何实现负载均衡
Ribbon与大多数负载均衡实现机制一样在客户端实现（不同于后续我们讲解的Nacos，Nacos在服务端实现），其主要流程为：
在RestTemplate标注@LoadBalanced注解，此时通过RestTemplate发起的RESTful请求都会被负载均衡
当请求发起时，会被LoadBalancedInterceptor拦截，其主要实现两个功能：
从多个可用Server中选择一个Server，选择算法即上述1.3中之一
重构请求URI：服务名-->具体ip、端口
LoadBalancerClient内部持有LoadBalancer并调用getServer方法得到一个Server，而这个Server是通过Eureka服务注册，ILoadBalancer持有的upServerList、allServerList中获取（底层依赖ServerListUpdater动态更新所有serverList）
完整源码交互流程总结如下，感兴趣的可做进一步研究：
3.Ribbon自定义负载均衡策略
1.代码声明式注册
在启动类追加以下代码即可，此优先级更高，但修改必须重启应用，且全局生效
通过查看IRule实现类，可以做其余负载均衡实现方案的更多测试
2.配置文件声明式配置
此配置优点在于不用重启应用，打包发布，但缺点是无法做到全局配置，必须声明规则对应的服务
4.Ribbon饥饿加载
在上述的测试中不知是否有读者发现：当请求第一次到某个实例时，其响应速度明细要慢一点，这里就是因为Ribbon默认采用饥饿加载，只有访问时才会创建LoadBalanceClient，从而导致第一次时间要长点，日志如下：
修改饥饿加载前启动日志
修改饥饿加载前访问日志
修改饥饿加载机制，通过在配置文件中追加以下配置即可
配置饥饿加载
YAML
复制代码
1
2
3
4
ribbon:
eager-load:
enabled: true # 开启饥饿加载
clients: userservice # 指定饥饿加载服务
修改饥饿加载后启动日志
修改饥饿加载后访问日志
至此我们的工程如下，有需自行下载导入：
cloud.zip
(52 KB)
5.总结
上一节就已经实现的负载均衡笔者并未深入探讨，本节通过分析负载均衡算法、Ribbon实现负载均衡的底层原理和实现过程，让大家对负载均衡有了一个大体认识，同时针对Ribbon自定义负载均衡策略，饥饿加载让大家对于Ribbon的了解又多一些。Ribbon实现的负载均衡只是方案之一，我们可以尽量多了解但不要局限于此。
负载均衡作为现如今架构必须考量的一个点，要了解和深入学习的地方还很多，如下一节我们要学习的Nacos是怎么实现的？它为什么反其道而行要在服务端实现？ZK也可作为注册中心它是怎么实现的？网关GateWay也可做负载均衡它又是怎么实现的呢？篇幅问题，更多的答案留给读者朋友们在未来的工作生涯中慢慢思考。
思考问题
Ribbon是什么？解决了什么问题？
Ribbon实现的是客户端，还是服务端负载均衡？
Ribbon如何实现负载均衡？
还有哪些技术点可以实现负载均衡？
负载均衡算法？如何实现？还有哪些技术有体现？
6.推荐阅读资料
了解负载均衡算法：阿里云实操课程链接
掌握Ribbon实现负载均衡原理：本文链接
