vlambda博客
学习文章列表

负载均衡（Load Balance）：顾名思义其本质就是将任务进行平衡、分摊。从而通过简单有效而又性价比高的方式满足业务对于系统的扩容需求。尤其在云计算时代，负载均衡往往作为流量入口，承担了至关重要的业务承载的使命。

一、系统扩容的形式

    随着业务的扩展、用户规模的扩大，我们的应用系统始终会处于扩容的需求之下。因此在系统整体规划，技术架构设计时，“易扩展性”就成为了一个必要考虑的特性之一。系统的主要能力一般包括：容量、计算、网络等。而根据不同的能力的扩容，往往需要采取不同的形式。一般可以分为纵向扩容（Scale Up）和横向扩容（Scale Out）。下面以存储系统扩容来说明两种扩容形式的区别。
    纵向扩容（Scale Up）
    随着业务的发展，经监控我们发现文件服务器空间不足，对于这种扩容需求，直接加存储即可。这就是纵向扩容。纵向扩容基本上是不会去影响整体系统架构的。就像一列绿皮火车，纵向扩容就是发现乘客太多的时候，往后面再挂一节车厢，增加载客容量。可是纵向扩容却不能解决所有的问题，因为新增加了车厢，车头的动力却没有变化，如果原车头动力不能负载新增的一节车厢，那么系统此时便会出现新的问题，更容易触发木桶短板效应。
    横向扩容（Scale Out）
    当纵向扩容无法解决系统当前的瓶颈的时候，这时候就需要考虑进行横向扩容，而横向扩容相对于纵向扩容就显得没那么纯粹了。横向扩容为了避免纵向扩容对单一能力的扩容造成的木桶短板效应，往往会以节点为单位进行扩容。就像一列高铁，每节车厢都拥有载客容量，都拥有独立的动力系统，这样，当我在进行车厢扩容的时候，便会在增加载客容量的同时，扩充了相应的动力系统，这样便可以让系统更加稳定的维持住原有性能水平（理论上是1+1=2的，但是往往实际 1 < 1+1 ≤ 2）。而由于多个节点的加入，乍看起来，其实是一种冗余的设计，而如何将冗余转化为“高可用（High Availability）”，对于系统来说就需要一个强有力的控制点来对所有节点进行统一管理，对所涉及的工作任务进行充分的协调管理。对于高铁系统来说，车头其实就相当于这样一个控制节点，统一协调着各车厢的行为。对于云计算，横向扩容后对于流量的承载、均衡、分发的火车头的角色，便是负载均衡了。

二、负载均衡的分类

    硬件负载均衡（Hardware Load Balancer）
    硬件负载均衡，即通过独立的硬件设备来实现负载均衡能力。我个人的项目经验中接触比较多的有F5和Array。这类硬件负载均衡的优点非常明显，功能强大、性能优异。缺点同时也非常明显，成本高昂。在我多个高并发背景的互联网项目的运行情况中，基本上只要不是网络存在异常，他们都可以很好的完成负载均衡的任务，使负载对于整个链路的性能损失降到最低。
    软件负载均衡（Software Load Balancer）
    软件负载均衡，即通过软件来实现负载均衡能力。在我个人的项目经验中，软件负载均衡对我来说接触的更为频繁。因为其成本低廉、安装部署简单、功能配置灵活等特点，使其更符合互联网行业对于产品的要求。最为常见也是大家最为熟悉的应该就是Nginx和LVS了。LVS是Linux内核的4层负载均衡，LVS是4层负载均衡。Nginx支持HTTP等协议；而LVS由于运行在4层，因此与协议无关，几乎所有应用都可以做。
    负载均衡的选择
    互联网往往更倾向于轻量、小巧、灵活、方便的技术特点的产品。在互联网有太多的例子。虽然从单体来看，软件负载的吞吐量与硬件负载差距较大，但对于互联网，这就相当于“x86于IBM小机”，“MySQL于Oracle”……
    我一贯的观点就是任何技术都一定要用在合适用它的地方才能发挥出最大的价值。硬件负载具有极高的性能和成本，那就“好钢用在刀刃上”，比如用在全站的最前端，或者一些非常重要的核心负载点。以下是结合我的项目经验，总结的一个常规相对理想的基本架构模型。不过由于各项目有各自的特点和现实情况，因此可以根据实际情况进行相关裁剪。
    项目的基本架构我们一般会采用：F5/Array - LVS/Nginx - APP Server

三、常用简单负载均衡的策略解析

    负载均衡的策略，我认为用好负载均衡的核心。其核心问题就是：如何均衡？流量进入到负载均衡后，负载是否能准确将该请求转发到能处理当前请求最优的服务端，这就有不同的策略辅以实现。
    轮询（Round Robin）
    每个请求按时间顺序逐一分配到不同的后端服务器。平均分配，一台一次。
    加权轮询（Weighted Round Robin）
    由于后端服务器性能不一定或者说大多数情况下都一定不会均衡的情况下，通过指定轮询权重，从而实现“能者多劳”的分配策略。
    最少连接数（Least Connections）
    根据每个节点实时的负载情况，对负载根据维护的各服务器的连接数取最小值，进行动态负载均衡的方式。
    最快响应（Least Response Time）
    根据每个节点实时的负载情况，对过去一段时间内的响应情况来分配，响应越快分配的越多。
    散列（Hash）
    散列的应用比较广泛，一般情况下可以使用源IP HASH之后，分配该IP相对固定的访问一台固定的IP，一定程度上可以避免会话保持的问题。

    实际应用往往不是直接应用单一策略，如果项目对于负载的分配有更高的要求，可以将简单的策略组合使用。策略需因地制宜、因项施策。