全栈必备 负载均衡

原文地址：http://blog.csdn.net/wireless_com/article/details/52761138

目录(?)[-]

1. 什么是负载均衡
2. 基于DNS的负载均衡
3. HTTP 负载均衡
4. 数据库负载均衡
5. 网络连接的负载均衡
6. SSL负载均衡
7. 压力和负载测试
8. 云服务的负载均衡
9. 高可用性

一个了不起的创意会产生一个很棒的产品，如果它一炮走红，你发现手中的是下一个facebook 或者twitter，而且随着用户越来越多，会变得越来越慢，该怎么办呢？对全栈而言，解决这类问题的一个重要技能就是——负载均衡。

什么是负载均衡

负载（load）一词起源于典型系统，指连接在电路中消耗电能的装置，负载（用电器）的功能是把电能转变为其他形式能。引申出来，一个是实体，一个转化。

于是，对于实体，有了通信帧或者报文中数据字段的内容被称为信息负载（payload），网络负载指的就是网络中继承载的流量以及网络设备承载的用户量。

转化被进一步阐释为资源的使用情况，系统平均负载是CPU的Load 即workload，它所包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息。

了解了负载，那么负载均衡就容易理解了。wiki百科给出的定义是这样的：

负载均衡（Load balancing）是一种计算机网络技术，用来在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。使用带有负载平衡的多个服务器组件，取代单一的组件，可以通过冗余提高可靠性。负载平衡服务通常是由专用软件和硬件来完成。

并且，wiki百科自身的系统就使用了负载均衡。

每一种技术都有它应用的场景和领域，负载均衡主要解决的是系统性能问题。但是，了解了根源，就可以知道不能够一提到性能问题就非负载均衡莫属，如果负载减少了，可能少一点均衡也可以解决问题，这样的技术例如缓存。

基于DNS的负载均衡

基于DNS的负载均衡是负载均衡的最简方法，可以说是穷人的负载均衡。

DNS会将域名映射为IP地址，反之亦然。所有核心DNS服务器都是集群，用的最多的DNS服务器大概就是BIND了。查询DNS服务器时，推荐使用dig；查询DNS解析时，推荐使用nslookup。 使用DNS缓存可以提高DNS解析的性能。Dig 在mac上的使用示例如下： 

对于DNS实现的负载均衡非常简单，采用轮转的方式，只要为所要服务的域名增加多个A记录即可。 
例如:

abel.com. IN A 168.168.168.168 

abel.com. IN A 168.168.168.168 

abel.com. IN A 168.168.168.168 

abel.com. IN A 168.168.168.168
1
2
3
4
5
6
7
1
2
3
4
5
6
7

基于DNS的负载均衡简单，易于调试且容易扩展。缺陷在于它有慢性失忆症，无法将会话信息从一个请求保留到下一个请求。而且，只是对目标服务地址进行了均衡，无法考虑请求处理的负载强度进行均衡，同时容错性较差。

支持DNS 负载均衡的服务商有AWS Route 53 以及dnspod。

HTTP 负载均衡

负载均衡解决的是性能问题，要先了解单个服务器的状况。一般地，nginx 的应答率比Apache 高，所以，有时更换Web 服务器就可以提高性能。

提高Apache Http的方法有禁用空载模块，禁用DNS查询，采用压缩模块，不使用SymLinksIfOwnerMatch选项，并且在Directory选项中启用FollowSymLinks，等等。

Nginx本身就是高性能的，但可以通过worker_processes 和worker_cpu_affinity调整来匹配服务器的硬件平台，还可以对压缩进行区分对待，使用其缓存的能力。例如

Http{
        gzip on;
        gzip_static on;
        gzip_comp_level 2;
        gzip_types application/javascript;
}
1
2
3
4
5
6
1
2
3
4
5
6

HTTP的负载均衡相当于7层负载均衡，不论Apache 还是 Nginx 都可以充当HTTP的负载均衡器。

以基于权重的负载均衡为例，可以配置Nginx把请求更多地分发到高配置的后端服务器上，把相对较少的请求分发到低配服务器。配置的示例如下：


http{ 
upstream sampleapp { 
server 192.168.1.23 weight=2; 
server 192.168.1.24; 
} 
.... 
server{ 
listen 80; 
... 
location / { 
proxy_pass http://myapp; 
} 
} 

Nginx 作为负载均衡工作在7层，可以对做正则规则处理（如针对域名、目录进行分流等） ，配置简单，能ping通就能进行负载功能，可以通过端口检测后端服务器状态，不支持url检测。Nginx 负载均衡抗高并发，采用epoll网络模型处理客户请求，但应用范围受限。

数据库负载均衡

数据库负载均衡的一般用法从读写分离开始的，因为一般的应用都是读多写少的缘故吧。将数据库做成主从，主数据用于写操作，从数据库用于读操作，事务一般在主库完成。

数据库集群是数据库负载均衡的典型方式，集群管理服务器作为负载均衡器，例如MySQL cluster。

更简单的方式是通过Haproxy 来完成负载均衡的调度。

HAProxy能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作，支持url检测后端的服务器出问题的检测会有很好的帮助。

HAProxy拥有更多的负载均衡策略比如：动态加权轮循(Dynamic Round Robin)，加权源地址哈希(Weighted Source Hash)，加权URL哈希和加权参数哈希(Weighted Parameter Hash）等，单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。

网络连接的负载均衡

LVS(IPVS，IP虚拟服务器)是在四层交换上设置Web服务的虚拟IP地址，对客户端是可见的。当客户访问此Web应用时，客户端的Http请求会先被第四层交换机接收到，它将基于第四层交换技术实时检测后台Web服务器的负载，根据设定的算法进行快速交换。常见的算法有轮询、加权、最少连接、随机和响应时间等。

LVS抗负载能力强，使用IP负载均衡技术，只做分发，所以LVS本身并没有多少流量产生。 LVS的稳定性和可靠性都很好应用范围比较广，可以对所有应用做负载均衡，缺陷是不支持正则处理，不能做动静分离。

通过LVS+Keepalived构建的LVS集群，LVS负载均衡用户请求到后端服务器，Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。

下图是Keepalived的原理图： 

SSL负载均衡

信任是互联网的基石，出于安全性的考量，服务中往往需要SSL的连接。SSL 有两种认证方式：双向认证 SSL 协议要求服务器和用户双方都有证书；单向认证 SSL 协议不需要客户拥有CA证书。一般Web应用，配置SSL单向认证即可。但部分金融行业用户的应用对接，可能会要求对客户端(相对而言)做身份验证。这时就需要做SSL双向认证。

SSL 属于应用层的协议，所以只能在 7 层上来做，而 HAProxy 也是支持 SSL 协议的，所以一种方式是只需简单的让 HAProxy 开启 SSL 支持完成对内解密对外加密的处理, 但引入 SSL 处理是有额外的性能开销的（如上面谈到的认证）, 所以 一般采用SSL proxy farm， 典型的架构如下：

压力和负载测试

测试负载的状况，一般要涉及负载或压力测试。

负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断增加负载载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源等，以检验系统的行为和特性，并发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。

负载测试更多地体现了一种方法或一种技术。压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。

压力测试可以被看作是负载测试的一种，即高负载下的负载测试，或者说压力测试采用负载测试技术。

简单地，httperf 或者Apache AB 就可以测量HTTP 服务器的负载性能。

云服务的负载均衡

云时代的到来，使负载均衡成了平台级的服务，几乎所有的云服务提供商都提供了负载均衡服务。下面是阿里云的负载均衡基础框架图：

特别的，qingcloud 的vpc 也是挺有特点的，私有网络 用于主机之间互联，类似于使用交换机（L2 Switch）自组局域网。弹性IP还好，管理路由器就显得很贴心了。

AWS 的负载均衡还是业界典范，官方给出的示意图如下： 

高可用性

高可用性是负载均衡带来的另一价值, 即负载均衡经常被用于实现故障转移。当一个或多个组件出现故障时，能持续提供服务的这些组件都在持续监控中，当一个组件没有响应，负载均衡器就会发现它，并不再向其发送数据。同样当一个组件重新上线，负载均衡器会重新开始向其发送数据。

SLA 作为高可用性的指标，一般有3个时间标准：99.9%,99.99%,99.999%. 表示不间断运行的离线时间不超过：

• 3个9： 8.76 小时
• 4个9：52.26 小时
• 5个9：5.26 分钟

三点两地的灾备方案并不是谁都做的起的，有了云服务就显得不那么苦难了。下面是阿里云给出的容灾示意图，多可用区部署，机房宕机后，仍能正常工作。 

系统的监控在系统高可用性上作用很大，个人推荐zabbix。

总体来看， 负载均衡是系统架构和DevOps 中的重要技术，对系统性能影响巨大。当然，如果有更高需求的话，就需要考虑硬件的负载均衡方案了，比如说F5。