负载均衡的概念：是指单台服务器性能达到极限时通过服务器集群来横向增加系统的吞吐量和性能。
想象一下，一群学生去食堂打饭，只安排一个阿姨负责分菜的话，效率太低了，阿姨可能会被累死。那么，就安排多个阿姨分菜吧。但是，可能会出现一堆学生涌进食堂，啥也不看直接向一号窗口的阿姨冲去；或者是认为一号窗口的阿姨分的菜比较多，所以集体向一号窗口的阿姨跑去，但是其实所有阿姨分菜的量都是一样的。这时，就需要一个人来安排学生排队，或者是告诉学生那里排队都一样。这就是负载均衡。
平时说负载均衡一般都是指服务端负载均衡，但因为分布式spring cloud分布式框架出现，也出现了客户端负载均衡这一概念，这两者之间到底怎么区别呢？
服务器端的负载均衡
首先来看平时说的服务器负载均衡。主要有硬件方面，比如：F5、Array等；还有软件方面，比如：LVS、Nginx等。
用常见的Nginx来举例，具体的服务流程如下：
客户端发送请求，由Nginx服务器接收，根据使用的负载均衡算法，再将请求发送给相应的应用服务器。
就是让一个人（Nginx）来安排学生（请求）来排队到不同的窗口（应用服务器）打饭嘛。
客户端的负载均衡
客户端的负载均衡是在spring-cloud后出现的，在spring-cloud中有ribbon组件来负责负载均衡。spring的负载均衡需要用到服务注册中心eruka。
服务提供方：将自己注册到服务注册中心eruka
服务消费方：从服务注册中心中获取服务列表，使用服务
客户端的负载均衡流程如下:
服务消费方通过ribbon先从服务注册中心获取服务列表，根据一定的负载均衡算法，分发请求到不同的服务提供方
可以理解成学生（服务消费方）在进入饭堂（服务注册中心）后根据自己的想法（负载均衡策略）选择合适的窗口（服务提供方）
总结
服务器负载均衡需要多加一台负载均衡服务器来进行，流程是客户端->负载均衡服务器->应用服务器
客户端负载均衡通过自己完成（先从服务注册中心获取服务列表），流程是客户端->应用服务器
附加：
前面一直提到了负载均衡算法策略，其实就是学生排队的方法。下面列出几种常见的负载均衡算法：
1、随机，通过随机选择服务进行执行，一般这种方式使用较少;
2、轮训，负载均衡默认实现方式，请求来之后排队处理;
3、加权轮训，通过对服务器性能的分型，给高配置，低负载的服务器分配更高的权重，均衡各个服务器的压力;
4、地址Hash，通过客户端请求的地址的HASH值取模映射进行服务器调度。
5、最小链接数;即使请求均衡了，压力不一定会均衡，最小连接数法就是根据服务器的情况，比如请求积压数等参数，将请求分配到当前压力最小的服务器上。
6、其他若干方式。
