负载场景及解决方案

本文列举了几个负载场景并提出了相应的负载方案。

1、不同的负载场景

我们知道负载均衡层的作用是“将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上”,那么不同的业务场景需要的负载均衡方式又是不一样的,架构师还要考虑架构方案的成本、可扩展性、运维难易度等问题。下面我们先介绍几种典型的不同业务场景,大家也可以先想一下如果是您,会怎么架设这些场景的负载均衡层。

需要注意的是,这个系统的文章,我们都将使用这几个典型的业务场景来讲解系统架构的设计递归设计。在后续几篇介绍负载层架构的文章中,我们也将通过这几个典型的业务场景讲解负载层的架构方案。

1.1、负载场景一

这是一个国家级物流园区的货运订单和物流管理系统。在物流园区内的货运代理商、合作司机(货运车辆)、园区管理员和客服人员都要使用这套系统。每日RUV在1万人次,日PV在10万左右。甲方总经理使用这套系统的原有是抱着“试一下移动互联网对物流产品是否能起到提高效率的作用”。可以看出整个系统基本上没有访问压力,甲方对您设计的系统只有一个要求:能够保证系统以后的功能和性能扩展性。

lb_1

1.2、负载场景二

效果不错!在第一版系统架设后的6个月,货场丢货的情况大大减少,并且由于货车在途情况的监控,按时到达率也显著提升,货车司机也反映由于整个货场货车信息都是共享的,货车的待货时间也明显缩短。在这期间物流园中越来越多的货运代理商、货车司机都开始使用这套系统了,整个系统的访问量成线性增长。

物流园的总经理对整个系统的作用感到满意,决定扩大系统的使用范围,并增加新的功能。经过讨论甲方最终决定把整套系统开放给货主:或者可以在系统上查看货运代理商的线路报价、线上通知代理商上门取货、监控目前自己货品的运输状态、了解第三方签收情况。初步估计系统的日RUV将达到10万,日PV将突破50万。

lb_2

1.3、负载场景三

一年后,赞不绝口的大宗货品运输服务质量终于传到了政府领导的耳朵里。省里分管运输的领导亲自领队到物流园区参观考察,最终决定由省政府牵头,各地方政府参与,将这套管理办法在整个省级范围进行推广使用。全省10家大型物流园和50家二级物流园中的上万货运代理商、散落省内的零散代理商、10万个人/企业货主、40万优等资质车源共同接入系统。

新的功能上,增加了费用结算和运费保障功能,从货主预付款开始到第三方确认收货的整个环节都进行费用管理。为了保证线上收货环节的顺利,新版本中还增加了代理商之间的合作收货功能。新系统的日RUV将超过50万,日PV将突破250万。

lb_3

1.4、负载场景四

服务效应、经济效应、口碑效应不断发酵,经过近两年多的发展,目前这套系统已经是省内知名的物流配送平台,专门服务大宗货运物流。联合政府向全国推广服务的时机终于到来。预计全国1000多个物流园区,50万左右物流代理商,500万货运车辆、数不清的个人和企业货主都将使用该系统。预估的RUV和PV是多少呢?无法预估,如果按照全国32省来进行一个简单的乘法,是可以得到一个大概的值(50万 * 32 = 1500万+;500万 * 32 = 1.5亿+,已经超过了JD.com的平峰流量),但是各省的物流业规模是不一样的,从业者数量也不一样,所以这样的预估并不科学。而且再这样的系统规模下我们应该更过的考虑系统的峰值冗余。

业务功能的情况:为了保证注册货车的有效性,您所在的公司被政府允许访问政府的车辆信息库,在车辆注册的过程中进行车辆信息有效性的验证(第三方系统接口调用,我们并不知道第三方系统是否能够接收一个较高水平的并发量,所以这个问题留给我我们的架构师,我们将在业务层讲解时进行详细的描述)。

1.5、沉思片刻

看到这里,我们已经将几个递进的业务场景进行了详细的说明(甚至在后文中我们讨论业务层、业务通信层、数据存储层时所涉及的业务场景也不会有什么大的变化了)。看客们看到这里,可以稍作休息,先想想如果是您,您会如何搭建负载层,甚至整个系统的顶层架构。

由于整个系统的性能除了和硬件有关外,业务层的拆分规则,代码质量,缓存技术的使用方式,数据库的优化水平都可能对其产生影响。所以: 我们在讨论负载层的几篇文章中,我们要假设系统架构中各层的设计都没有对系统性能产生瓶颈

如果您已经思考好了,那么可以继续看以下的内容。

2、负载方案构想

2.1、解决方案一:独立的Nginx/Haproxy方案

很显然,第一个业务场景下,系统并没有多大的压力就是一套简单业务系统,日访问量也完全没有“有访问压力”这样的说法。但是客户有一个要求值得我们关注:要保证系统以后的功能和性能扩展性。为了保证功能和性能扩展性,在系统建立之初就要有一个很好的业务拆分规划,例如我们首先会把用户信息权限子系统和订单系统进行拆分,独立的车辆信息和定位系统可能也需要拆分出来。

这也是我们在系统建立时就要引入负载均衡层的一个重要原因。也是负载均衡层的重要作用之一。如下图所示:

lb_4

可以看出,这时负载均衡层只有一个作用,就是按照设定的访问规则,将访问不同系统的请求转发给对应的系统,并且在出现错误访问的情况下转发到错误提示页面。

2.2、解决方案二:Nginx/Haproxy + Keepalived方案

此后,系统的访问压力进一步加大,系统的稳定性越来越受到我们的关注。所以在单节点处理还能满足业务要求的情况下,我们为负载层(还有各层)引入热备方案,以保证一个节点在崩溃的情况下,另一个节点能够自动接替其工作,为工程师解决问题赢得时间。如下图所示:

lb_5

2.3、解决方案三:LVS(DR)+ Keepalived+ Nginx方案

在第三版本架构方案中,为了保证负载层足够稳定的状态下,适应更大的访问吞吐量还要应付可能的访问洪峰,我们加入了LVS技术。LVS负责第一层负载,然后再将访问请求转发到后端的若干台Nginx上。LVS的DR工作模式,只是将请求转到后端,后端的Nginx服务器必须有一个外网IP,在收到请求并处理完成后,Nginx将直接发送结果到请求方,不会再经LVS回发(具体的LVS工作原理介绍将在后文中详细介绍)。

lb_6

这里要注意的是:

2.4、解决方案四:DNS轮询 + LVS(DR)+ Keepalived + Nginx方案

lb_7

场景四中,为了满足平均上亿的日PV访问,在对业务进行外网暴露的基础上,我们在互联网的最前端做了一个DNS轮询。然后将(对用户信息系统)访问压力首先分摊到两个对称LVS组上,再由每个组向下继续分拆访问压力。

注意上图的负载层方案的不同:

方案扩展到了这一步,LVS层就没有必要再进行扩展新的节点了。为什么呢?根据您的业务选择的合适的LVS工作模式,两个LVS节点的性能足以支撑地球上的所有核心WEB站点。如果您对LVS的性能有疑惑,请自行谷歌百度。这里提供了一份参考资料:《LVS性能,转发数据的理论极限》

3、术语说明

Table of Contents