架构设计：负载均衡层设计方案（1）——负载场景和解决方案

在上一篇《标准Web系统的架构分层》文章中，我们概述了WEB系统架构中的分层架设体系。介绍了包括负载均衡层、业务层、业务通信层、数据存储层的作用和存在意义。从本片文章開始，我们将首先具体解说负载均衡层的架构原理和选型场景。

1、不同的负载场景

我们知道负载均衡层的作用是“将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上”。那么不同的业务场景须要的负载均衡方式又是不一样的，架构师还要考虑架构方案的成本、可扩展性、运维难易度等问题。

以下我们先介绍几种典型的不同业务场景。大家也能够先想一下假设是您，会怎么架设这些场景的负载均衡层。

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

1.1、负载场景一

这是一个国家级物流园区的货运订单和物流管理系统。

在物流园区内的货运代理商、合作司机（货运车辆）、园区管理员和客服人员都要使用这套系统。每日RUV在1万人次，日PV在10万左右。甲方总经理使用这套系统的原有是抱着“试一下移动互联网对物流产品能否起到提高效率的作用”。

能够看出整个系统基本上没有訪问压力。甲方对您设计的系统仅仅有一个要求：能够保证系统以后的功能和性能扩展性。

1.2、负载场景二

效果不错！

在第一版系统架设后的6个月。货场丢货的情况大大降低，而且因为货车在途情况的监控，按时到达率也显著提升，货车司机也反映因为整个货场货车信息都是共享的。货车的待货时间也明显缩短。

在这期间物流园中越来越多的货运代理商、货车司机都開始使用这套系统了，整个系统的訪问量成线性增长。

物流园的总经理对整个系统的作用感到惬意，决定扩大系统的使用范围。并添加新的功能。

经过讨论甲方最终决定把整套系统开放给货主：或者能够在系统上查看货运代理商的线路报价、线上通知代理商上门取货、监控眼下自己货品的运输状态、了解第三方签收情况。初步预计系统的日RUV将达到10万。日PV将突破50万。

1.3、负载场景三

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

新的功能上，添加了费用结算和运费保障功能，从货主预付款開始到第三方确认收货的整个环节都进行费用管理。

为了保证线上收货环节的顺利，新版本号中还添加了代理商之间的合作收货功能。新系统的日RUV将超过50万，日PV将突破250万。

1.4、负载场景四

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

业务功能的情况：为了保证注冊货车的有效性，您所在的公司被政府同意訪问政府的车辆信息库，在车辆注冊的过程中进行车辆信息有效性的验证（第三方系统接口调用。我们并不知道第三方系统能否够接收一个较高水平的并发量，所以这个问题留给我我们的架构师。我们将在业务层解说时进行具体的描写叙述）。

1.5、沉思片刻

看到这里，我们已经将几个递进的业务场景进行了具体的说明（甚至在后文中我们讨论业务层、业务通信层、数据存储层时所涉及的业务场景也不会有什么大的变化了）。看客们看到这里，能够稍作歇息，先想想假设是您。您会怎样搭建负载层。甚至整个系统的顶层架构。

因为整个系统的性能除了和硬件有关外，业务层的拆分规则，代码质量，缓存技术的使用方式，数据库的优化水平都可能对其产生影响。所以：

我们在讨论负载层的几篇文章中，我们要假设系统架构中各层的设计都没有对系统性能产生瓶颈

假设您已经思考好了，那么能够继续看以下的内容。

2、负载方案构想

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

非常显然，第一个业务场景下，系统并没有多大的压力就是一套简单业务系统，日訪问量也全然没有“有訪问压力”这种说法。

可是客户有一个要求值得我们关注：要保证系统以后的功能和性能扩展性。

为了保证功能和性能扩展性，在系统建立之初就要有一个非常好的业务拆分规划。比如我们首先会把用户信息权限子系统和订单系统进行拆分，独立的车辆信息和定位系统可能也须要拆分出来。

这也是我们在系统建立时就要引入负载均衡层的一个重要原因。

也是负载均衡层的重要作用之中的一个。例如以下图所看到的：

能够看出，这时负载均衡层仅仅有一个作用，就是依照设定的訪问规则，将訪问不同系统的请求转发给相应的系统，而且在出现错误訪问的情况下转发到错误提示页面。

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

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

例如以下图所看到的：

2.3、解决方式三：LVS（DR）+ Keepalived+ Nginx方案

在第三版本号架构方案中，为了保证负载层足够稳定的状态下，适应更大的訪问吞吐量还要应付可能的訪问洪峰，我们添加了LVS技术。

LVS负责第一层负载，然后再将訪问请求转发到后端的若干台Nginx上。LVS的DR工作模式，仅仅是将请求转到后端。后端的Nginxserver必须有一个外网IP，在收到请求并处理完毕后。Nginx将直接发送结果到请求方，不会再经LVS回发（具体的LVS工作原理介绍将在后文中具体介绍）。

这里要注意的是：

• 有了上层的LVS的支撑Nginx就不再须要使用Keepalived作为热备方案。

  因为首先Nginx不再是单个节点进行负载处理，而是一个集群多台Nginx节点。另外LVS对于下后端的server自带基于port的健康检查功能；

• LVS是单节点处理的。尽管LVS是非常稳定的，可是为了保证LVS更稳定的工作，我们还是须要使用Keepalived为 LVS做一个热备节点。以防不时之需。

2.4、解决方式四：DNS轮询 + LVS（DR）+ Keepalived + Nginx方案

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

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

• 首先我们不在像前面的方案中。使用文件夹名切割业务系统了，而是直接将业务系统的訪问使用不同的二级域名进行拆分。

  这种变化有利于每一个业务系统都拥有自己独立的负载均衡层。

• 请注意上图中的细节。这个负载均衡层是专门为“用户信息子系统”提供负载均衡支撑的，而可能还存在的“订单子系统”、“车辆信息子系统”都会有他们独立的负载均衡层。

• 在LVS下方的Nginx服务能够实现无限制的扩展。相同的就像场景三种所给出的解决方式一样，Nginx本身不在须要Keepalived保持热备。而是所有交由上层的LVS进行健康情况检查。而即使有一两台Nginxserver出现问题。对整个负载集群来说问题也不大。

方案扩展到了这一步，LVS层就没有必要再进行扩展新的节点了。

为什么呢？依据您的业务选择的合适的LVS工作模式，两个LVS节点的性能足以支撑地球上的所有核心WEB站点。假设您对LVS的性能有疑惑，请自行谷歌百度。这里我们提供了一份參考资料：《LVS性能，转发数据的理论极限》http://www.zhihu.com/question/21237968

3、为什么没有独立的LVS方案

在下一篇文章《架构设计：负载均衡层设计方案（2）——LVS、keepalived、Nginx安装和核心原理解析》中我们将提到这个问题。

实际上通过本篇文章的架构演进分析。一些读者都能够看出端倪。

假设用一句话说明当中的原因，那就是LVS为了保证其性能对配置性有所牺牲，单独使用的话往往无法满足业务层对负载层灵活分配请求的要求。

4、说明

4.1、术语说明

• TPS: 衡量业务层处理性能的重要指标（每秒钟request/事务的处理数量）。业务服务处理一个完整的业务过程，并向上层返回处理结果的过程就是一个 request/事务。那么在一秒钟内整个业务系统能够完毕多少个这种过程，其衡量单位就是TPS。TPS不但和系统架构有非常大的关系（特别是业务层和业务通信层的架构祥泰），和物理环境、代码质量的关系也非常密切。

• PV: 网页浏览数是评价站点流量最经常使用的指标之中的一个，简称为PV。Page Views中的Page通常是指普通的html网页，也包括php、jsp等动态产生的html内容。注意是完整的显示一个Page成为一个PV。

  可是一个PV。一般须要多次HTTP请求，以便获取多个静态资源。这是须要注意的。

• UV: Unique Visitor 一个独立IP，在一个单位时间内（比如一日/一小时）对系统的一个PV请求。成为一个UV（反复的PV不在进行计数）。

• RUV: Repeat User Visitor 一个独立用户，在一个单位时间内（比如一日/一小时）对系统的一个PV请求。而且反复的訪问要进行计数。

4.2、后文介绍

下篇文章《架构设计：负载均衡层设计方案（2）——LVS、keepalived、Nginx安装和核心原理解析》中，我们将提到LVS的工作原理和Nginx中核心负载策略的工作原理（Hash、轮询、权重）。以及独立的LVS、Nginx、keepalived的安装方式（尽管安装方式在网络上一个搜索就能搜出来一大把。可是非常对都是抄袭。且没有经过具体的正误检查。所以我认为还是须要又一次进行一下说明）