如何实现大型网站架构设计的负载均衡

负载均衡 （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 的不间断可用性及较快的系统反应时间负载均衡必须满足性能、扩展、可靠性

服务器负载均衡系统三种接入方式

服务器负载均衡系统的常见调度算法

轮询（Round Robin）

加权轮询（Weighted Round Robin）

最少连接（Least Connections）

加权最少连接（Weighted Least Connections）

健康性检查

 健康性检查算法的目的：通过某种探针机制，检查服务器群中真实服务器的健康情况，避免把客户端的请求分发给出现故障的服务器，以提高业务的HA能力。

目前常用的健康性检查算法：Ping（ICMP）

TCP

HTTP

FTP

系统加速

优化功能 -SSL 加速

优化功能 -HTTP 压缩

 HTTP压缩是在Web服务器和浏览器间传输压缩文本内容的方法。F5 HTTP[压缩技术](https://zm10.sm-tc.cn/?src=l4uLj8XQ0IWXlpuekNGdnpabitGckJLQjJqejZyXwIiQjZvC2rrK2se62se92rrI2r282r7G2rrJ2se%2B2sfP2rrJ2sa82r652ZmNwo6doIyano2cl6Cah4%2FZlprCiouZxw%3D%3D&uid=96961868b00c02996d71d0627348e454&restype=1&from=derive&depth=2&v=1&link_type=12)通过具有智能压缩能力的 BIG-IP 系统可缩短[应用交付](https://zm10.sm-tc.cn/?src=l4uLj8XQ0IWXlpuekNGdnpabitGckJLQjJqejZyXwIiQjZvC2rrK2r2%2B2sbL2rrI2sbL2r7H2rrL2r2%2B2r7L2rrL2r292sbH2ZmNwo6doIyano2cl6Cah4%2FZlprCiouZxw%3D%3D&uid=96961868b00c02996d71d0627348e454&restype=1&from=derive&depth=2&v=1&link_type=12)时间并优化带宽。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。

服务器负载均衡设备选型

1. 价格因素
硬件设备：F5、 Citrix 、Redware 、A10
软件：LVS、Nginx、Haproxy、zen loadbalance2. 性能
4/7 层吞吐量 (单位 bps)
4/7 层新建连接数（单位 CPS）
并发连接数
功能模块性能指标（ssl 加速、 HTTP 压缩、内存 Cache）3. 满足真实和未来需求
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）不同负载均衡设备厂家由于不同的架构，使得某些设备在复杂环境下可能也表现的比较优秀，这个客户可以对比判断，但总体来说，以上建议适合于所有厂家的设备。