负载均衡可以简单分为服务端负载均衡和客户端负载均衡这两种。

根据 OSI 模型，服务端负载均衡还可以分为：

二层负载均衡
三层负载均衡
四层负载均衡
七层负载均衡

最常见的是四层和七层负载均衡

四层负载均衡 工作在 OSI 模型第四层，也就是传输层，这一层的主要协议是 TCP/UDP，负载均衡器在这一层能够看到数据包里的源端口地址以及目的端口地址，会基于这些信息通过一定的负载均衡算法将数据包转发到后端真实服务器。也就是说，四层负载均衡的核心就是 IP+端口层面的负载均衡，不涉及具体的报文内容。
七层负载均衡 工作在 OSI 模型第七层，也就是应用层，这一层的主要协议是 HTTP 。这一层的负载均衡比四层负载均衡路由网络请求的方式更加复杂，它会读取报文的数据部分（比如说我们的 HTTP 部分的报文），然后根据读取到的数据内容（如 URL、Cookie）做出负载均衡决策。也就是说，七层负载均衡器的核心是报文内容（如 URL、Cookie）层面的负载均衡，执行第七层负载均衡的设备通常被称为 反向代理服务器 。

七层负载均衡比四层负载均衡会消耗更多的性能，不过，也相对更加灵活，能够更加智能地路由网络请求，比如说你可以根据请求的内容进行优化如缓存、压缩、加密。

简单来说，四层负载均衡性能更强，七层负载均衡功能更强！

常用的七层负载均衡解决方案：DNS 解析和反向代理

在工作中，我们通常会使用 Nginx 来做七层负载均衡，LVS(Linux Virtual Server 虚拟服务器， Linux 内核的 4 层负载均衡)来做四层负载均衡。

一、服务端负载均衡

服务端负载均衡 主要应用在系统外部请求和网关层之间，可以使用软件或硬件实现。

在我们日常开发中，一般很难接触到硬件负载均衡，接触的比较多的还是软件负载均衡 。软件负载均衡通过软件（比如 LVS、Nginx、HAproxy ）实现负载均衡功能。

二、客户端负载均衡

客户端负载均衡主要应用于系统内部的不同服务之间，可以使用现成的负载均衡组件来实现。

在客户端负载均衡中，客户端会自己维护一份服务器的地址列表，发送请求之前，客户端会根据对应的负载均衡算法来选择具体某一台服务器处理请求。

客户端负载均衡器和服务运行在同一个进程或者说 Java 程序里，不存在额外的网络开销。不过，客户端负载均衡的实现会受到编程语言的限制，比如说 Spring Cloud Load Balancer 就只能用于 Java 语言。

Java 领域主流的微服务框架 Dubbo、Spring Cloud 等都内置了开箱即用的客户端负载均衡实现。Dubbo 属于是默认自带了负载均衡功能，Spring Cloud 是通过组件的形式实现的负载均衡，属于可选项，比较常用的是 Spring Cloud Load Balancer（官方，推荐）和 Ribbon（Netflix，已被启用）。

Ribbon 支持的 7 种负载均衡策略：

RandomRule：随机策略。
RoundRobinRule（默认）：轮询策略
WeightedResponseTimeRule：权重（根据响应时间决定权重）策略
BestAvailableRule：最小连接数策略
RetryRule：重试策略（按照轮询策略来获取服务，如果获取的服务实例为 null 或已经失效，则在指定的时间之内不断地进行重试来获取服务，如果超过指定时间依然没获取到服务实例则返回 null）
AvailabilityFilteringRule：可用敏感性策略（先过滤掉非健康的服务实例，然后再选择连接数较小的服务实例）
ZoneAvoidanceRule：区域敏感性策略（根据服务所在区域的性能和服务的可用性来选择服务实例）

Spring Cloud Load Balancer 支持的 2 种负载均衡策略：

RandomLoadBalancer：随机策略
RoundRobinLoadBalancer（默认）：轮询策略

不过，Spring Cloud Load Balancer 支持的负载均衡策略其实不止这两种，看官方文档。

三、负载均衡常见的算法

随机法

轮询法

一致性 Hash 法

最小连接法

四、Nginx负载均衡实现原理

Nginx服务器作为前端，Tomcat服务器作为后端，页面请求由Nginx服务来进行转发请求到不同的web服务器上，但是不是把所有的Web请求转发，静态页面请求Nginx服务器自己来处理，动态页面请求转发给后端的Tomcat服务器来处理。
Tomcat是属于轻量级的应用服务器，它内置了一个轻量级的Web服务器，用于转发html文件的请求，可以接受的访问量可能会不足，所以我们需要多台Tmocat服务器，然后通过Nginx选择负载策略来挑选不同的Tomcat服务器去进行处理。
nginx+tomcat 部署实现负载均衡原理如下图：

五、Nginx和Ribbon的区别

        Nginx是服务端负载均衡，客户端所有请求都会交给nginx，然后由nginx实现转发请求到不同的web服务器上（如Tomcat），即负载均衡是由服务端实现的。
        Ribbon是客户端负载均衡，在调用服务接口时，会在注册中心上获取注册服务列表之后缓存到JVM本地，从而在本地实现RPC远程服务调用（个人理解的意思：nginx用来处理网关集群的，ribbon用来处理服务集群的，至于为不直接用nginx处理服务集群，好像是因为开发语言的问题）。
        Nginx适合于服务器端实现负载均衡，比如Tomcat ，Ribbon适合于在微服务中RPC远程调用实现本地服务负载均衡，比如Dubbo、SpringCloud中都是采用本地负载均衡。

Nginx是一个独立运行的服务器，通过反向代理实现负载均衡。Ribbon是一个客户端负载均衡组件，它依赖于服务注册中心给出的服务列表，做服务路由选择。两个定位不一样，工作模式和位置也不一样。在某些基于DNS负载场合，两者是可以结合起来使用的。
Ribbon是一个客户端负载均衡框架，最大的优势之一就是无单点，而使用nginx的话又会引入这样一个单点了，引入这个单点以后你还要调优它，请求也多了一层转发，从可靠性、复杂度这些方面都不如直接用ribbon。

其实如果用k8s的话，甚至springcloud都不需要，看项目和团队怎么抉择吧。

六、正向代理和反向代理的区别

正向代理隐藏的是用户，反向代理隐藏的是服务器
正向代理是为用户服务的，反向代理是为服务器服务的
正向代理：
正向代理是一个被配置为代表客户端的服务器（伪装客户端），客户端的请求转到代理处，而不是服务器处。代理再将请求转发给服务器，并等待响应，将其送回给客户端，这样的话，服务器就不知道客户端是谁了，它只知道代理的源IP地址，这时候对于服务器而言用户是不可见的，他们并不知道用户在哪。因此，正向代理可以保护和隐藏客户端的身份。 VPN也遵循相同的工作原理。
优点：
1、选择性的发送/阻止请求
2、记录或监控请求
3、缓存回复

vpn是在用户浏览器端设置的(并不是在远端的服务器设置)。
浏览器先访问vpn地址，vpn地址转发请求，并最后将请求结果原路返回来。

反向代理：
反向代理是配置为代表另一台服务器运行的服务器（伪装服务器）。代理代替服务器接收客户端的请求。代理将请求转发到服务器并等待将它们发送回给客户端的响应。
客户端不知道它正在与反向代理通信。响应返回给客户端，似乎来自服务器本身。这时对于用户而言服务器是不可见的，用户并不知道是哪个服务器给你传回来数据。因此反向代理可以保护和隐藏服务器的身份。
优点：
1、为一组服务器做负载均衡
2、服务器的匿名性和更高的安全性
3、更好的性能，代替服务器执行额外的任务

反向代理是作用在服务器端的，是一个虚拟ip(VIP)。对于用户的一个请求，会转发到多个后端处理器中的一台来处理该具体请求。
大型网站都有DNS(域名解析服务器)，load balance(负载均衡器)等。

注意：无论是正向代理和反向代理，实际上相互都不知道对方，他们只需要明确自己的需求和结果，而中间的发送和返回的过程并不关心，实际上一个传输的过程中完全有可能存在正向代理和反向代理两种模式，当你使用vpn（正向）访问一个使用了负载均衡（反向）的服务器。

例子：
正向代理：vpn，某个商店，你不能去买东西或者你不想暴露自己，但是你朋友可以去买，你就把钱给他让他去买。（你的请求给你朋友，商店不知道真正的客户是谁）
反向代理：vip，某个生产商，不想暴露自己的几个生产工厂，就把商品放到门店，你就去门店那里买。（你只关心你买到的东西，你并不知道真正的生产工厂是哪个）