负载均衡

大规模流量的网站架构，历来都是慢慢“成长”而来。而这个过程当中，会遇到不少问题，在不断解决问题的过程当中，Web系统变得愈来愈大。而且，新的挑战又每每出如今旧的解决方案之上。但愿这篇文章可以为技术人员提供必定的参考和帮助。 

如下为原文

当一个Web系统从日访问量10万逐步增加到1000万，甚至超过1亿的过程当中，Web系统承受的压力会愈来愈大，在这个过程当中，咱们会遇到不少的问题。为了解决这些性能压力带来问题，咱们须要在Web系统架构层面搭建多个层次的缓存机制。在不一样的压力阶段，咱们会遇到不一样的问题，经过搭建不一样的服务和架构来解决。

Web负载均衡 

Web负载均衡（Load Balancing），简单地说就是给咱们的服务器集群分配“工做任务”，而采用恰当的分配方式，对于保护处于后端的Web服务器来讲，很是重要。

 

负载均衡的策略有不少，咱们从简单的讲起哈。

1. HTTP重定向

当用户发来请求的时候，Web服务器经过修改HTTP响应头中的Location标记来返回一个新的url，而后浏览器再继续请求这个新url，实际上就是页面重定向。经过重定向，来达到“负载均衡”的目标。例如，咱们在下载PHP源码包的时候，点击下载连接时，为了解决不一样国家和地域下载速度的问题，它会返回一个离咱们近的下载地址。重定向的HTTP返回码是302，以下图：

 

若是使用PHP代码来实现这个功能，方式以下：

 

这个重定向很是容易实现，而且能够自定义各类策略。可是，它在大规模访问量下，性能不佳。并且，给用户的体验也很差，实际请求发生重定向，增长了网络延时。

2. 反向代理负载均衡

反向代理服务的核心工做主要是转发HTTP请求，扮演了浏览器端和后台Web服务器中转的角色。由于它工做在HTTP层（应用层），也就是网络七层结构中的第七层，所以也被称为“七层负载均衡”。能够作反向代理的软件不少，比较常见的一种是Nginx。

 

Nginx是一种很是灵活的反向代理软件，能够自由定制化转发策略，分配服务器流量的权重等。反向代理中，常见的一个问题，就是Web服务器存储的session数据，由于通常负载均衡的策略都是随机分配请求的。同一个登陆用户的请求，没法保证必定分配到相同的Web机器上，会致使没法找到session的问题。

解决方案主要有两种：

1. 配置反向代理的转发规则，让同一个用户的请求必定落到同一台机器上（经过分析cookie），复杂的转发规则将会消耗更多的CPU，也增长了代理服务器的负担。

2. 将session这类的信息，专门用某个独立服务来存储，例如redis/memchache，这个方案是比较推荐的。

反向代理服务，也是能够开启缓存的，若是开启了，会增长反向代理的负担，须要谨慎使用。这种负载均衡策略实现和部署很是简单，并且性能表现也比较好。可是，它有“单点故障”的问题，若是挂了，会带来不少的麻烦。并且，到了后期Web服务器继续增长，它自己可能成为系统的瓶颈。

3. IP负载均衡

IP负载均衡服务是工做在网络层（修改IP）和传输层（修改端口，第四层），比起工做在应用层（第七层）性能要高出很是多。原理是，他是对IP层的数据包的IP地址和端口信息进行修改，达到负载均衡的目的。这种方式，也被称为“四层负载均衡”。常见的负载均衡方式，是LVS（Linux Virtual Server，Linux虚拟服务），经过IPVS（IP Virtual Server，IP虚拟服务）来实现。

 

在负载均衡服务器收到客户端的IP包的时候，会修改IP包的目标IP地址或端口，而后原封不动地投递到内部网络中，数据包会流入到实际Web服务器。实际服务器处理完成后，又会将数据包投递回给负载均衡服务器，它再修改目标IP地址为用户IP地址，最终回到客户端。 

 

上述的方式叫LVS-NAT，除此以外，还有LVS-RD（直接路由），LVS-TUN（IP隧道），三者之间都属于LVS的方式，可是有必定的区别，篇幅问题，不赘叙。

IP负载均衡的性能要高出Nginx的反向代理不少，它只处理到传输层为止的数据包，并不作进一步的组包，而后直接转发给实际服务器。不过，它的配置和搭建比较复杂。

4. DNS负载均衡

DNS（Domain Name System）负责域名解析的服务，域名url其实是服务器的别名，实际映射是一个IP地址，解析过程，就是DNS完成域名到IP的映射。而一个域名是能够配置成对应多个IP的。所以，DNS也就能够做为负载均衡服务。

 

这种负载均衡策略，配置简单，性能极佳。可是，不能自由定义规则，并且，变动被映射的IP或者机器故障时很麻烦，还存在DNS生效延迟的问题。 

5. DNS/GSLB负载均衡

咱们经常使用的CDN（Content Delivery Network，内容分发网络）实现方式，其实就是在同一个域名映射为多IP的基础上更进一步，经过GSLB（Global Server Load Balance，全局负载均衡）按照指定规则映射域名的IP。通常状况下都是按照地理位置，将离用户近的IP返回给用户，减小网络传输中的路由节点之间的跳跃消耗。 

 

图中的“向上寻找”，实际过程是LDNS（Local DNS）先向根域名服务（Root Name Server）获取到顶级根的Name Server（例如.com的），而后获得指定域名的受权DNS，而后再得到实际服务器IP。

 

CDN在Web系统中，通常状况下是用来解决大小较大的静态资源（html/Js/Css/图片等）的加载问题，让这些比较依赖网络下载的内容，尽量离用户更近，提高用户体验。

例如，我访问了一张imgcache.gtimg.cn上的图片（腾讯的自建CDN，不使用qq.com域名的缘由是防止http请求的时候，带上了多余的cookie信息），我得到的IP是183.60.217.90。 

 

这种方式，和前面的DNS负载均衡同样，不只性能极佳，并且支持配置多种策略。可是，搭建和维护成本很是高。互联网一线公司，会自建CDN服务，中小型公司通常使用第三方提供的CDN。

同步访问量的 架构选择：

（1）日访问量百万如下，架构能够简单点，作好mysql的优化等就好。

（2）百万到千万，Nginx为负载均衡，web服务器引入redis内存cache，mysql分离为多台。

（3）千万以上，负载均衡转LVS，web服务器优化，内存缓存，减轻mysql读写，引入nosql等等。

（4）亿以上，能够维持原来（3）的方案不变，不过用户体验很差，建议发展异地部署。 静态文件，所有使用CDN，前期使用第三方，有条件能够自建CDN。