负载均衡是怎么做的~

Posted 2023-04-11

1、服务直接返回：这种安装方式负载均衡的LAN口不使用，WAN口与服务器在同一个网络中，互联网的客户端访问负载均衡的虚IP（VIP），虚IP对应负载均衡机的WAN口，负载均衡根据策略将流量分发到服务器上，服务器直接响应客户端的请求。

2、桥接模式：桥接模式配置简单，不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP（WAN口与LAN口是桥连接），所有的服务器与负载均衡均在同一逻辑网络中。

3、路由模式：路由模式的部署方式，服务器的网关必须设置成负载均衡机的LAN口地址，且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小，能均衡任何下行流量。

扩展资料

负载均衡的算法:

1、随机算法：Random随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

2、哈希算法：一致性哈希一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

3、URL散列：通过管理客户端请求URL信息的散列，将发送至相同URL的请求转发至同一服务器的算法。

参考资料

百度百科-负载均衡

参考技术A 负载均衡（Load Balance）

由于目前现有网络的各个核心部分随着业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，这样将造成现有资源的浪费，而且如果再面临下一次业务量的提升时，这又将导致再一次硬件升级的高额成本投入，甚至性能再卓越的设备也不能满足当前业务量增长的需求。

针对此情况而衍生出来的一种廉价有效透明的方法以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性的技术就是负载均衡（Load Balance）。

负载均衡技术主要应用

1、DNS负载均衡 最早的负载均衡技术是通过DNS来实现的，在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。

2、代理服务器负载均衡 使用代理服务器，可以将请求转发给内部的服务器，使用这种加速模式显然可以提升静态网页的访问速度。然而，也可以考虑这样一种技术，使用代理服务器将请求均匀转发给多台服务器，从而达到负载均衡的目的。

3、地址转换网关负载均衡 支持负载均衡的地址转换网关，可以将一个外部IP地址映射为多个内部IP地址，对每次TCP连接请求动态使用其中一个内部地址，达到负载均衡的目的。

4、协议内部支持负载均衡 除了这三种负载均衡方式之外，有的协议内部支持与负载均衡相关的功能，例如HTTP协议中的重定向能力等，HTTP运行于TCP连接的最高层。

5、NAT负载均衡 NAT（Network Address Translation 网络地址转换）简单地说就是将一个IP地址转换为另一个IP地址，一般用于未经注册的内部地址与合法的、已获注册的Internet IP地址间进行转换。适用于解决Internet IP地址紧张、不想让网络外部知道内部网络结构等的场合下。

6、反向代理负载均衡 普通代理方式是代理内部网络用户访问internet上服务器的连接请求，客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。反向代理（Reverse Proxy）方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。

7、混合型负载均衡 在有些大型网络，由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异，我们可以考虑给每个服务器群采用最合适的负载均衡方式，然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务（即把这多个服务器群当做一个新的服务器群），从而达到最佳的性能。我们将这种方式称之为混合型负载均衡。此种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。 参考技术B 负载均衡有分硬件负载和软件。
1. 硬件方面，可以用F5做负载，内置几十种算法。
2. 软件方面，可以使用反向代理服务器，例如apache,nginx等高可用反向代理服务器。 参考技术C 负载均衡的意思就是有几台服务器或者几个服务。。通过设备或者软件，将外部来的连接均匀的分配到这几个服务器或者服务上面。。使服务器的负载平均 参考技术D 这个问题比较笼统

在win2K高级服务器（包含）以后的服务器操作系统里面在网卡属性那里有个负载均衡，可以实现网卡分担。还有一些专业的负载均衡设备。推荐你搜索下baidu很多相关知识，还推荐杂志“windows国际中文版”这本杂志以前详细介绍过在2k高级服务器下面负载均衡的实例。

京东的负载均衡是这么做的(改进点篇）

经典架构技术文章第一时间送达！

618大促，京东的网关承载了几十亿的流量和调用，在这种情况下，网关系统必须保证整个系统的稳定性和高可用，保证高性能和可靠，以支撑业务。基于这种复杂问题，怎样做到很好地提高它的性能和稳定性、复杂技术之间怎么整合保证整体网关的高可用。

昨日已经详细介绍了京东做负载均衡的基本情况，下面会就昨天结尾提到了八个点展开介绍。昨日推文——

三、基本思路及过程改进点

实践 1 Nginx层统一接入

先看网关整个线上的部署架构，先通过一个软负载LVS进入到整个京东的网关，第一层是核心Nginx，经过核心Nginx之后就是后面的业务Nginx，然后通过业务Nginx把我们的请求透传到后端的服务器。

核心Nginx主要是前端流量的分配，比如限流、防刷都是在这层去做。下层是业务Nginx，主要的Nginx+lua的逻辑在这一层实现。这一层还有能减轻核心Nginx压力、CPU压力的作用，而且一些lua的应用逻辑，比如限流、防刷、鉴权、降级都是在这一层做的。

相较于Tomcat等，Nginx其实是一个能扛特别大并发流量的服务器。Nginx天然就是这种NIO异步的方式，能够非常好地支持大并发的业务需求。所以我们把一些核心的，比如降级、流控等，都放在这一层，让它替我们在最前端把流量防住。

实践 2 引入NIO、利用Servlet3异步化

第二个实践是在Tomcat层引入了NIO，用了一个JDK7+TOMCAT7+Servlet3的配置，让同步请求变得异步化，然后利用NIO的多路复用处理技术，让我们能够同时处理更高的并发数。

利用Servlet3异步化之后可以提升吞吐量，但单个请求的响应时间会略微变长，不过这种损耗是可以忍受的，因为这会带来整个应用吞吐量的增加和灵活性的增强。还是非常值得我们使用的。

实践 3 分离之术

本节将在所有分离技术中挑两个比较重点的进行分享。

请求解析和业务处理分离

第一个是通过NIO的方式，把请求解析的线程和后面处理的业务线程进行分离。

请求由tomcat单线程处理，在NIO模式下可以用非常少量线程处理大量链接情况。业务逻辑处理和生成响应都是由另外的tomcat线程池处理，从而跟请求线程隔离。这里的业务线程池还可以进一步隔离，不同业务设置不同的线程池。

业务线程池分离

第二个是业务线程池分离，就是通过一个线程的隔离技术，把不同的接口或不同类型的接口进行隔离。比如订单相关的接口，拿20个单独线程去处理；商品相关的接口，拿10个单独的线程去处理，这样的话就可以让不同的接口之间互不影响，如果订单这块有一个出了问题，最多消耗它自己，不会影响到其他接口的线程的调用。

具体的线程隔离可以根据业务来指定一组线程的数量，这几个线程是为固定接口准备的，当这个接口出现问题，它就把自己的线程数用掉了，不会去占用其他接口的线程，这样起到了线程隔离的作用，让单个API出问题的时候不会影响到其他。

实践 4 降级

降级主要是说当有某个接口出现问题，我们能够把这个接口直接降调，让它调用直接返回，不会用到其他应用。还有就是如果某一块弱一点的业务逻辑出现问题，我们直接把这块逻辑降调，不至于影响到其他的黄金逻辑。

降级怎么做？

首先，降级开关要集中化管理，比如通过zookeeper推送到各个应用服务。这样才能在出现问题的第一时间找到对应开关做降级处理。

精细化流量控制

说完开关、流量控制和降级之后，我们来看通过多维度的流量控制和降级的策略，比如按照单个API或API+地域、运营商等维度进行控制。一旦出问题了，我们会把多种组合方式进行降级，还可以根据秒/分钟级等不同维度进行流量控制，从而达到精细化流量管理。

优雅降级

说到降级，前面说的更多的是技术层面的，在业务层面的话，我们也要讲究优雅降级。我们不能说这个逻辑一旦建立之后就直接返回前端502，这肯定是不友好的。我们肯定会跟前端进行沟通，比如降级之后反馈给前端一个对应的错误码，或者给用户反馈一个提示等操作指令，这样能够让用户体验更好一些。

实践 5 限流

恶意请求、恶意攻击，恶意的请求流量可以只访问cache，恶意的IP可以使用nginx层的 deny进行屛蔽；

防止流程超出系统的承载能力，虽然会预估但总有意外，如果没有限流，当超过系统承载峰值的时候，整个系统就会打垮。

实践 6 熔断

当我们的后端机构出现问题了，达到某个阀值了，系统就能够自动进行关闭降级，这是熔断的大体思路。我们会有更灵活的配置：比如当某个接口接连三次访问超时或返回错误的话就自动熔断；也可以是配置一些超时间，比如连续三次这种方法调用的性能都超过了50毫秒，就会自动对这个方法进行熔断，熔断之后就相当于降级了，再次调用的话会返回失败，就是直接拒绝返回了。

熔断之后还可以有一个设置：比如5秒或一分钟之后出来一个半打开状态，再次醒来之后，它会去试探一下当天这个服务是否已经OK了，如果没有问题了，它就会去把你之前熔断的API业务再次打开，能够正常对外提供服务。现在有一些开源的实践，通过这些实践可以很好的做熔断，当然根据这里边的思路，自己也可以实现，这不是特别复杂的事情。

实践 7 快速失败-链路中的超时

快速失败是非常重要的一个实践，不光是做网关系统，做其他系统也要记住，特别是调用量大的系统，比如注意到整个链条中的超时设置。这是我们每年在做双11和618备战的时候，都需要重点去review的一块东西，包括我们平时在做开发的时候、每一次新模块上线之前，我们都要重点去监控这一块。我们会梳理所有系统对外的依赖，比如网关依赖于我们自己的一些业务的缓存、数据库，更多的是依赖于后端数千个不同的服务。

这种涉及到网络的，我们必须要设置超时间，因为像网关这种调用量比较大的系统，如果不设超时间，有可能它默认时间就是几分钟，这么长时间，一旦有一个机构出问题了，有可能瞬间整个网关系统会全部雪崩掉，任何一个接口都不能对外使用，因为数据量很大，有可能你都来不及降级就已经被冲垮了。

实践 8 监控统计-应用层

监控统计是网关系统里非常核心的一部分，只有有了监控，有了报警，才能让我们实时了解所有的运营情况、每一个API调用的情况。

监控目标

第一：保证7*24小时守护系统；

第二：能够实时监控系统的运营状况，比如哪个API是不是调用时间过长了？哪个API已经熔断了？等等；

第三：统计数据，分析指标。比如一天过去了，每一个API调用情况有没有超时？有没有访问的性能降低等；

第四：实时报警。因为监控是一部分，发现问题之后能够第一时间通知到我们，让我们能够马上处理也是让系统更加健康的一个方面。

监控范围

监控的维度

• 第一层：硬件监控。比如系统的CPU内存、网卡等。

• 第二层：自定义监控。比如直接报警。

• 第三层：性能监控。比如每个接口的TP指标，TP999 TP99 TP90 TP50四种性能指标作为SLA的参考标准，还有可用率等，这个对于网关来说至关重要。

• 第四层：心跳监控。网关系统线上有很多机器，每个机器现在的情况怎样？有没有存货等。

• 第五层：业务层监控。比如我们会有一些JVM监控，监控Nginx连接数等。

在京东内部有一个很完善的监控体系，叫UMP系统，能够帮助我们做各个层级的监控。它主要是提供给我们一些类似于配置的文件，我们配置好之后就可以进行系统的监控，我们在做的时候会通过一些AOP代理的方式，对所有的方法进行监控。因为我们是网关，需要大量的后端透传，网关因为是动态地生成这些接口，根本不知道有哪些接口，所以在动态生成接口的时候自动地AOP给它注入一个个监控，这样的话就是每一个接口都能够有一个监控。

说到监控不得不提的是，我们做网关系统就是做透传的，后面有各种各样不同的接口、业务逻辑，每个业务逻辑和接口的性能都需要去监控，然后告知对方让对方去整改的，所以我们除了把这些监控加完之后，有了问题要能够通知到对应的负责人，包括我们自己。所以我们每一天每一周都会有邮件以报表形式发出，让所有系统负责人都知道对应的机构的情况，比如性能是否有问题、是否需要整改等。

如需查看更多技术架构文章，长按下面二维码关注，获取大量经典架构技术，让我们一起学习架构技术支持，成长为架构师。

经典技术架构

ID：tuhao_programer

互联网 | 海量高可用 | 应用技术架构丨大数据丨机器学习 | 云计算