负载均衡 load balance

This is a big topic which can be measured by many different ways. 

按层次： 网络层和应用层； 按范围： 全局和本地； 按策略：round robin, 加权round robin,  关键性能的反馈来确定负载。

1. 网络层：

DNS:  最早的负载均衡技术之一， 在DNS中为多个地址配置同一个名字，因而查询这个名字的客户机将得到其中一个地址，从而使得不同的客户访问不同的服务器，达到负载均衡的目的。　　DNS负载均衡是一种简单而有效的方法，但是它不能区分服务器的差异，也不能反映服务器的当前运行状态。  缺点： 粗暴、无法解决局部过热。

虚拟IP： LVS的 NAT模式、IP 隧道模式和直接路由模式（链路层)。 由于IP隧道模式出去的流量不经过路由节点DR，而且不像直接路由模式那样需要服务器在同一个广播域。 所以不错的选择。 

上面的实现硬件中的软件，而且是round robin策略。

2. 应用层

这个要看具体的应用了。 譬如图片应用和音乐应用自然在不同的 软件component上，譬如电商应用和聊天应用自然在不同的集群上。 天然的负载分开。 即使同一个应用也可以按不同的服务在架构上做负载均衡，而且利于以后的业务扩展。 譬如搜索服务里面的 摘要和检索应该在不同的组件上。

当然更多负载均衡发生在相同应用、相同服务的背景下。 在这种情况下往往加个负载均衡节点(存在的或者虚拟的）。 首先这里要区分你要均衡的到底是什么负载， 你负载是否就是socket 链接、 SCSI  ITN还是实际服务请求数、session数。 然后决定按照什么参数来负载均衡，譬如负载本身(connection, ITN, session, request, concurrent etc)， 譬如服务器机器资源消耗(cpu, 内存、硬盘等），还是性能本身譬如(response time etc).

2.1 其中策略有

1  Round Robin

简单但是会局部过热。 按负载round robin。 链接数，请求个数。  Weighed Round Robin 可部分避免局部过热。

2  最小并发数(session,  connection)

这里包括BIGIP 中的LeastConnection。   由于某些请求、链接会处理延迟、如果还是round robin,那么某些服务器会积累越来越多的并发请求，响应速度就会减慢。

3  根据性能

根据响应时间来均衡负载，其实就是BIGIP中的最快模式是这个的一部分。 根据资源消耗的话，需要另外的监测模块。

4 预测模式

某些应用有周期性，可以提前预测。

5 综合策略

以上多种策略综合。

2.2 软件实现方式

很多应用比较复杂，不可以是简单IP转换等，不可以是简单的round robin。  譬如动态web网站会进行 缓存和session处理， 前面会有很多web 容器服务器，web容器后面有很多分布服务的应用服务器，譬如支付，支付分很多步，希望一个用户的支付尽量在同一台服务器上，保持用户状态。 

这样就可以 网络层+加应用层(session ID).   web 容易前面的http请求是网络等，然后传给后面的应用层负载均衡器，由它根据hashtable(key, value) 找到那台session 服务器，发生请求。

其他譬如http请求代理等。

3. 负载均衡 开源软件

LVS：发生在 四层的负载均衡

nginx， Layer7 switching）、HAProxy： 第七层的软件负载均衡。