科普文：深入明确负载平衡（四层负载平衡、七层负载平衡）

登录 · 发表于 2026-1-16 11:34:42

概叙

网络模子：OSI七层模子、TCP/IP四层模子、实际的五层模子

应用层：对软件提供接口以使程序能使用网络服务，如事务处理程序、文件传送协议和网络管理等。（HTTP、Telnet、FTP、SMTP）
表示层：程序和网络之间的翻译官，管理数据的解密加密数据转换、格式化和文本压缩。（JPEG、ASCII、GIF、DES、MPEG）
会话层：负责在网络中的两节点之间建立和维持通信，以及提供交互会话的管理功能。（RPC、SQL、NFS）
传输层：提供建立、维护和拆除传送连接的功能；选择网络层提供最合适的服务；在系统之间提供可靠的透明的数据传送，提供端到端的错误恢复和流量控制。（TCP、UDP、SPX）
网络层：将网络地址（ip地址）翻译成对应物理地址（网卡地址），并决定如何将数据从发送方路由到接收方。（IP、ICMP、IGMP、IPX、ARP、RARP）
数据链路层：物理地址寻址、数据的成帧、流量控制、数据的检错、重发。（IEEE 802.3/.2、HDLC、PPP、ATM）
物理层：物理连网媒介，如电缆连线连接器。（RS232、V.35、RJ-45、FDDI）

复制代码

为什么要有负载平衡?

        在高并发的业务场景下，办理单个节点压力过大，导致Web服务相应过慢，特殊是严峻的环境下导致服务瘫痪，无法正常提供服务的标题，目标就是为了维护体系稳固可靠。而负载平衡技能通过将负载（‌工作任务）‌平衡、‌分摊到多个利用单元上举行运行，‌如FTP服务器、‌Web服务器等，‌从而协同完成工作任务。‌这种技能构建在原有网络结构之上，‌提供了一种透明且自制有用的方法来扩展服务器和网络装备的带宽，‌增强网络数据处理处罚本领，‌增长吞吐量，‌进步网络的可用性和机动性。‌
        负载平衡的告急作用是为了包管体系的可用性、‌可靠性、‌性能和相应时间。‌
        具体来说，‌负载平衡的作用包罗：‌

进步体系性能：‌通过将负载分发到多个资源上，‌体系可以或许处理处罚更多的并发哀求，‌从而进步团体的处理处罚本领和性能。‌
实现高可用性：‌当此中一个资源发生故障或不可用时，‌负载平衡可以主动将哀求转发到其他可用的资源，‌低落单点故障的风险，‌进步体系的可靠性和容错性。‌
进步体系可伸缩性：‌随着业务的增长，‌负载平衡技能可以动态地增长或镌汰资源的数目，‌根据实际负载环境举行扩展或紧缩，‌实现水平扩展，‌满意不绝增长的需求。‌
优化资源利用：‌根据资源的性能、‌可用性和负载环境，‌公道地分配哀求或任务，‌最大限度地利用资源，‌克制资源的空闲或过载。‌

        别的，‌负载平衡还可以与其他云服务举行集成，‌比方容器编排、‌数据库、‌网络服务等，‌为用户提供更全面的云服务。‌通过实现这些功能，‌负载平衡确保了体系的一连运行，‌优化了体系的性能和相应时间，‌从而进步了体系的团体服从和用户体验
什么是负载平衡？

负载平衡（Load Balance）的指将负载（工作任务）举行平衡、分摊到多个利用单元上举行运行，比方FTP服务器、Web服务器、企业核心应用服务器和别的告急任务服务器等，从而协同完成工作任务。负载平衡构建在原有网络结构之上，它提供了一种透明且自制有用的方法扩展服务器和网络装备的带宽、增强网络数据处理处罚本领、增长吞吐量、进步网络的可用性和机动性。
        负载平衡重点在于由原来的单个节点承接流量，变成多个节点分担流量，镌汰哀求相应时间，进步应用步伐的可用性和可伸缩性。
        负载平衡是指将传入的网络流量高效分发到一组后端服务器，也称为“服务器群”或“服务器池”。当代高流量网站必须满意来自用户或客户端的数十万乃至数百万的并发哀求，并快速、可靠地返回准确的文本、图像、视频或应用数据。为了经济高效地举行扩展以满意这些海量数据需求，当代盘算最佳实践通常要求添加更多的服务器。
        负载平衡有两方面的寄义：
        起首，大量的并发访问或数据流量分担到多台节点装备上分别处理处罚，镌汰用户期待相应的时间；
        其次，单个重负载的运算分担到多台节点装备上做并行处理处罚，每个节点装备处理处罚竣过后，将结果汇总，返回给用户，体系处理处罚本领得到大幅度进步。
        通过这种方式，负载平衡器可实验以下功能：

在多台服务器之间高效分配客户端哀求或网络负载
仅向在线服务器发送哀求，确保高可用性和可靠性
提供按需增减服务器的机动性

负载平衡实用场景

负载平衡战略

        现在有很多差别的负载平衡技能用以满意差别的应用需求，下面从负载平衡所接纳的装备对象(软、硬件负载平衡)，应用的OSI网络条理(网络条理上的负载平衡)，及应用的地理结构(客户端和服务端负载平衡)等来分类。

硬件与软件负载平衡

        负载平衡器通常有两种情势：基于硬件和基于软件。基于硬件的办理方案的厂商将专有软件加载到其提供的呆板（通常搭载专用处理处罚器）上。
        为了处理处罚日益增长的网站流量，您必须从厂商处购买更多或更大的呆板。而软件办理方案通常在商用硬件上运行，因此更为经济、更加机动。您可将软件安装到所选硬件上，大概安装在 AWS EC2 等云环境中。
软件负载平衡

        软件负载平衡办理方案是指在一台或多台服务器相应的利用体系上安装一个或多个附加软件来实现负载平衡，如DNS Load Balance，Check Point Firewall-1 Connect Control，Keepalive+ IPVS、Nginx、apache、LVS等，它的优点是基于特定环境，设置简单，利用机动，本钱低廉，可以满意一样寻常的负载平衡需求。
        软件办理方案缺点也较多，由于每台服务器上安装额外的软件运行会斲丧体系不定量的资源，越是功能强盛的模块，斲丧得越多，以是当毗连哀求特殊大的时间，软件本身会成为服务器工作成败的一个关键；软件可扩展性并不是很好，受到利用体系的限定；由于利用体系本身的Bug，每每会引起安全标题。
硬件负载平衡

        硬件负载平衡办理方案是直接在服务器和外部网络间安装负载平衡装备，这种装备通常是一个独立于体系的硬件，我们称之为负载平衡器。由于专门的装备完成专门的任务，独立于利用体系，团体性能得到大量进步，加上多样化的负载平衡战略，智能化的流量管理，可到达最佳的负载平衡需求。
        负载平衡器有多种多样的情势，除了作为独立意义上的负载平衡器外，有些负载平衡器集成在交换装备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块毗连到Internet上，一块毗连到后端服务器群的内部网络上。
软、硬件负载平衡的对比

        软件负载平衡的优点是需讨环境明确，设置简单，利用机动，本钱低廉，服从不高，能满意寻常的企业需求；缺点是依赖于体系，增长资源开销；软件的优劣决定环境的性能；体系的安全，软件的稳固性均会影响到整个环境的安全。
        硬件负载平衡优点是独立于体系，团体性能大量提升，在功能、性能上优于软件方式；智能的流量管理，多种战略可选，能到达最佳的负载平衡结果；缺点是代价昂贵（F5硬件服务器不低于20万/台）。
OSI网络条理负载平衡

按照OSI七层模子分别方式：根据接纳的装备对象区分、根据位于OSI中差别条理的分别，这里我们告急讲根据OSI中的条理分别。

二层负载均衡（mac地址）：数据链路层，使用虚拟MAC地址方式，外部请求流量经过虚拟MAC地址，负载均衡收到流量请求后分配后端实际的MAC地址进行响应。
三层负载均衡（ip地址）：网络层，使用虚拟ip地址方式，外部请求流量经过虚拟IP地址，负载均衡收到流量请求后分配后端实际的IP地址进行响应。
四层负载均衡（tcp、udp）：传输层，使用IP+PORT接收外部流量请求，转发到对应的机器上。
七层负载均衡（http）：应用层，使用虚拟的URL或IP地址接收外部流量请求，转发到对应的处理服务器。
1）二层负载均衡（一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应）；
2）三层负载均衡（一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应）；
3）四层负载均衡（在三次负载均衡的基础上，用 ip+port 接收请求，再转发到对应的机器）；
4）七层负载均衡（根据虚拟的url或是IP，主机名接收请求，再转向相应的处理服务器）。

复制代码

二层负载平衡

        二层负债平衡是基于数据链路层的负债平衡，即让负债平衡服务器和业务服务器绑定同一个捏造IP（即VIP），客户端直接通过这个VIP举行哀求。
        那么怎样区分雷同IP下的差别呆板呢？没错，通过MAC物理地点，每台呆板的MAC物理地点都不一样，当负载平衡服务器吸收到哀求之后，通过改写HTTP报文中以太网首部的MAC地点，按照某种算法将哀求转发到目标呆板上，实现负载平衡。
        这种方式负载方式固然控制粒度比力粗，但是优点是负载平衡服务器的压力会比力小，负载平衡服务器只负责哀求的进入，不负责哀求的相应（相应是有后端业务服务器直接相应给客户端），吞吐量会比力高。

三层负载平衡

三层负载平衡是基于网络层的负载平衡，普通的说就是按照差别呆板差别IP地点举行转发哀求到差别的呆板上。
这种方式固然比二层负载多了一层，但从控制的颗粒度上看，并没有比二层负载平衡更有上风，而且，由于哀求的收支都要颠末负载平衡服务器，会对其造成比力大的压力，性能也比二层负载平衡要差。

四层负载平衡

        四层的负载平衡就是基于IP+端口的负载平衡：在三层负载平衡的底子上，通过发布三层的IP地点（VIP），然后加四层的端标语，来决定哪些流量须要做负载平衡，对须要处理处罚的流量举行NAT处理处罚，转发至背景服务器，并记载下这个TCP大概UDP的流量是由哪台服务器处理处罚的，后续这个毗连的全部流量都同样转发到同一台服务器处理处罚。
        对应的负载平衡器称为四层交换机（L4 switch），告急分析IP层及TCP/UDP层，实现四层负载平衡。
        此种负载平衡器不明确应用协议（如HTTP/FTP/MySQL等等），常见例子有：LVS，F5。

七层负载平衡

        七层的负载平衡就是基于捏造的URL或主机IP的负载平衡：在四层负载平衡的底子上（没有四层是绝对不大概有七层的），再思量应用层的特性，比犹如一个Web服务器的负载平衡，除了根据VIP加80端口辨别是否须要处理处罚的流量，还可根据七层的URL、欣赏器种别、语言来决定是否要举行负载平衡。
        举个例子，假如你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载平衡就可以当用户来访问你的域名时，主动辨别用户语言，然后选择对应的语言服务器组举行负载平衡处理处罚。
        对应的负载平衡器称为七层交换机（L7 switch），除了支持四层负载平衡以外，尚有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载平衡。此种负载平衡器能明确应用协议，常见例子有：  haproxy，MySQL Proxy、Nginx、apache。

服务端负载平衡 和 客户端负载平衡

服务端负载平衡

服务端负载平衡可通过硬件装备或软件来实现，硬件好比：F5、Array等，软件好比：LVS、Nginx等。通过硬件或软件实现负载平衡均会维护一个服务端清单，利用心跳检测等本领举行清单维护，包管清单中都是可以正常访问的服务节点。当用户发送哀求时，会先到达负载平衡器（也相当于一个服务），负载平衡器根据负载平衡算法（轮训、随机、加权轮训）从可用的服务端列表中取出一台服务端的地点，接着举行转发，低落体系的压力。

服务端负载平衡分类

DNS负载平衡
链路层负载平衡
IP负载平衡
HTTP负载平衡
反向署理负载平衡

DNS域名分析负载平衡

利用DNS处理处罚域名分析哀求的同时举行负载平衡是一种常用的方案。在DNS服务器中设置多个A记载，每次域名分析哀求都会根据负载平衡算法盘算一个差别的IP地点返回，如许A记载中设置的多个服务器就构成一个集群，并可以实现负载平衡。
DNS域名分析负载平衡的优点是将负载平衡工作交给DNS，省略掉了网络管理的贫困，缺点就是DNS大概缓存A记载，不受网站控制。毕竟上，大型网站总是部门利用DNS域名分析，作为第一级负载平衡本领，然后再在内部做第二级负载平衡。
数据链路层负载平衡(LVS)

        数据链路层负载平衡是指在通讯协议的数据链路层修改mac地点举行负载平衡。
        这种数据传输方式又称作三角传输模式，负载平衡数据分发过程中不修改IP地点，只修改目标的mac地点，通过设置真实物理服务器集群全部呆板捏造IP和负载平衡服务器IP地点一样，从而到达负载平衡，这种负载平衡方式又称为直接路由方式（DR）。
        在上图中，用户哀求到达负载平衡服务器后，负载平衡服务器将哀求数据的目标mac地点修改为真实WEB服务器的mac地点，并不修改数据包目标IP地点，因此数据可以正常到达目标WEB服务器，该服务器在处理处罚完数据后可以颠末网关服务器而不是负载平衡服务器直接到达用户欣赏器。
        利用三角传输模式的链路层负载平衡是现在大型网站所利用的最广的一种负载平衡本领。在linux平台上最好的链路层负载平衡开源产物是LVS(linux virtual server)。
IP负载平衡

        IP负载平衡：即在网络层通过修改哀求目标地点举行负载平衡。
        用户哀求数据包到达负载平衡服务器后，负载平衡服务器在利用体系内核举行获取网络数据包，根据负载平衡算法盘算得到一台真实的WEB服务器地点，然后将数据包的IP地点修改为真实的WEB服务器地点，不须要通过用户进程处理处罚。真实的WEB服务器处理处罚完毕后，相应数据包回到负载平衡服务器，负载平衡服务器再将数据包源地点修改为自身的IP地点发送给用户欣赏器。
        这里的关键在于真实WEB服务器相应数据包怎样返回给负载平衡服务器，一种是负载平衡服务器在修改目标IP地点的同时修改源地点，将数据包源地点改为自身的IP，即源地点转换（SNAT），另一种方案是将负载平衡服务器同时作为真实物理服务器的网关服务器，如许全部的数据都会到达负载平衡服务器。
        IP负载平衡在内核进程完成数据分发，较反向署理平衡有更好的处理处罚性能。但由于全部哀求相应的数据包都须要颠末负载平衡服务器，因此负载平衡的网卡带宽成为体系的瓶颈。
HTTP重定向负载平衡

HTTP重定向服务器是一台寻常的应用服务器，其唯一的功能就是根据用户的HTTP哀求盘算一台真实的服务器地点，并将真实的服务器地点写入HTTP重定向相应中（相应状态吗302）返回给欣赏器，然后欣赏器再主动哀求真实的服务器。
这种负载平衡方案的优点是比力简单，缺点是欣赏器须要每次哀求两次服务器才气拿完成一次访问，性能较差；利用HTTP302相应码重定向，大概是搜索引擎判定为SEO作弊，低落搜索排名。重定向服务器自身的处理处罚本领有大概成为瓶颈。因此这种方案在实际利用中并不见多。
反向署理负载平衡

        传统署理服务器位于欣赏器一端，署理欣赏器将HTTP哀求发送到互联网上。而反向署理服务器则位于网站机房一侧，署理网站web服务器吸收http哀求。
        反向署理的作用是掩护网站安全，全部互联网的哀求都必须颠末署理服务器，相当于在web服务器和大概的网络攻击之间创建了一个屏蔽。
        除此之外，署理服务器也可以设置缓存加快web哀求。当用户第一次访问静态内容的时间，静态内存就被缓存在反向署理服务器上，如许当其他用户访问该静态内容时，就可以直接从反向署理服务器返回，加快web哀求相应速率，减轻web服务器负载压力。
        别的，反向署理服务器也可以实现负载平衡的功能。
        由于反向署理服务器转发哀求在HTTP协议层面，因此也叫应用层负载平衡。优点是摆设简单，缺点是大概成为体系的瓶颈。

客户端负载平衡

        对于客户端负载平衡来说，与服务端负载平衡的告急区分点在于服务清单的存放位置。在客户端负载平衡中，客户端本身会存储一份服务端清单，它是通过从注册中心举行抓取得到的，同时也须要对此举行维护。
        在现在的微服务架构中，根本都是接纳的这种客户端负载平衡。相比于服务器端负载平衡，它有一个显着的优点，就是可以肯定水平克制load balancer单点故障。

图中告急包罗三个部门：API Gateway、Service Registry Server、微服务。一样寻常来说，为了进步并发处理处罚本领，API Gateway和微服务都须要有多个instance。
基于上面的架构图，假想两个范例的场景：

API Gateway收到一个哀求，在完成认证和 授权校验 之后，须要把哀求转发到微服务A行止理处罚，而微服务A有多个instance，那么API Gateway应该怎样把哀求转发到微服务A的哪个instance呢？
微服务A收到一个哀求，处理处罚这个哀求时它须要发一个同步哀求给微服务B以获取一些数据，那么这时微服务A应该怎样把哀求发送到微服务B的哪个instance呢？

        对于这两个标题，我们可以利用服务注册和服务发现模块（好比说zookeeper、eureka等）来实现。一样寻常来说，服务注册和服务发现是微服务架构内里非常告急的一个模块，它告急是用于办理微服务架构内部大量微服务之间相互依赖的标题。通过这个模块，可以使微服务之间的相互依赖变得简单和容易维护；同时，也可以实现微服务的负载平衡。
        服务注册和服务发现模块是怎样应用到上面两个场景的呢？
服务注册的角度：
        每个微服务的instance在启动阶段就主动地把本身的IP和端口注册到Service Registry Server；当shutdown的时间，Service Registry Server就主动地把这个instance的IP和端口删撤除。
服务发现的角度：
        针对场景1，API Gateway起首去Service Registry Server获取微服务A全部的instance列表（IP+端口），然后利用某种负载平衡战略选择一个instance，这时就可以直接把哀求转发到微服务A的这个instance。
        针对场景2，流程也是雷同，微服务A起首去Service Registry Server获取微服务B全部的instance列表（IP+端口），然后利用某种负载平衡战略选择一个instance，这时就可以直接把哀求转发到微服务B的这个instance。
客户端负载平衡是怎样克制单点故障的？答：缓存服务端实例列表
        从负载平衡角度可以看到，负载平衡的逻辑是运行在客户端的，顾名思义，这就是一种范例的客户端负载平衡。回到上面提到的，客户端负载平衡可以克制load balancer的单点故障，怎样实现呢？以上面场景2为例，微服务A获取到微服务B的全部instance列表之后可以缓存到内存中，接下来当微服务A哀求微服务B时，都直接从内存中获取微服务B的全部instance列表，如许纵然Service Registry Server挂了，也不影响微服务A和微服务B正常通讯。
API Gateway的负载平衡

什么是API Gateway？

网关是体系的唯一对外的入口，介于客户端和服务器端之间的中心层，处理处罚非业务功能，提供路由哀求、鉴权、监控、缓存、限流、日记记载等功能。如许，差别的微服务之间无需重复实现限流、认证等功能，让微服务每个服务的功能实现更加纯粹，镌汰研发本钱。无论你检察任何一个微服务项目架构，你都会发现在客户端和服务器端之间有一个网关，移动端的任何哀求都必须颠末网关才气到达服务端。它包罗但不限于以下这些特点：

丰富的路由战略：API Gateway 工作在七层，以是它可以分析到 HTTP/HTTPS 层的数据。因此它可以根据哀求的 Path 或 Domain 乃至是 Header 作为条件，将哀求转发到差别的上游服务器。
认证：可以在 API 层面支持多种多样的认证方式来克制非法哀求，好比 OAuth2、JWT 等等，直接将认证这部门服务独立出来，不侵入大概少侵入业务代码。
限流：支持对差别水平的路由举行细粒度的限流，防止恶意攻击，防止后端服务雪崩。
可观测性：可观测性是指从体系外部观察体系内部步伐的运行状态和资源利用环境的本领。 API Gateway 支持将日记对接到 Kafka、 Google Cloud Logging Service、Elasticsearch 等，支持将相干 metrics 接入到 prometheus、datadog 等。
扩展：由于 API Gateway 自身是网关身份，这就注定对它要求是能适配各家公司差别应用场景，好比差别的鉴权、灰度、安全战略、日记网络等，必须允许用户自由选择所需扩展大概自界说开发，因此扩展性很强，允许选择的扩展种类也非常丰富。以 Apache APISIX 举例，光是认证的扩展就有 13 款，险些涵盖了市面上常见的认证需求。

现在市面上有很多 API Gateway，好比 Apache APISIX、Kong、Tyk、Zuul 等，开发者可以根据本身的需求选择符合的 API Gateway。
go-zero中负载平衡的实现

go-zero中的网关

go-zero保举利用 nginx 做为网关，利用 nginx 的 auth_request 模块作为同一鉴权，业务内部不做鉴权。由nginx同一吸收外部哀求，通过匹配 location 将哀求转发到差别的api服务，此时假如须要鉴权，则先调用鉴权api，鉴权通过后，再去调用对应的rpc服务。

Nginx负载平衡

高可用nginx集群

为了防止nginx宕机导致整个服务不可用，也可以利用 Keepalived+Nginx 来实现nginx双机热备。Master和Backup两边都开启nginx服务，无论Master照旧Backup，当此中的一个keepalived服务克制后，vip都会漂移到keepalived服务还在的节点上。对外只袒露一个vip。
具体实现原理：

Master没挂，则Master占据vip且nginx运行在Master上
Master挂了，则backup抢占vip且在backup上运行nginx服务
假如master服务器上的nginx服务挂了，则vip资源转移到backup服务器上
检测后端服务器的康健状态

Nginx实现四层负载平衡和七层负载平衡

负载平衡工作原理

负载平衡分为四层负载平衡和七层负载平衡。
四层负平衡是工作在七层协议的第四层-传输层，告急工作是转发。
它在吸收到客户端的流量以后通过修改数据包的地点信息（目标地点和端口和源地点）将流量转发到应用服务器。
七层负载平衡是工作在七层协议的第七层-应用层，告急工作是署理。
它起首会与客户端创建一条完备的毗连并将应用层的哀求流量分析出来，再按照调治算法选择一个应用服务器，并与应用服务器创建别的一条毗连将哀求发送已往。

Nginx实现七层负载平衡

Nginx服务器：192.168.2.10
  后端服务器1：192.168.2.20
  后端服务器2：192.168.2.30

前端服务器告急设置upstream和proxy_pass：
upstream 告急是设置平衡池和调治方法。
proxy_pass 告急是设置署理服务器ip或服务器组的名字。
proxy_set_header 告急是设置转发给后端服务器的Host和前端客户端真实ip。

Nginx服务器设置

[root@bogon nginx]# vim /usr/local/ngin/conf/nginx.conf
# 在http指令块下配置upstream指令块
upstream web {
server 192.168.2.20;
server 192.168.2.30;
}
# 在location指令块配置proxy_pass
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://web;
proxy_next_upstream error http_404 http_502;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
[root@bogon nginx]# /usr/local/nginx/sbin/nginx -s reload

复制代码

proxy_next_upstream error http_404 http_502; 通过这个指令，可以处理处罚后端返回404等报错时，直接将哀求转发给其他服务器处理处罚，而不是把报错返回客户端
proxy_set_header Host $host; 通过这个指令，把客户端哀求的host,转发给后端
proxy_set_header X-Real-IP $remote_addr通过这个指令, 把客户端的IP转发给后端服务器, 在后端服务器的日记格式中，添加$http_x_real_ip即可获取原始客户端的IP了

后端服务器设置

创建两个静态页面，验证负载均衡效果
在后端服务器192.168.2.20配置如下(配置文件不需要修改即可）
vim /usr/local/nginx/html/index.html
this is 2.20 page
在后端服务器192.168.2.30配置如下(配置文件不需要修改即可）
vim /usr/local/nginx/html/index.html
this is 2.30 page

复制代码

验证差别的负载平衡战略

1.轮询：

Nginx服务器
upstream web {
server 192.168.2.20;
server 192.168.2.30;
}
[root@bogon nginx]# /usr/local/nginx/sbin/nginx -s reload

复制代码

访问验证：

[root@localhost ~]# while true;do curl 192.168.2.10;sleep 2;done
this is 2.20 page
this is 2.30 page
this is 2.20 page
this is 2.30 page
this is 2.20 page
this is 2.30 page
#可以看到后端服务器，非常平均的处理请求。

复制代码

2.轮询加权重：

upstream web {
server 192.168.2.20 weight=3;
server 192.168.2.30 weight=1;
}
默认是weight=1
[root@bogon nginx]# /usr/local/nginx/sbin/nginx -s reload

复制代码

访问验证：

[root@localhost ~]# while true;do curl 192.168.2.10;sleep 2;done
this is 2.20 page
this is 2.20 page
this is 2.20 page
this is 2.30 page
this is 2.20 page
this is 2.20 page
this is 2.20 page
this is 2.30 page
#后端服务，根据权重比例处理请求，适用于服务器性能不均的环境。

复制代码

3.最大错误毗连次数：

错误的毗连由proxy_next_upstream， fastcgi_next_upstream等指令决定，且默认环境下，后端某台服务器出现故障了，nginx会主动将哀求再次转发给其他正常的服务器（由于默 proxy_next_upstream error timeout）。

以是纵然我们没有配这个参数，nginx也可以帮我们处理处罚error和timeout的相应，但是没法处理处罚404等报错。

为了看清晰本质，可以先将proxy_next_upstream设置为off，也就是不将失败的哀求转发给其他正常服务器，如许我们可以看到哀求失败的结果。

vim /usr/local/nginx/conf/nginx.conf
upstream web {
server 192.168.2.20 weight=1 max_fails=3 fail_timeout=9s;
#先将2.20这台nginx关了。
server 192.168.2.30 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://web;
#proxy_next_upstream error http_404 http_502;
proxy_next_upstream off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
[root@bogon nginx]# /usr/local/nginx/sbin/nginx -s reload
# 在这里，我们将超时时间设置为9s，最多尝试3次，
这里要注意，尝试3次，依然遵循轮询的规则，并不是一个请求，连接3次，
而是轮询三次，有3次处理请求的机会

复制代码

访问验证：

复制代码

[root@localhost ~]# while true;do curl -I 192.168.2.10 2>/dev/null|grep HTTP/1.1 ;sleep 3;done
HTTP/1.1 502 Bad Gateway
HTTP/1.1 200 OK
HTTP/1.1 502 Bad Gateway
HTTP/1.1 200 OK
HTTP/1.1 502 Bad Gateway
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 502 Bad Gateway
HTTP/1.1 200 OK
我们设置的超时时间为9s，我们是每3s请求一次。
我们可以看到后端一台服务器挂了后，请求没有直接转发给正常的服务器，
而是直接返回了502。尝试三次后，等待9s，才开始再次尝试（最后一个502）。
要注意，第二行的200响应，并不是客户端第一次的请求的响应码，而是客户端第二次新的请求。

复制代码

将proxy_next_upstream开启

vim /usr/local/nginx/conf/nginx.conf
upstream web {
server 192.168.2.20 weight=1 max_fails=3 fail_timeout=9s;
#先将2.20这台nginx关了。
server 192.168.2.30 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://web;
proxy_next_upstream error http_404 http_502;
#proxy_next_upstream off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
[root@bogon nginx]# /usr/local/nginx/sbin/nginx -s reload

复制代码

再次测试访问验证

[root@localhost ~]# while true;do curl -I 192.168.2.10 2>/dev/null|grep HTTP/1.1 ;sleep 3;done
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
可以看到现在没有502报错，请求都处理了。因为错误的响应码被proxy_next_upstream 获取，这次请求
被转发给下一个正常的服务器了。
所以看到都是200，但是你应该清楚，哪个200是响应的上个服务器没有处理请求，哪个200是正常的响应。

复制代码

4.ip_hash

通过客户端ip举行hash，再通过hash值选择后端server 。

vim /usr/local/nginx/conf/nginx.conf
upstream web {
ip_hash;
server 192.168.2.20 weight=1 max_fails=3 fail_timeout=9s;
server 192.168.2.30 weight=1;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://web;
proxy_next_upstream error http_404 http_502;
#proxy_next_upstream off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
[root@bogon nginx]# /usr/local/nginx/sbin/nginx -s reload

复制代码

访问验证：

[root@localhost ~]# while true;do curl 192.168.2.10;sleep 2;done
this is 2.30 page
this is 2.30 page
this is 2.30 page
this is 2.30 page
this is 2.30 page
this is 2.30 page
[root@localhost ~]# curl 192.168.2.20
this is 2.20 page
#可以看到2.20的服务是正常的，但是却不转发给2.20了，请求固定在了2.30的服务器上。

复制代码

在利用负载平衡的时间会遇到会话保持的标题,常用的方法有:

ip hash，根据客户端的IP，将哀求分配到差别的服务器上;
cookie，服务器给客户端下发一个cookie，具有特定cookie的哀求会分配给它的发布者。

4.url_hash

vim /usr/local/nginx/conf/nginx.conf
upstream web {
hash $request_uri consistent;
server 192.168.2.20;
server 192.168.2.30;
}
[root@bogon nginx]# /usr/local/nginx/sbin/nginx -s reload

复制代码

根据相应时间平衡

# 下载模块：
wget https://github.com/gnosek/nginx-upstream-fair/archive/master.zip
# 解压：
unzip master.zip
# 修改源码bug：
sed -i 's/default_port/no_port/g' ngx_http_upstream_fair_module.c
# 预编译：
./configure --prefix=/usr/local/nginx --add-module=../echo-nginx-module --withhttp_stub_status_module --add-module=../nginx-upstream-fair-master
# 编译/安装：
make && make install
# 配置：
upstream web {
fair;
server 192.168.2.20 weight=1 max_fails=3 fail_timeout=9s;
server 192.168.2.30 weight=1;
}

复制代码

备用服务器

upstream web {
server 192.168.2.20 weight=1 max_fails=3 fail_timeout=9s;
server 192.168.2.30 weight=1 backup;
}
# 2.30的服务器做备用服务器，只有在2.30得服务器不能提供服务时，才会自动顶上,否则，默认是不提供服务的。

复制代码

Nginx实现四层负载平衡

前端服务器：192.168.2.10
  后端服务器1：192.168.2.20
  后端服务器2：192.168.2.30

前端服务器告急设置stream和upstream，注意该模块须要在预编译时指定，没有被默认编译进nginx。

#预编译：
./configure --prefix=/usr/local/nginx --add-module=../echo-nginx-module --withhttp_stub_status_module --with-stream
# 编译/安装：
make && make install
make upgrade
# 在main全局配置stream：
events {
worker_connections 1024;
}
stream {
upstream web {
# 必须要指定ip加port
server 192.168.2.20:80;
server 192.168.2.30:80;
}
server {
listen 80;
# 连接上游服务器超时间，超过则选择另外一个服务器
proxy_connect_timeout 3s;
# tcp连接闲置时间，超过则关闭
proxy_timeout 10s;
proxy_pass web;
}
log_format proxy '$remote_addr $remote_port $protocol $status
[$time_iso8601] '
'"$upstream_addr" "$upstream_bytes_sent"
"$upstream_connect_time"' ;
access_log /usr/local/nginx/logs/proxy.log proxy;
}

复制代码

后端服务器测试页面设置

在后端服务器192.168.2.20配置如下(配置文件不需要修改即可）
vim /usr/local/nginx/html/index.html
this is 2.20 page
在后端服务器192.168.2.30配置如下(配置文件不需要修改即可）
vim /usr/local/nginx/html/index.html
this is 2.30 page

复制代码

访问前端服务器IP测试

复制代码

- 在后端2.30上访问前端IP
[root@localhost ~]# curl 192.168.2.10
this is 2.20 page
- 查看后端2.20日志
[root@bogon nginx]# tail -1 /usr/local/nginx/logs/host.access.log
192.168.2.10 - - [26/Apr/2020:03:16:37 +0800] "GET / HTTP/1.1" 200 18 "-" "curl/7.29.0" "-"
-查看前端2.10日志
[root@bogon nginx]# tail -1 /usr/local/nginx/logs/proxy.log
192.168.2.30 45420 TCP 200 [2020-04-25T19:23:35+08:00] "192.168.2.20:80" "76""0.001"

复制代码

端口转发

复制代码

#在前端2.10配置：
[root@bogon nginx]# vim conf/nginx.conf
events {
worker_connections 1024;
}
stream {
upstream web {
server 192.168.2.20:22;
# server 192.168.2.30:80;
}
server {
listen 6666;
proxy_connect_timeout 3s;
proxy_timeout 10s;
proxy_pass web;
}
log_format proxy '$remote_addr $remote_port $protocol $status [$time_iso8601] ' '"$upstream_addr" "$upstream_bytes_sent""$upstream_connect_time"' ;
access_log /usr/local/nginx/logs/proxy.log proxy;
}
[root@bogon nginx]# /usr/local/nginx/sbin/nginx -s reload
#在另外一台服务器访问：
[root@localhost ~]# ssh 192.168.2.10 -p 6666
root@192.168.2.10's password:
Last login: Sun Apr 26 03:31:45 2020 from www.ys.com
#可以看到已经登上2.20服务器上了
[root@bogon ~]# ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:2c:72:99 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.20/24 brd 192.168.2.255 scope global noprefixroute ens33
valid_lft forever preferred_lft forever
inet6 fe80::7e7a:cabd:3b11:a545/64 scope link noprefixroute
valid_lft forever preferred_lft forever

复制代码

科普文：深入明确负载平衡（四层负载平衡、七层负载平衡）

本帖子中包含更多资源

浏览过的版块