我眼中的云计算4-负载均衡

排队在生活中无处不在，比如去银行办理业务，银行工作人员首先会引导客户根据待办理的业务类型，分到对应的组领号，通常情况一个业务窗口只提供一种服务，如果某类型业务排队的人太多，可能会开启新的业务窗口，而在没有人排队的时候，也会相应减少服务窗口。领到业务号码为止的前半段可视之为业务分发，而等待叫号直至处理完成则是负载均衡或处理能力池化。

在目前的硬件能力下，单机计算/存储能力相对固定(成本基本确定时)，提高能力只能增加硬件，为了使用户请求在各节点上的分布相对均衡，需要根据业务情况来设置相应的分发策略。计算资源常用的几种负载均衡策略：
1.轮询策略：依次从集群中获取，把请求平均分配到每一台服务器，不考虑服务器本身性能的差别；同一用户的请求也会被分发到不同服务器；
2.加权轮询策略：加强的轮询策略，分发时考虑了服务器性能的因素，但需要量化服务器计算能力，按服务器实际处理能力进行请求分发；
3.负荷最轻策略：优先把请求分发到负载最轻的服务器，因为用户请求的处理耗时不同，因此运行一段时间后，集群中各服务器的负载会有差别，但是使用负荷数据会增加额外的传输；
4.粘连策略：把同一用户的请求分发到同一个服务器处理，在session独立在各服务器的的情况下能提高用户体验；但在全局session和缓存数据的作用下，同一用户访问不同机器的请求连续性也能得到保证；

如前文所说，受限于I/O读写能力，单个存储资源(内存或硬盘)在满足读写访问的情况下，可存储的数据相对固定，而用户数据剧增的情况下，必然要增加存储资源，如何让用户数据分布合理，来保证存储资源的负载均衡呢？
1.按用户注册时间划分：无法保证各时间段活跃用户的比例接近，读写不均衡；
2.对用户ID取模：用户持续增长时，面对大批数据迁移重新分布的问题
3.一致性Hash：服务集群足够大时，把hash值在各服务器上进行环状分布，计算得到最终用户ID的hash值后，按所在区间分发到相应服务器；

业务的增长，使得软件抽象层次变深；而服务器的增加，导致网络拓扑变得复杂，分发/均衡策略在业务的横向和纵向变化中受到不同的约束，从粗放转向精细，从通用逐渐专用，越靠近用户，效率要求越高。实际使用中，常见的是4层和7层分发，一个作用于IP层，效率高，有硬件和软件两种实现方案；一个作用于应用层，可根据url识别出业务信息(静态内容/动态内容等)，做出更加准确的业务分发，以软件形式提供服务。

根据业务的不同，常见的负载均衡有主动和被动两种，着眼点不同：主动负载均衡，拉模式，集群处理能力一般先于分发能力成为瓶颈，通过设置任务缓冲区，让集群根据处理能力获取任务，并且可区别用户级别处理，高等级用户可提供优先服务，在峰值突然出现时由于缓冲区的存在集群表现也会比较平稳，部分请求会出现高延时的情况；而被动负载均衡，推模式，分发能力一般先于集群处理能力成为瓶颈，集群处理能力做余量配置，由前端的负载均衡器来进行任务的分发，提供的是无差别服务，在集群超负荷时不能缓存任务；

对于不同的业务场景，均衡策略的效果也有不同：

场景一：新闻页面的浏览，编辑完成内容录入后，生成静态页面，可根据url直接定位；多用户对单一页面的只读请求，因此可产生多份拷贝，通过CDN来优化用户体验；

场景二：电商的物品浏览，相比场景一增加了库存/评价/交易记录等动态信息，通常最终用户的浏览器获得框架页面后，再分别获取动态内容，而为了延缓加载压力或减少瞬时的异步请求，动态内容也可以由用户手动点击触发获取；极端情况是秒杀物品，多用户对单一资源的争抢，通常采用同步锁或数据合计对比的办法来，前端负载均衡，但订单有效性判断则仍是单一点处理；

场景三：SP业务系统的周/月计费模式，在新的计费周期到来时，需要对订阅类型的客户再次发起计费，由计费结果来决定服务的后续提供时间，整个处理过程中存在多次异步等待，计费发起条件的满足，用户的确认消息，计费结果的等待等等；批量多用户情况，但实际上不存在跨用户的数据交互，因此可简化为单一用户的处理，负载均衡策略达到较好效果；

场景四：SNS的用户浏览，用户A关注多个用户，当A登录时，给所有关注A的好友发送上线通知，获取A所关注用户的在线信息，并按时间顺序显示A关注的用户的发帖信息；单一用户对多种类型内容的加载需求，暂且不考虑所加载内容在何时生成，多用户并发情况下则演变为数据从前向后迅速增多的获取模型，各种类型的数据最终在用户的浏览器上完成合并展示，各个层级的负载均衡策略组合在一起，web层负责用户的框架页面/静态信息获取，内存cache管理着在线用户/热用户的信息，以及关注者众多的明星用户的发帖，而数据库/文件系统存储着大内容/冷用户等信息；

场景五：搜索引擎，用户提交关键字后，获得后台返回的网页信息；类似于场景四，但是数据归并的过程在服务端，而不是用户的浏览器入口；

综上所述，随着互联网的发展，由于用户获取信息时对数量和质量都有着更高的提高，服务/内容提供商在数据组织上需要更好的权衡，先规划再发展，或者先发展再重构，不管怎样，都需要预留足够的余量，来保证系统面临瓶颈时升级所要的时间。