理想负载均衡技术交流.pptx

;目录;管理性… 新业务、应用越来越多、简化因为众多的单点的安全产品带来的管理和运维的复杂度的问题，;分层架构：整个架构是分层的分布式的架构，纵向包括CDN，负载均衡/反向代理，web应用，业务层，基础服务层，数据存储层。水平方向包括对整个平台的配置管理部署和监控;负载均衡方案概述;支持基于tcp/ip连接的任务分配（4层负载均衡） 支持基于应用内容的任务分配（7层负载均衡） 支持负载均衡器自身的横向扩展 支持web集群的动态伸缩;服务发现 通过监听器主动发现服务器部署应用的四层和七层负载均衡服务，通过管理控制台集中管理。四层负载（ali-LVS）和七层负载tengine服务通过zookeeper注册到管理控制台。;目录;;探测模块功能： 实时动态加载节点：应用发布时注册到Zookeeper，由探测模块实时通知IPVS 动态反馈负载均衡：根据综合负载和当前权值，使用加权轮叫调度算法来调度新的请求连接 ;1、当用户向负载均衡调度器（Director Server）发起请求，调度器将请求发往至内核空间 2、PREROUTING链首先会接收到用户请求，判断目标IP确定是本机IP，将数据包发往INPUT链 3、IPVS是工作在INPUT链上的，当用户请求到达INPUT时，IPVS会将用户请求和自己已定义好的集群服务进行比对，如果用户请求的就是定义的集群服务，那么此时IPVS会强行修改数据包里的目标IP地址及端口，并将新的数据包发往POSTROUTING链 4、POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器，那么此时通过选路，将数据包最终发送给后端的服务器;4层负载均衡-LVS/NAT;4层负载均衡-LVS/DR;1、当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP，目标IP为VIP 。 2、PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链 3、IPVS比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层IP报文，封装源IP为为DIP，目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP，目标IP为RIP 4、POSTROUTING链根据最新封装的IP报文，将数据包发至RS（因为在外层封装多了一层IP首部，所以可以理解为此时通过隧道传输）。 此时源IP为DIP，目标IP为RIP 5、RS接收到报文后发现是自己的IP地址，就将报文接收下来，拆除掉最外层的IP后，会发现里面还有一层IP首部，而且目标是自己的lo接口VIP，那么此时RS开始处理此请求，处理完成之后，通过lo接口送给eth0网卡，然后向外传递。 此时的源IP地址为VIP，目标IP为CIP 6、响应报文最终送达至客户端;客户端属性 请求任意字段 Language URI Cookies HOST HTTP-Head;探测模块：应用负载探测，应用状态探测，结果上报应用管理器 应用管理平台：控制应用、根据应用负载设定通知云平台调整资源;技术实现说明： Session存在分布式共享池内，用户请求可以由负载均衡器随机分配服务器，访问在各个服务器之间切换无需重复生成session。 Session数据存在分布式共享池内，共享池由Redis集群来实现，不会出现单点故障。 Session存储在redis服务器，以sessionId为key，控制redis的key过期时间管理session的失效时间，客户端超过一定时间不再访问此session，则session到期自动失效。;流量控制：tengine流量编程式控制;;产品界面-负载均衡;产品界面-LVS集群;产品界面-Tengine流量编程控制;产品界面-Tengine集群;负载均衡性能指标：测试部署图;性能指标：单台tengine配置的性能测试;性能指标：LVS+tengine扩展性能测试;【 测试分析】 从此次测试可以看出，对同一个应用，完成同样次数的请求，经过varnish缓存比直连应用的提升较为明显，随着请求数增加，提升的幅度也增加。 100W次请求提升在9.6% 200W次请求提升在15.8% 300W次请求提升在32.8%;【 测试分析】 1、该测试所采用的应用仅包含一个113B大小的html文件。 2、由图一可看出对于单台pcserver来说，随着压力的增加，TPS提升。当TPS达到4W左右时，提升变得缓慢，达到瓶颈 3、由图二可分析，由于测试应用为纯静态的html文件，所以对服务器的CPU和内存消耗极小，可知瓶颈并不是由CPU或内存造成。;目录;My SQL Slave;负载均衡-容器集群;负载均衡-分布式WEB;谢 谢！