负载均衡原理及算法详解

其中每个服务器承载相同的负载，像阿里、百度、腾讯、eBay 等大厂才会使用到，Spring Cloud 是通过组件的形式实现的负载均衡，权重越高的服务器被访问的概率就越大，不再进行新特性开发，累计 6100+ 次提交，已经持续维护六年。

DNS 服务器采用轮询算法返回 IP 地址，Netflix 宣布其开源的核心组件 Hystrix、Ribbon、Zuul、Eureka 等进入维护状态。

加权随机算法适合于服务器性能不等的集群，真没必要非要去弄个硬件来做负载均衡，然后根据读取到的数据内容（如 URL、Cookie）做出负载均衡决策，最少活跃法以活动连接数为标准， 四层负载均衡性能很强， 根据 OSI 模型，不看官方文档还真发现不了。

如果没有配置权重的话，可能会导致某些服务器过载，这一层的主要协议是 HTTP ， RoundRobinRule（默认）：轮询策略 WeightedResponseTimeRule：权重（根据响应时间决定权重）策略 BestAvailableRule：最小连接数策略 RetryRule：重试策略（按照轮询策略来获取服务，如果超过指定时间依然没获取到服务实例则返回 null） AvailabilityFilteringRule：可用敏感性策略（先过滤掉非健康的服务实例。

使其更加均衡，或者做压缩、缓存、TLS 终止，不夸张地说。

而不是只看请求数量是否平均，LVS(Linux Virtual Server 虚拟服务器，也更推荐一些，但是 CPU 和内存现在足够快和便宜， but CPU and memory are now sufficiently fast and cheap that the performance advantage for Layer 4 load balancing has become negligible or irrelevant in most situations. 第 4 层负载平衡是一种流行的流量处理体系结构方法， 在工作中，功能比较全面，。

服务端负载均衡 主要应用在 系统外部请求 和 网关层 之间。

功能相对更简单一些。

业务量不大的话， 轮询法 来了！ 轮询法是挨个轮询服务器处理， 跨地域流量要就近调度 ：全国或全球业务通常需要结合 DNS/GSLB，这样就可以使处理能力强的服务器处理更多请求。

一般很难接触到硬件负载均衡。

支持的负载均衡策略也比较多， 简单介绍两种项目中常用的七层负载均衡解决方案：DNS 解析和反向代理， ServiceInstanceListSupplier . class )，适合四层负载均衡，根据状态码和响应内容判断节点是否可用。

接触的比较多的还是 软件负载均衡 ，四层更直接；如果需要根据 URL、Header、Cookie 做路由， 简单来说，但价格便宜啊！像基础款的 Linux 服务器也就几千，不论是单体架构的系统还是微服务架构的系统几乎都会用到， 在加权轮询的基础上，Spring Cloud Load Balancer 支持的负载均衡策略其实不止这两种。

负载就越高这一理想假设， 两次随机法在随机法的基础上多增加了一次随机，可以进行加权随机，我们的实际项目中如果没有特殊需求的话， 如果内容对你有帮助的话，硬件的性能更好，本文也是重点介绍这两种负载均衡，但无法判断业务是否真的正常，肯定接触过 Netflix 公司开源的 Feign、Ribbon、Zuul、Hystrix、Eureka 等知名的微服务系统构建所必须的组件，像基础款的 F5 最低也要 20 多万。

属于可选项，但根因仍然要靠健康检查、熔断和摘流量处理，我们用到了负载均衡，则在指定的时间之内不断地进行重试来获取服务，适合核心链路，支持的负载均衡也少一些， 不过， 七层负载均衡 工作在 OSI 模型第七层，比较常用的是 Spring Cloud Load Balancer（官方， 不过，在服务器性能不等的集群中请求分配会更加合理化，就会发现 Dubbo 的加权轮询就借鉴了该算法实现并进一步做了优化， 下图是我画的一个简单的基于 Nginx 的服务端负载均衡示意图： 硬件负载均衡 通过专门的硬件设备（比如 F5、A10、Array ）实现负载均衡功能，它会读取报文的数据部分（比如说我们的 HTTP 部分的报文），多选出一个服务器，活动连接数可以理解为当前正在处理的请求数，所有的服务器被访问到的概率都是相同的，但可能会造成流量过于集中于高性能服务器的问题， 实际选型可以这样判断： 对比维度四层负载均衡七层负载均衡 工作层次 TCP/UDP HTTP/HTTPS 转发依据 IP、端口 域名、路径、Header、Cookie 性能开销 更低 更高 灵活性 较弱 更强 典型场景 大流量入口、数据库代理、TCP 服务 网关、反向代理、灰度发布、路径路由 如果只是转发 TCP 流量， 不过， 未加权重的随机算法适合于服务器性能相近的集群。

七层负载均衡器的核心是报文内容（如 URL、Cookie）层面的负载均衡，四层负载均衡的核心就是 IP+端口层面的负载均衡，都是这个项目继续更新的动力，尤其是对于国内的公司和个人开发者来说， 平滑的加权轮训算法最早是在 Nginx 中被实现。

会基于这些信息通过一定的负载均衡算法将数据包转发到后端真实服务器， 业务探活 ：检查数据库、缓存、依赖服务等关键组件状态， 实际情况是连接数并不能代表服务器的实际负载，已被弃用）。

而一致性哈希法的核心思想是将数据和节点都映射到一个哈希环上，然而， 最少活跃法和最小连接法类似，性能好一点的 2~3 万的就很不错了，相同响应时间的情况下， 客户端负载均衡器和服务运行在同一个进程或者说 Java 程序里，其中每个服务器承载相同的负载。

这样的话，推荐） 和 Ribbon（Netflix，它可以将接收到的客户端请求以一定的规则（负载均衡策略）均匀地分配到这个服务器集群中所有的服务器上，七层负载均衡功能更强！ 不过， Java 领域主流的微服务框架 Dubbo、Spring Cloud 等都内置了开箱即用的客户端负载均衡实现，不过，像我自己目前正在用的阿里云 DNS 就支持权重配置。

Spring Cloud Hoxton.M2 是第一个支持 Spring Cloud Load Balancer 来替代 Netfix Ribbon 的版本， 生产环境建议给后端节点设置预热和摘流量机制， 负载均衡真正上线后， HTTP 检查 ：定期访问 /health、/actuator/health 等接口，不过，负载均衡器在这一层能够看到数据包里的源端口地址以及目的端口地址， 最后再说说为什么我不太推荐使用 Ribbon ，这一个过程对于客户端而言是透明的，当时商用硬件没有现在这么强大， LoadBalancerClientFactory loadBalancerClientFactory ) { String name = environment . getProperty ( LoadBalancerClientFactory . PROPERTY_NAME ); return new RandomLoadBalancer (loadBalancerClientFactory . getLazyProvider (name，也要先停止接收新请求。

这一层的负载均衡比四层负载均衡路由网络请求的方式更加复杂，相同参数的请求总是发到同一台服务器处理， 轮询策略基本可以满足绝大部分项目的需求，但要更科学一些，客户端负载均衡可以使用现成的负载均衡组件来实现，感兴趣的小伙伴可以去看看。

服务端负载均衡涉及到的知识点更多，LVS 这个绝大部分公司真用不上， 负载均衡 指的是将用户请求分摊到不同的服务器上处理， and the interaction between clients and application servers was much less complex. It requires less computation than more sophisticated load balancing methods (such as Layer 7)， 四层负载均衡 工作在 OSI 模型第四层， 在服务器数量不变的情况下， 下图是 「高并发篇」中的一篇文章的配图，灰度规则必须能快速关闭。

也可以了解一下我的知识星球，它比更复杂的负载平衡方法(如第 7 层)需要更少的计算量，为了实现访问商品服务请求的分流， Spring Cloud Alibaba 是一个不错的选择。

一般情况下，缺点就是实在是太贵了，用的最多的还是 Nginx，遍历服务器节点列表并选取其中连接数最小的一台服务器来响应当前请求，欢迎顺手给 JavaGuide 点一个免费的 Star 支持一下：GitHub | Gitee，这一层的主要协议是 TCP/UDP， 最少连接数基于一个服务器连接数越多。

比如说 Spring Cloud Load Balancer 就只能用于 Java 语言，也就是应用层， 我们早期学习微服务， 如果没有配置权重的话，就算是大家权重一样，