文本网站代码空两格怎么做,深圳建设工程交易中心网站,品牌广告策划方案,网站建设设计服务一、写在前面
最近在进行线上监控检查时#xff0c;我遇到了两个超出预期的案例。首先#xff0c;网关层的监控数据与应用实际监控数据存在不一致性#xff0c;尤其是max有较大的差异#xff0c;详见如下图。其次在某个应用中#xff0c;通过httpclient请求某域名时发现只…一、写在前面
最近在进行线上监控检查时我遇到了两个超出预期的案例。首先网关层的监控数据与应用实际监控数据存在不一致性尤其是max有较大的差异详见如下图。其次在某个应用中通过httpclient请求某域名时发现只有一台机器持续出现Read timed out的异常错误。 鉴于这种情况我分析了客户端请求到应用集群之间的完整链路。用户发起域名请求时客户端通过本地DNS没有解析记录粥查询如权威DNS发起查询请求获取域名关联的VIP接着发起到负载均衡LB的请求LB接收到请求后根据配置的LB策略如轮询、最小连接、IP源hash等决定将请求转发给后端的服务实例。后端服务器接收到请求后应用服务器处理请求并生成响应数据然后再逆向传递。 二、负载均衡
首先聊聊什么是负载均衡。负载均衡LBLoad Balance)是一种技术解决方案用来在多个资源一般是服务器中分配负载达到最优资源使用避免过载。最常见的LB是四层TCP负载和7层HTTP负载。四层负载均衡是基于IPPort实现通过网络层的IP地址VIP)然后加上运输层的端口号来决定哪些流量需要做负载均衡主要工作是转发在接收到客户端的流量以后通过修改数据包的地址信息将流量转发到应用服务吕。七层负载均衡器除了支持四层负载均衡以外还要分析应用层的信息如HTTP协议URI或Cookie信息可以理解应用协议七层负载均衡会与客户端建立一条完整的连接并将应用层的请求流量解析出来再按照调度算法选择一个应用服务器并与应用服务器建立另外一条连接将请求发送过去因此它主要工作是代理 。
•四层负载均衡在传输层即网络层对网络流量进行负载均衡的一种手段 以常见的TCP为例负载均衡设备在接收到第一个来自客户端的SYN请求时通过报文中的IPPort根据预设的负载均衡算法如轮询、加权轮询、最小连接等选择一个最佳的服务器当然在转发时会修改报文中目标IP地址直接转发给后端服务器。TCP的建连是客户端与服务器直接建立的LB只是起到一个类似路由器转发动作。
4层负载均衡主要通过检查传输层的相关信息来源请求流量的转发性能较高适应于TCP/UDP等传输协议。然而由于不了解应用层信息因此无法做到智能化的请求分发只能基于基本信息进行转发决策。
•七层负载均衡在应用层对网络流量进行负载均衡的一种方案 七层负载均衡也称为内容交换主要通过报文中真正有意义的应用层内容加上负载均衡设备设置的服务器选择方式决定最终选择的内容服务器。以常见的TCP为例LB设备如果要根据应用层内容选择服务器只能先代理最终的服务器和客户端建立连接后才可能接受到客户端发送的真正报文内容然后再根据报文中的特写字段LB设备设置的服务器选择方式如轮询、加权轮询、最小连接等决定最终 选择的内部服务器。由此可见LB和客户端以及服务器会分别独立建立TCP连接与四层模式的LB相比 处理能力必然要低一些。
从技术原理上看它可以对客户端的请求和服务器的响应进行任何意义上的修改极大提高了应用系统在网络层的灵活性另一方面就是安全性特别是常见的SYN Flood攻击SYN攻击可以在LB设备上截止不会影响后台服务器的正常运营另外LB设备可以在七层层面设定多种策略过滤特写报文例如SQL注入等应用层面的特写攻击手段从应用层面进一步提高系统整体安全。由于深入到应用层对请求处理更加精细但相应地也会增加负载均衡的处理开销。
下图是经典四层和七层架构和解析包的关系。 三、LB模式
LB模式含义有
•fullnat 代表dpdkkeepalive实现的4层tcp集群负载均衡软件为lvs
•nginx代表nginx实现的可同时提供4层tcp和7层http服务负载均衡软件为jfe基于nginx二次开发
•ha代表haproxy实现的可同时提供4层tcp和7层http服务负载均衡软件为haproxy.
这里强调一下实例冷备时不同LB模式的影响。如果VIP的LB模式是fullnat冷备时当前已有的链接会立刻被断开其他模式如nginx、ha将不会转发新的请求到冷备设备但已建立的链接不影响直至链接正常断开为止。因此需要强调的茵LB模式为fullnat在冷备应用实例后立即部署对业务会有短暂的影响相反在fullnat模式下影响几乎可以忽略不计。 四层负载均衡DR/FULLNAT基于DPDK的DLVSDPDK全称Data Plane Development Kit是Intel提供的数据平面开发工具集专注于网络应用中数据包的高性能处理其提供基于TCP的应用程序代理。
七层负载均衡HA 基于HAProxy 二次开发支持配置热加载生效、单机QPS可达5w其提供基于TCP和HTTP的应用程序代理。
七层负载均衡Nginx基于Nginx 二次开发支持单元化、物理网关隔离、实例变更热加载等功能单机QPS可达3w其提供基于TCP和HTTP的应用程序代理。
对比项四层负载均衡FULLNAT七层负载均衡HA七层负载均衡Nginx产品定位·强大的四层处理能力 ·聚焦TCP协议 ·面向网络层交付·强大的七层处理能力 ·聚焦HTTP应用层协议 ·面向应用层交付·强大的七层处理能力 ·聚焦HTTP、HTTPS应用层协议 ·面向应用层交付业务场景·低延迟10ms、高并发1Wqps、高带宽1Gbps各类型业务·基于HTTP协议接口类业务不适合需要HTTPS的WEB网页类业务·基于HTTP协议的WEB网页类业务、尤其需要支持HTTPS访问的业务
四、解决方案与调优实践
在之前的讨论中我已经探讨了负载均衡的核心概念、四层与七层LB的差异以及LB模式。基于这些讨论本节重点关注如何通过具体的解决方案和调优实践来应对线上监控检查中遇到的问题包括风关层与应用层监控数据不一致以及Read timed out异常。
•场景一网关层的监控数据与应用实际监控数据存在不一致性
前面已经详细分析了四层LB与七层LB的差异。对于不同的协议在性能上TCP比HTTP快毕竟7层监听经过LVS后还需要更长的链路但不会达到max1kms的影响。那影响性能的另一个因素就是运营商到集群的跨机房调用。跨机房调用会导致网络延迟和稳定性由于物理距离的增加数据在传输过程中经过路由器和交换机数量增多网络RTT会显著增加。上图中的经色箭头就是调整同机房调用后的时刻可以看到max性能显著提升。 •场景二单台机器HTTP请求域名时Read Timed Out异常
在线上应用环境中通过HttpClient请求某个域名时发现只有一台机器持续出现“Read Timed Out”的异常错误。这种情况首先让人疑惑的是为什么只有一台机器会遇到这个问题而其他机器却能正常工作 经过详细的排查和分析我发现了几个关键因素导致了这个问题的出现
1) 、网络问题首先出现timeout的原因是因为请求的域名下的某台机器网络存在问题。
2)、长连接机制HttpClient默认使用长连接Keep-Alive的方式进行通信。这种方式在大多数情况下可以提高性能因为它减少了频繁建立和断开连接的开销。然而当目标服务器存在网络问题时这种长连接机制可能会导致持续的超时问题。
3、源地址Hash策略根本原因在于集群负载均衡算法采用了源地址Hash策略。这种策略根据请求的源地址来分配请求到后端服务器旨在保持客户端与特定服务器的会话连续性。因此如果某台后端机器遇到了网络问题那么所有被路由到这台机器的请求都会受到影响。业务ip的数量小于或接近域名对应的ip数量
当然解决方案很简单。一方面设置合理的超时时间调整负载均衡策略如轮询最小连接等。
五、写在最后
线上监控当发现问题解决问题后追根溯源也是非常重要的。不能忽视线上的任何问题无论它们是多少微小。每一个异常都有可能是更深层次问题的征兆。通过建立一套完善的监控体系实时捕捉异常数据结合深入的技术分析和理解就能够及时定位问题并采取相应措施。这不仅仅是为了解决眼前的问题更是为了系统的长期健康和可持续发展。追踪溯源的过程虽然可能耗时费力但它是确保我们服务可靠、稳定和高效的基石。
