理解【负载均衡】

理解【负载均衡】：
所谓的【负载均衡】其实就是：让任务/请求能够【均匀】的分配到【服务提供者】身上；
实现【负载均衡】的不同角度：
【软硬件】角度
* 硬件：F5
* 软件：微服务的网关、微服务的Ribbon、Nginx

【端到端】角度
* 客户端负载均衡
* 服务端负载均衡

理解【客户端负载均衡】和【服务端负载均衡】：
服务端负载均衡图解：这里的【负载均衡设备】包括但不限于：代理服务器（Nginx）、微服务的网关（gateway、zuul）、硬件请求分发设备（F5）；
这些【负载均衡设备】的核心就是：负载均衡的算法/策略；
目前是存在开源的负载均衡实现方式的！！！

服务端负载均衡的经典实现方式就是：Nginx实现
即：客户端只知道Nginx的地址，需要调用【后台服务】时，只需要将请求发送给Nginx，之后Nginx就会根据【负载均衡算法/策略】将请求【真实的】发给对应的Service 。

客户端负载均衡图解（客户端负载均衡是相对于“服务端负载均衡”而言的）：
常见的客户端负载均衡实现方式：Ribbon

那【客户端负载均衡】和【服务端负载均衡】最大的区别在那呢？
最大的区别就在：谁能够拿到【可用服务的清单】！
是的，不管用那种方式实现负载均衡，其本质上就是两点：
* 负载均衡的算法
* 可用服务的清单
这两点，少了任何一点都是行不通的！！！

客户端负载均衡：客户端能拿到【可用服务的清单】
服务端负载均衡：服务端能拿到【可用服务的清单】

【可用服务清单】的提供者：服务注册中心

小结：
不管是用那种方式实现负载均衡，他的本质过程都是一样的负载均衡不是一个新概念，也不应该是一个新概念，他的实现方式，早已被【前人】实现了无数次，总之，很简单就是了。

补充：
在真实的项目中，往往存在多级【负载均衡】，也就是说：请求会经历多次【负载均衡算法】，层层【负载转发】，最终才会到达【真实的请求处理的服务上】！