最简单的负载均衡架构

如下架构示例图： 

虽然这个架构图非常简陋，但是的确利用DNS服务器做了负载均衡，多数大型网站都是混合式的负载均衡方案，基本都不会少了DNS的负载均衡。可以使用dig命令看看qq.com和baidu.com，其中baidu.com有4条A记录，也就是通过DNS做了4个分支的负载均衡。 
图中还存在单点服务的地方，譬如共享文件系统的服务器端只在”web应用1“存在，不过意义非常大。

1. 在应用系统搭建初期就规划好共享文件的存储路径，为将来的扩展提供便利，也给代码编写提供了参考标准，避免后期再做调整。如果是租用云服务器提供商的服务器，将来直接使用对象存储服务、CDN都比较容易。
2. 双备份的数据库体系，架构简单易维护，但可以在故障发生的时候最大程度保护数据。
3. 双备份的web应用，可以给前线业务提供高保障的应用系统，发布新版本的时候，还可以很方便的把其中一台作为预发布环境，新版本内容发布和验证完毕后再更新另外一台应用，起码保证了50%的业务正常运行。
4. 配置简单，管理简单

当然，这仅仅只适用于时效要求低、缺少管理人员的创业型min公司。

利用负载均衡应用来搭建负载均衡架构

如图： 

负载均衡服务的实现方式

• 
  

  DNS负载均衡 
  基于DNS的负载均衡方案是最容易实施的，而且通常你也不用去管DNS服务器的性能和可用性，它的属主会关心这些问题。但是通常DNS服务器只是通过RR算法来均衡调度，因此，用户的在线信息需要管理好，也就是session数据需要在所有服务器间进行共享，不然用户的登陆状态会丢失。

  
  
• 
  

  反向代理负载均衡 
  基于反向代理服务器实施负载均衡应该是应用得最多的方式，反向代理服务工作在7层，通过转发http请求提供服务。目前几乎所有web容器都支持反向代理服务，如nginx。nginx可以根据实际需要定义负载均衡调度算法，权重，健康状态检测等参数。 
  默认情况下，nginx使用 round-robin 调度算法，并有健康状态检查和恢复主机的能力，另外还支持ip_hash,least_conn,sticky，不过有的需要安装额外的组件。

  
  
• 
  

  Http重定向负载均衡 
  http重定向方案可以说最个性化的负载均衡方案，因为几乎是代码级的工作，不同于反向代理，反向代理是转发http请求，而http重定向是web服务告诉用户的浏览器去访问另外一个url，可能是根据IP地址找到了更好的服务器，或者其他策略。例如从镜像下载文件，中国区用户可能会重定向到一个中国区的服务器上进行下载。这都是通过http协议中指定Location属性来实现的。

  
  
• 
  

  NAT负载均衡 
  也叫IP负载均衡，工作在7层网络结构里的第四层，通过对数据包中的IP地址和端口信息进行修改，从而打到负载均衡的效果。因为涉及的知识比较深，而且我也没有实践过，所以不深入写了。

  
  
• 
  

  在《构建高性能Web站点》一书中，还提到两种更高性能的方案，即直接路由、IP隧道，因为工作得更底层更接近硬件，所以性能会比上面的方式更高。

  
  
• 
  

  混合型负载均衡 
  在有些大型网络，由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异，可以考虑给每个服务器群采用最合适的负载均衡方式，然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务（即把这多个服务器群当做一个新的服务器群），从而达到最佳的性能。