统一接入层方案
1 概述
信息中心网络组已经对应用服务器所在的网络进行划分，应用系统的节点分别部署到网络的接入层、应用层和数据层。这样的划分能够提高应用系统和敏感数据的安全性，但是增加了应用系统部署的复杂性。
根据网络规划，接入层作为用户（包括内部用户和外部用户）与关键服务器的隔离层，直接接收用户的请求，并转发给应用服务器。作为一种尝试，目前在接入层已经开始使用nginx对应用服务器进行反向代理，并支持多个应用服务器的负载均衡。
但是从应用系统部署的角度来看，接入层尚缺少统一的技术方案和整体规划。本文提出本证券公司应用系统接入层整体解决方案，以期达到如下的目的：
- 提出统一的接入层方案，规范应用系统的部署。
- 实现统一的应用服务器负载均衡解决方案。
- 通过公共的接入服务器和集中的配置，减小系统上线的工作量。
- 解决接入层的单点问题，保证高可用。
- 实现内外部域名的统一指向。
- 整合各应用系统的URL，对于子域名、虚拟目录等进行统一规划和分配。
2 技术方案
2.1 要考虑的问题
统一接入层技术方案主要考虑两方面的问题：负载均衡和高可用。
- 负载均衡
采用一定的分配算法将网络请求分发到后端的多个服务器，从而获得更高的性能。实现负载均衡功能的软/硬件称为 负载均衡器 。 本文中的负载均衡特指将客户的http请求分发到后端的web服务器或应用服务器。
- 高可用
为了避免负载调度器的单点故障，部署多个负载调度器节点，通过并行或主从的方式同时工作。
- 会话保持
会话 服务器端维持的状态信息，使得服务器能够识别同一客户的多次请求之间的关联。会话保持是指负载均衡器上的一种机制，通过会话保持，负载均衡器能够识别同一客户端多次请求的关联性，并能够将相关联的请求分配到同一台后端服务器上。
- 配置灵活性
因为需要整合各应用系统的URL，对于子域名、虚拟目录等进行统一规划和分配，需要考虑配置的灵活性和分流策略的多样性。
2.2 总体架构
统一接入层的总体架构如下图所示：
2.3 负载均衡器选型
考虑到管理类系统都是内部用户，总的并发不高。按照峰值 3000员工*（10请求/秒）= 3万请求/秒 进行估算，软件负载均衡器就能够满足要求。
目前比较流行的软件负载均衡器包括NginX、HAProxy 和 LVS(Linux Virtual Server) 。三者的对比如下：
| LVS | HAProxy | Nginx | |
|---|---|---|---|
| 网络协议层 | 4 | 4，7 | 7 |
| 性能 | 最高 | 高 | 高 |
| 资源消耗 | 高 | 中 | 低 |
| 安装配置 | 复杂 | 一般 | 简单 |
| 支持的协议 | tcp之上 | tcp之上 | http，pop/smtp |
| 会话保持 | 不支持 | 支持 | 支持 |
| 虚拟主机 | 不支持 | 支持 | 支持 |
| 其他功能 | 支持广域网负载均衡 | 支持URL方式检查后端服务器状态 | 可以作为web服务器，支持web缓存，支持虚拟目录 |
从上面简单的对比可以看出，LVS性能最好，能够适应多种网络协议，可以用作大多数服务器的负载均衡，但是配置比较复杂，对http协议没有额外的功 能；HAProxy性能比Nginx要好，对http协议提供了一些额外支持；Nginx的性能略差于HAProxy，对http协议的额外支持与 HAProxy各有千秋，但是NginX能够针对域名、URL目录结构等配置分流策略，配置更加强大和灵活，同时NginX还可以作为web服务器并支持 web缓存。
综合上述分析，对于本文要实现的“统一web应用接入层”，使用NginX更加合适。其主要优势在于配置策略的灵活性，能够有效实现子域名、虚拟目录、URL路径的统一规划和管理。 同时，相对其他两款负载均衡器，NginX在公司内部有一定的技术积累，所以本方案选择NginX作为统一接入层的负载均衡器。
而HAProxy适合单个应用的负载均衡，尤其适合web服务器和mysql服务器的负载均衡；LVS更适合高并发网站的最前端负载均衡（作为硬件负载均衡的替代）。
2.4 高可用方案
目前服务器的高可用（HA,High Availability）主要通过服务器集群(Cluster)技术来实现。比较常见的集群软件包括keepalived, heartbeat和NLB等。 对于NginX，最成熟的架构是配合keepalived实现高可用。
Keepalived是Linux下实现VRRP备份路由的高可靠性运行件。能够实现主服务器和备份服务器故障时IP瞬间无缝交接。而NginX支持Master-Backup的部署方式。配合Keepalived，能够通过两台NginX的集群实现高可用。
具体方案包括：
- 在两台linux服务器上均部署NginX和keepalived
- 两台服务器为主备（Master-Backup）关系，对外有相同的虚拟IP（VIP）
- keepalived监测服务器的IP存活，当发现故障时接管虚拟IP
- 编写自定义脚本用于keepalived监测NginX的存活状态。如果发现NginX故障，杀掉NginX所在服务器的keepalived，使得另一台keeplived可以接管。
- 需要配合监控和报警机制
2.5 会话保持方案
为简单起见，本方案中不考虑会话同步/共享。但在NginX会采用ip-hash策略，保证同一客户的请求会被转发到相同的后端服务器，从而实现会话保持。 如果应用系统需要进行会话同步，需要自行考虑redis、memcached等方案。
2.6 URL资源的统一规划
尽量减少子域名的数量和变化频度，可以考虑按照应用系统的类别划分子域名，如：
| 类别 | 二级域名 |
|---|---|
| 管理系统 | coworks.mycompany.com |
| 移动办公 | m.mycompany.com |
| 开发类 | dev.mycompany.com |
| 其他 | site.mycompany.com |
应用系统的变化相对频繁，为了简化应用系统部署，用二级域名的第一级目录指定具体的应用系统，如：
| URL | 应用系统 |
|---|---|
| dev.mycompany.com/svn | 版本管理 |
| dev.mycompany.com/submin | svn web管理界面 |
| dev.mycompany.com/jira | 缺陷管理 |
| dev.mycompany.com/trac | 系统资料（wiki） |
| dev.mycompany.com/software | 开发工具下载 |
| dev.mycompany.com/mirrors | 内部yum源 |
| dev.mycompany.com/maven | maven私服 |
2.7 方案扩展
- 当并发进一步增加时，在nginx前端再部署LVS/F5
- 对于非web应用，可以在接入层部署LVS或HAProxy
- HAProxy或LVS也可用于数据库的负载均衡
3 实施计划
- 搭建
- 测试
- 测试故障切换
- 测试故障恢复
- 测试性能
- 测试不停止服务的情况下更改NginX配置
- 准备规划好的二级域名
- 迁移
Author: Holbrook Wong<wanghaikuo@gmail.com>
Date: 2012-10-16 16:23:35 CST
HTML generated by org-mode 6.33x in emacs 23
