大型网站--负载均衡架构
转自：http://www.cnblogs.com/and/p/3366400.html
负载均衡 （Load Balancing） 负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
大型网站负载均衡的利器
- 全局负载均衡系统（GSLB）
- 内容缓存系统（CDN）
- 服务器负载均衡系统（SLB）
DNS域名解析的基本过程
最初的负载均衡解决方案（DNS轮询）
优点
- 基本上无成本，因为往往域名注册商的这种解析都是免费的；
- 部署方便，除了网络拓扑的简单扩增，新增的Web服务器只要增加一个公网IP即可
缺点
- 健康检查，如果某台服务器宕机，DNS服务器是无法知晓的，仍旧会将访问分配到此服务器。修改DNS记录全部生效起码要3-4小时，甚至更久；
- 分配不均，如果几台Web服务器之间的配置不同，能够承受的压力也就不同，但是DNS解析分配的访问却是均匀分配的。用户群的分配不均衡导致DNS解析的不均衡。
- 会话保持，如果是需要身份验证的网站，在不修改软件构架的情况下，这点是比较致命的，因为DNS解析无法将验证用户的访问持久分配到同一服务器。虽然有一定的本地DNS缓存，但是很难保证在用户访问期间，本地DNS不过期，而重新查询服务器并指向新的服务器，那么原服务器保存的用户信息是无法被带到新服务器的，而且可能要求被重新认证身份，来回切换时间长了各台服务器都保存有用户不同的信息，对服务器资源也是一种浪费。
全局负载均衡系统（GSLB）
优势
- 数据中心冗余备份
- 多站点流量优化
- 确保用户体验
全局负载均衡系统（GSLB）的原理
DNS检查工具网上有很多，感兴趣的可以搜索一下。
内容缓存系统（CDN）
- 内容缓存系统（CDN）之静态加速
- 内容缓存系统（CDN）之动态加速
动态加速的特点
- 智能路由
- 传输控制协议（TCP）优化
- HTTP预载
服务器负载均衡系统
应用背景
- 访问流量快速增长
- 业务量不断提高
用户需求
- 希望获得7×24的不间断可用性及较快的系统反应时间
负载均衡必须满足性能、扩展、可靠性
服务器负载均衡系统三种接入方式
部署方式 | 特点 | 优点 | 缺点 |
串联路由模式 | 比较常见的部署方式 |
|
|
单臂模式 | 最常见的部署方式 |
|
|
DSR | 服务器回程报文不通过负载均衡设备，直接返回给客户端； 延迟短，适合流媒体等对延时要求较高应用 |
|
|
服务器负载均衡系统的常见调度算法
- 轮询（Round Robin）
- 加权轮询（Weighted Round Robin）
- 最少连接（Least Connections）
- 加权最少连接（Weighted Least Connections）
健康性检查
健康性检查算法的目的：通过某种探针机制，检查服务器群中真实服务器的健康情况，避免把客户端的请求分发给出现故障的服务器，以提高业务的HA能力。
目前常用的健康性检查算法：
- Ping（ICMP）
- TCP
- HTTP
- FTP
系统加速
优化功能-SSL加速
优化功能-HTTP压缩
HTTP压缩是在Web服务器和浏览器间传输压缩文本内容的方法。F5 HTTP压缩技术通过具有智能压缩能力的 BIG-IP 系统可缩短应用交付时间并优化带宽。HTTP压缩采用通用的压缩算法压缩HTML、JavaScript或CSS文件。压缩的最大好处就是降低了网络传输的数据量，从而提高客户端浏览器的访问速度。
优化功能-连接复用
优化功能-TCP缓存
会话保持
会话保持-客户端源IP会话保持
源IP地址会话保持就是将同一个源IP地址的连接或者请求认为是同一个用户，根据会话保持策略，在会话保持有效期内，将这些发自同一个源IP地址的连接/请求都转发到同一台服务器。
会话保持-Cookie会话保持
当采用基于源地址的会话保持无法做到负载均分时，例如客户端发起连接请求的源IP地址相对固定，发生此类问题通常可采用基于应用层的会话保持方式，Cookie通常是存在于HTTP头中，现如今基于HTTP的应用被广泛使用，因此基于Cookie的会话保持越来越多的出现在服务器负载均衡解决方案中。
局限性：
对于非HTTP协议，或者客户端禁用Cookie，无效。
会话保持-URL哈希（Hash）会话保持
哈希会话保持的一个基本概念就是按照某个Hash因子，根据此因子以及后台存在多少台服务器计算得到的结果来选择将请求分配到那台服务器。哈希会话保持的特点是在后台服务器的健康状态不发生改变的时候，每个特定的Hash因子被分配到的服务器是固定的。其最大的优势是哈希会话保持可以没有会话保持表，而仅仅是根据计算的结果来确定被分配到那台服务器，尤其在一些会话保持表查询的开销已经远远大于Hash计算开销的情况下，采用Hash会话保持可以提高系统的处理能力和响应速度。
URL哈希会话保持通常针对后台采用Cache服务器的应用场景，针对URL进行Hash计算，将同一个URL的请求分配到同一台Cache服务器，这样，对后台的Cache服务器群来说，每台Cache服务器上存放的内容都是不一样的，提高Cache服务器的利用率。
故障案例分析
Q&A案例分析（1）-循环跳转
故障现象：
Web服务端对用户访问的URL进行判断，对于非https的请求，重定向到http站点，结果导致用户一直302跳转。
原因分析：
采用了负载均衡SSL加速功能，在服务端看到所有的用户请求都来自于http。
解决方案：
全站启用SSL加速。
Q&A案例分析（2）-用户Session丢失
故障现象：
用户在http站点上提交数据到同域名的https站点，web程序抛出session丢失的异常，用户提交数据失败。
原因分析：
http和https在负载均衡设备上被认为是2个独立的服务，产生2个独立的TCP链接，会命中不同的真实服务器，导致session丢失。
解决方案：
在负载均衡设备上启用基于真实服务器的会话保持。
Q&A案例分析（3）-客户端源IP取不到
故障现象：
服务端获取不到用户外网的IP地址，看到的都是大量来自于内网特定网段的IP地址。
原因分析：
负载均衡设备启用了用户源地址转换（SNAT）模式，修改了TCP报文中的用户源IP。
解决方案：
负载均衡设备会用用户的外网IP改写x-forwarded-for值，服务端通过获取http协议中request header头的x-forwarded-for值作为用户源IP。IIS日志通过安装插件形式显示用户源IP。
服务器负载均衡设备选型
硬件设备：F5、 Citrix 、Redware 、A10
软件：LVS、Nginx、Haproxy、zen loadbalance
4/7层吞吐量(单位bps)
4/7层新建连接数（单位CPS）
并发连接数
功能模块性能指标（ssl加速、 HTTP压缩、内存Cache）
1）如果确认负载均衡设备对所有应用的处理都是最简单的4层处理，那么理论上选择的负载均衡设备的4层性能稍高于实际性能需求即可。
2）如果确认负载均衡设备对所有应用的处理都是简单的7层处理，那么理论上选择的负载均衡设备的7层性能稍高于实际性能需求即可。
3）如果负载均衡设备处理的应用既有4层的也有7层的，建议按照7层应用的性能来考虑负载均衡设备。
4）如果确认自己的应用经过负载均衡处理时，需要复杂的4层或者7层处理，例如需要根据客户端的地址做策略性分发，需要根据tcp的内容做处理，需要根据HTTP头或者HTTP报文做处理，那么建议选择的负载均衡设备4/7层性能为真实性能需求的两倍。
5）如果负载均衡设备有混合的复杂流量处理并且还开启了一些功能模块，那么建议选择的负载均衡设备4/7层性能为真实性能需求的3倍。
6）考虑到设备需要轻载运行才能更加稳定，所以有可能的话在以上基础上再增加30%的性能。
7）如果还要满足未来几年的发展需求，在以上基础上还要留出未来发展所需要增加的性能。
8）不同负载均衡设备厂家由于不同的架构，使得某些设备在复杂环境下可能也表现的比较优秀，这个客户可以对比判断，但总体来说，以上建议适合于所有厂家的设备。
未完待续
感兴趣的可以我关注微博或博客，如果感觉不错可以点“推荐”