自己怎么做网站模块,本地黄页小程序,对海尔网站建设水平的评价,怎么做微信小程序平台概叙
网络模型#xff1a;OSI七层模型、TCP/IP四层模型、现实的五层模型 应用层#xff1a;对软件提供接口以使程序能使用网络服务#xff0c;如事务处理程序、文件传送协议和网络管理等。#xff08;HTTP、Telnet、FTP、SMTP#xff09;
表示层#xff1a;程序和网络之…概叙
网络模型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 BalanceCheck Point Firewall-1 Connect ControlKeepalive IPVS、Nginx、apache、LVS等它的优点是基于特定环境配置简单使用灵活成本低廉可以满足一般的负载均衡需求。 软件解决方案缺点也较多因为每台服务器上安装额外的软件运行会消耗系统不定量的资源越是功能强大的模块消耗得越多所以当连接请求特别大的时候软件本身会成为服务器工作成败的一个关键软件可扩展性并不是很好受到操作系统的限制由于操作系统本身的Bug往往会引起安全问题。
硬件负载均衡 硬件负载均衡解决方案是直接在服务器和外部网络间安装负载均衡设备这种设备通常是一个独立于系统的硬件我们称之为负载均衡器。由于专门的设备完成专门的任务独立于操作系统整体性能得到大量提高加上多样化的负载均衡策略智能化的流量管理可达到最佳的负载均衡需求。 负载均衡器有多种多样的形式除了作为独立意义上的负载均衡器外有些负载均衡器集成在交换设备中置于服务器与Internet链接之间有些则以两块网络适配器将这一功能集成到PC中一块连接到Internet上一块连接到后端服务器群的内部网络上。
软、硬件负载均衡的对比 软件负载均衡的优点是需求环境明确配置简单操作灵活成本低廉效率不高能满足普通的企业需求缺点是依赖于系统增加资源开销软件的优劣决定环境的性能系统的安全软件的稳定性均会影响到整个环境的安全。 硬件负载均衡优点是独立于系统整体性能大量提升在功能、性能上优于软件方式智能的流量管理多种策略可选能达到最佳的负载均衡效果缺点是价格昂贵F5硬件服务器不低于20万/台。
OSI网络层次负载均衡 按照OSI七层模型划分方式根据采用的设备对象区分、根据位于OSI中不同层次的划分这里我们主要讲根据OSI中的层次划分。 二层负载均衡mac地址数据链路层使用虚拟MAC地址方式外部请求流量经过虚拟MAC地址负载均衡收到流量请求后分配后端实际的MAC地址进行响应。
三层负载均衡ip地址网络层使用虚拟ip地址方式外部请求流量经过虚拟IP地址负载均衡收到流量请求后分配后端实际的IP地址进行响应。
四层负载均衡tcp、udp传输层使用IPPORT接收外部流量请求转发到对应的机器上。
七层负载均衡http应用层使用虚拟的URL或IP地址接收外部流量请求转发到对应的处理服务器。1二层负载均衡一般是用虚拟mac地址方式外部对虚拟MAC地址请求负载均衡接收后分配后端实际的MAC地址响应2三层负载均衡一般采用虚拟IP地址方式外部对虚拟的ip地址请求负载均衡接收后分配后端实际的IP地址响应3四层负载均衡在三次负载均衡的基础上用 ipport 接收请求再转发到对应的机器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等等常见例子有LVSF5。 七层负载均衡 七层的负载均衡就是基于虚拟的URL或主机IP的负载均衡在四层负载均衡的基础上没有四层是绝对不可能有七层的再考虑应用层的特征比如同一个Web服务器的负载均衡除了根据VIP加80端口辨别是否需要处理的流量还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。 举个例子如果你的Web服务器分成两组一组是中文语言的一组是英文语言的那么七层负载均衡就可以当用户来访问你的域名时自动辨别用户语言然后选择对应的语言服务器组进行负载均衡处理。 对应的负载均衡器称为七层交换机L7 switch除了支持四层负载均衡以外还有分析应用层的信息如HTTP协议URI或Cookie信息实现七层负载均衡。此种负载均衡器能理解应用协议常见例子有 haproxyMySQL 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和端口删除掉。
服务发现的角度 针对场景1API 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宕机导致整个服务不可用也可以使用 KeepalivedNginx 来实现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 后端服务器1192.168.2.20 后端服务器2192.168.2.30 前端服务器主要配置upstream和proxy_pass upstream 主要是配置均衡池和调度方法。 proxy_pass 主要是配置代理服务器ip或服务器组的名字。 proxy_set_header 主要是配置转发给后端服务器的Host和前端客户端真实ip。 Nginx服务器配置
[rootbogon 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;
}
}
[rootbogon 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;}[rootbogon nginx]# /usr/local/nginx/sbin/nginx -s reload
访问验证
[rootlocalhost ~]# while true;do curl 192.168.2.10;sleep 2;done
this is 2.20 pagethis is 2.30 page
this is 2.20 pagethis is 2.30 page
this is 2.20 pagethis is 2.30 page
#可以看到后端服务器非常平均的处理请求。
2.轮询加权重
upstream web {
server 192.168.2.20 weight3;
server 192.168.2.30 weight1;
}
默认是weight1
[rootbogon nginx]# /usr/local/nginx/sbin/nginx -s reload
访问验证
[rootlocalhost ~]# 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 pagethis is 2.30 page
this is 2.20 page
this is 2.20 page
this is 2.20 pagethis 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 weight1 max_fails3 fail_timeout9s;
#先将2.20这台nginx关了。
server 192.168.2.30 weight1;
}
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;
}
}
[rootbogon nginx]# /usr/local/nginx/sbin/nginx -s reload
# 在这里我们将超时时间设置为9s最多尝试3次
这里要注意尝试3次依然遵循轮询的规则并不是一个请求连接3次
而是轮询三次有3次处理请求的机会
访问验证
[rootlocalhost ~]# 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 weight1 max_fails3 fail_timeout9s;
#先将2.20这台nginx关了。
server 192.168.2.30 weight1;
}
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;
}
}
[rootbogon nginx]# /usr/local/nginx/sbin/nginx -s reload
再次测试访问验证
[rootlocalhost ~]# 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 weight1 max_fails3 fail_timeout9s;
server 192.168.2.30 weight1;
}
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;
}
}
[rootbogon nginx]# /usr/local/nginx/sbin/nginx -s reload
访问验证
[rootlocalhost ~]# while true;do curl 192.168.2.10;sleep 2;donethis is 2.30 pagethis is 2.30 pagethis is 2.30 pagethis is 2.30 pagethis is 2.30 pagethis is 2.30 page
[rootlocalhost ~]# 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;
}
[rootbogon 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 weight1 max_fails3 fail_timeout9s;
server 192.168.2.30 weight1;
}
备用服务器
upstream web {
server 192.168.2.20 weight1 max_fails3 fail_timeout9s;
server 192.168.2.30 weight1 backup;
}
# 2.30的服务器做备用服务器只有在2.30得服务器不能提供服务时才会自动顶上,否则默认是不提供服务的。 Nginx实现四层负载均衡 前端服务器192.168.2.10 后端服务器1192.168.2.20 后端服务器2192.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
[rootlocalhost ~]# curl 192.168.2.10
this is 2.20 page
- 查看后端2.20日志
[rootbogon 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日志
[rootbogon nginx]# tail -1 /usr/local/nginx/logs/proxy.log
192.168.2.30 45420 TCP 200 [2020-04-25T19:23:3508:00] 192.168.2.20:80 760.001
端口转发
#在前端2.10配置
[rootbogon 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;
}
[rootbogon nginx]# /usr/local/nginx/sbin/nginx -s reload
#在另外一台服务器访问
[rootlocalhost ~]# ssh 192.168.2.10 -p 6666
root192.168.2.10s password:
Last login: Sun Apr 26 03:31:45 2020 from www.ys.com
#可以看到已经登上2.20服务器上了
[rootbogon ~]# ip add
1: lo: LOOPBACK,UP,LOWER_UP mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host lovalid_lft forever preferred_lft foreverinet6 ::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 1000link/ether 00:0c:29:2c:72:99 brd ff:ff:ff:ff:ff:ffinet 192.168.2.20/24 brd 192.168.2.255 scope global noprefixroute ens33valid_lft forever preferred_lft foreverinet6 fe80::7e7a:cabd:3b11:a545/64 scope link noprefixroute valid_lft forever preferred_lft forever
