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