标签：bank jpg 维护 实时 处理 大量 关机 场景 共享
对于云计算行业来说，云服务的可用性和可扩展性是的检测其服务质量的重要标准，也是最受用户关注的两大难题。各云计算厂商针对容灾、升级等需求的解决方案，最能够体现其底层架构的实力。腾讯云基于基础架构的优势，为分期乐、微信红包等平台提供技术支持，可以完美满足如下三点需求：
1. 高可用能力，容灾能力强，升级不停服
2. 可扩展性强，功能丰富，性能超高
3. 避免重复造轮子，性价比之王
近期，针对一些客户对腾讯云产品可用性的问询，腾讯云基础产品团队对负载均衡产品的原理做出详细阐述，并希望通过对腾讯负载均衡集群底层架构的实现的讲解分析，揭示其强劲性能、高可用性的根源所在。
单台web服务器如apache、nginx往往受限于自身的可扩展硬件能力。在面对海量的web请求时，需要引入load balance将访问流量均匀的分发到后端的web集群，实现接入层的水平扩展。
Tencent所有业务的负载均衡都是基于内部Tencent GateWay实现的，运行在标准x86服务器上，优点包括：自主研发、代码可控。Tencent GateWay对外的版本为Cloud load balance，是多机active部署的，通过BGP发布VIP、local adress路由、同步DNS信息等，实现集群负载通过路由OSPF将流量分发到不同的服务器上。
Load balance作为IT集群的出入口、咽喉要塞。开发商使用负载均衡器看中的无非是高可用能力、分发性能以及产品功能的丰富程度，咱先从高可用说起。
集群容灾，简单来说就是一个集群中一台服务器倒掉不会影响整个集群的服务能力。LVS是国内厂商常用的开源框架，常用Keepalived完成主备模式的容灾。有3个主要缺点：
1、主备模式利用率低。一个集群同时只有一半的服务器在工作，另外一半的机器处于冷备状态，主节点不可用之后的切换速度相对较慢；
2、横向平行扩展能力差。LVS服务集群扩展后转发效率大幅下降；
3、依赖的VRRP协议存在脑裂的风险，需引入第三方仲裁节点，在金融领域、跨园区容灾领域备受挑战。
CLB在设计之初就考虑到这个问题，采用自研的ospf动态路由协议来实现集群的容灾，若一台机器倒掉，ospf协议可以保证在10s以内把机器从集群中剔除。
CLB一个集群放在两个接入交换机下，并且保证跨机架的容灾，这样保证在即便有单边的交换机出故障或者单边机架掉电时，本集群的服务不受影响。同事实现了集群内session连接定期同步。这样在别的服务器接管故障机器的包时，client端的用户体验不受影响（如未登录的账户，在电商购物车里的未付款商品不丢失）
为了满足金融核心客户，24小时核心业务持续服务的要求。腾讯云负载均衡已在各金融专区（region）部署了多可用区（zone）容灾套件，从路由器、交换机和服务器以及布线是全冗余的，任意一个路由器、交换机或者服务器接口挂掉之后，流量会从冗余组件提供服务。
当client端请求，经过CLB代理，访问到后端CVM时，负载均衡的源 ip、目的ip、转发策略、会话保持机制，健康探测机制等业务配置。会实时的同步到另一个zone的集群。当主可用区的机房故障、不可用时，负载均衡仍然有能力在非常短的时间内（小于10s）切换到另外一个备可用区的机房恢复服务能力，而业界产品的切换时间一般在分钟级别。当主可用区恢复时，负载均衡同样会自动切换到主可用区的机房提供服务。目前包括webank、富途证券等金融开发商已启用跨园区容灾能力。
容灾演练实测：
1、协议切换(模拟交换机、CLB集群任何一层故障导致整个机房外网LB不可用)，切换时间ping丢包不超过1秒，但长链接会瞬断，结果符合预期
2、在高可用机房的LB外网完全瘫痪发生切换，恢复后不主动回切，过程中瘫痪机房的任何操作不应影响另外一边，结果符合预期
3、模拟（与CLB开发商沟通好以后）流量回切操作，流量回切时间ping丢包不超过1秒，但长链接发生瞬断，结果符合预期
CLB内核升级、Linux内核缺陷、安全漏洞等原因，免不了要做后端集群的重启升级，如果服务器每年由于维护等原因重启一次，1小时的恢复时间就已经达不到99.99%的可用性了。
目前CLB已能做到客户无感知的，完成服务器升级。升级时会选取集群一半负载均衡器，停掉OSPF协议，实行“温暖关机”。将其权重设置为0，从而保证数据包不会在经过这几台LB。另一半LB集群会接管预备关机LB的流量，集群内连接同步，负责接管的LB上具有全量的连接信息，连接不会中断。升级完成后的LB将重新启动ospf，加入集群，正常服务。
腾讯云负载均衡内部实现，利用了intel DPDK提供的高性能多核开发框架、hugepage内存管理及ring buffer共享队列方案，CLB团队将DPDK常见的逻辑设计框架run-to-completion与pipeline结合。极大提升了流量分发的效率。
2017年1月28日，微信公布了用户在除夕当天收发微信红包的数量：142亿个，而其收发峰值也已达到76万每秒。面对亿级的用户数及百亿级的红包，系统的性能至关重要。而承载新年红包的手机QQ和微信都接入了腾讯云负载均衡集群，得到了有效的性能保障。CLB单集群可承受的TCP最大并发连接数超过1.2亿，处理峰值40Gb/s的流量，每秒处理包量（QPS）可达600万。为广大用户提供了流畅、愉快的抢红包体验，实现了除夕夜系统零故障。
CLB性能上最大的一个难题是如何提升HTTPS的效率。同样的物理设备下cpu满负载，nginx SSL完全握手的性能不到普通HTTP性能的10%，如果说HTTP的性能是QPS 1万，HTTPS可能只有几百。为什么会这么低呢？
1、主要是RSA算法，它对性能的影响占了75%左右；
2、ECC椭圆曲线如果使用最常用的ECDHE算法，这部分约占整体计算量的7%；
3、对称加解密和MAC计算，它们对性能影响比较小，是微秒级别的。
有了这些分析结论，优化的方向就很明确了：
1、减少完全握手（采用分布式session cache、全局Session ticket、自定义session ticket）
2、RSA异步代理计算
3、对称加密优化
经过以上努力CLB团队通过异步代理、减少完全握手等方式，释放了CPU负载，。经过优化后，https请求的访问时延与http请求相差无几。单集群的单台云服务器完全握手性能可达到65000QPS，长连接时单台服务器性能可以达到300000QPS。完美的支撑了红包业务对SSL卸载的性能要求
我们来看看另一个case。分期乐一家专注于大学生分期购物的在线商城及金融服务提供商，提供分期贷款和还款服务。原分期乐（fenqile.com）的电商门户，有三十多个业务模块，通过多个二级域名、公网IP来分隔业务模块。门户的日PV超过亿次，峰值带宽超过5GB。
随着访问量的增多，其自建的nginx负载均衡集群已无法承载海量的请求，频繁出现丢包、SSL卸载慢等额问题。为了保证其业务在九月开学大促、双十一大促中平稳运行，分期乐引导部分流量到云端架构中，通过负载均衡进行业务整合：
为了实现业务分离，分期乐使用七层负载均衡获取HTTP/HTTPS头部信息，并根据企业业务的实际需要，将请求路由到不同的后端服务器集群，从而让负载均衡基于内容进行路由转发。此外，采用了细致到转发组级别的健康检查，具有更强灵活性，满足更多业务场景。
分期乐业务架构中，通过自定义域名/URL，实现了基于内容的路由转发。根据业务类型，分期乐配置了a.fenqile.com/image 和a.fenqile.com/text 两个URL路径。通过识别请求内容，将后缀带有/image的请求转发到后端服务器群组1，并将后缀带有/text的请求转发到后端服务器群组2，从而保证了流量分发到不同的服务器群组中，减轻单个节点的负载。原来以上配置都需要在自建的nginx location中配置完成，转发请求时消耗大量的cpu资源，现在交给CLB就好了。
CLB同时提供多元化的重定向能力，可以满足电商的两种场景：A.浏览器发起的http请求，强制转换为https请求，加密更可靠。B.电商中商品更替、库存售罄、后端某服务器负载过高（限制连接数、请求）等场景，常见的做法是直接拉黑页面，给client端返回404、503。但这种体验太差了，CLB支持智能重定向，将超负载的请求，转发到其它页面，如门户首页。
迁移上云从不是一蹴而就的，腾讯云强大的专线互联能力，满足客户逐步从自建IDC将业务迁移上云的能力：
a.分期乐首先逐步将业务迁移到云端，例如mall.fenqile.com这个域名会同时部署在自建idc及腾讯云负载均衡集群中。首先通过weight权重的配比，将30%的流量迁移到腾讯云，70%的流量回IDC。在稳定运营后，再逐步增加腾讯云端的权重，替换原有数据中心IDC的服务。
b.当业务流量增大时，clb负载均衡无性能瓶颈，需要注意的时候后端的apache、nginx接入层需要做到无状态，并借用autoscaling能力实现弹性伸缩。
大促当天，CLB支持了海量的并发访问，分期乐门户的日PV超过亿次，峰值带宽超过5Gbps，支持了过亿的交易额。
传统的硬件负载均衡，以F5为例，其缺点非常明显， 从商业角度来说，硬件负载均衡产品过于昂贵，高端产品动辄五十万甚至数百万的价格对于用户是几乎不可承受的负担，如下图所示：
从使用角度来说，硬件负载均衡是黑盒，有BUG需要联系厂商等待解决，时间不可控、新特性迭代缓慢且需资深人员维护升级，也是变相增加昂贵的人力成本。
腾讯云在2015年起，将内部的负载均衡服务，正式对外商业化服务，单实例1个月的开销为30元（费用节省达99%以上）。您还有什么理由购买硬件负载均衡，或使用开源方案造轮子呢？快来试用吧：）
相关推荐
标签：bank jpg 维护 实时 处理 大量 关机 场景 共享
原文地址：http://www.cnblogs.com/qyun/p/6657543.html
