负载均衡架构及实现

负载均衡架构及实现

常用的调度算法有如下几个：

1. 轮询（RR）
   round robin:新的连接请求被轮流分配至各RealServer，优点是该算法无需记录当前所有连接的状态，效率高，但是缺点是在RealServer中，如果有性能不均等的情况下，性能差的主机将负载比较大。可能会导致服务器之间负载不均衡。
   另外轮询在算法实现上，应该用了ArrayList(存放所有服务器)和pos(指向下一个服务器)实现，pos必须要保证线程安全，加锁，这样也会导致并发的吞吐量明显下降。
   为了解决这一问题，其实可以用随机选取的方式，吞吐量越大，根据概率统计的理论，效果越接近轮询，这样就可以避免对pos加锁
2. 加权轮询(WRR)
   Weighted RR:优点与RR一样，无需记录所有连接状态，可以通过设定一定的权重值来分配连接请求，比如性能好的机器，在分配的时候，可以多分配一点。
3. 源地址哈希(SH)
   Source Hashing:通过一个散列函数将去往同一个目的IP请求映射到一台服务器或链路上。
4. 目标地址哈希(DH)
   Destination Hashing:通过一个散列函数将来自同一个源IP请求映射到一台服务器或链路上。
5. 最少连接数(LC)
   Least Connection:根据当前各服务器的连接数来估计服务器的负载情况，把新的连接分配给连接数最小的服务器上。
6. 加权最少连接数(WLC)
   Weight LC:与LC类似，根据当前各服务器的连接数来估计服务器的负载情况。
7. 最短期望延迟(SED)
   Shortest Expect Delay:这个算法主要是优化LC的，在服务均在请求少的时候避免负载到一台服务器上做的优化。
8. 永不排队(NQ)
   Never Queue:负载低时，请求直接分配到空闲服务器上，不会产生请求等待。

负载场景1

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

负载场景2

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

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

负载场景3

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

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

负载场景4

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

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

解决方案1（Nginx）

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

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

Nginx是反向代理服务器，对于正向代理和反向代理不清楚的小伙伴可以去看下一篇文章

解决方案2(Nginx+Keepalive)

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

解决方案3(LVS+Keepalive+Nginx)

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

解决方案4(DNS轮询+LVS+Keepalive+Nginx)

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

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

首先我们不在像前面的方案中，使用目录名分割业务系统了，而是直接将业务系统的访问使用不同的二级域名进行拆分。这样的变化有利于每个业务系统都拥有自己独立的负载均衡层。

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

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

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

转载：http://blog.csdn.net/yinwenjie