文/邹艳玲 宋晓辉 常征

为提高高校数据中心Web应用的性能和安全性，提出了一种基于NGINX技术的综合管理体系架构。该结构聚合访问者请求转发到真实服务器，针对不同HTTP应用部署了智能DNS、策略路由等分流策略，使用静态资源缓存技术提升了访问速度，整合了各运营商资源达到“互联互通”。同时，使用事件驱动的方式处理请求，转发经过适当过滤的Web访问，增加WAF模块实现了对应用服务器更全面的Web安全防护。通过UPSTREAM管理模块构建管理体系，为安全应急响应提供了快速处置接口。现网运行实践表明，与传统的Web应用架构相比，所提架构稳定，安全性高，并通过“无状态”降低了整体管理成本。

高校数据中心承载了学校大量信息系统，面对师生和公众提供各项服务，是非常重要的信息化基础设施。随着信息化工作不断推进，数据中心承载的信息系统越来越多，学校各项业务和用户对信息系统的依赖不断增强，对数据中心的各项要求也越来越高:首先，基于访问质量要求；其次，基于网络和信息安全要求。综合上述管理和技术要求，本文尝试了以NGINX为核心，构建校级Web应用管理体系。NGINX是一款轻量级的Web服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器，并在一个BSD-like协议下发行。其特点是占有内存少，并发能力强。在学校数据中心部署后，实现了对校内Web应用的加速、管理等多种功能，并在一定程度上提高了校园网内Web站点的应用安全。

系统架构

数据中心传统的系统架构通常利用防火墙做目标地址转换（DNAT）或者在Web服务器上设置各互联网服务提供商（ISP）的公网地址。配置更新时需要手动修改防火墙或服务器设置，显然，这两种方式管理相对复杂，缺少灵活性。因此，可以把各个ISP的IP资源放到NGINX服务器群上，实现全校所有Web系统共享共用。本文提出了集中统一的架构模式，如图1所示，因学校由两个校区组成，拓扑中设备分成了两组，数据中心（IDC）核心1和2在同一校区，IDC核心3在另一校区。两校区间通过多个MPLS VPN（基于MPLS技术的虚拟局域网）连接将双方的ISP资源对接到三个IDC核心设备上。IDC核心包括了防火墙（FW）、入侵防御系统（IPS）和负载均衡（LB）等常见业务插卡。虽然，NGINX集群在网络连接上和普通Web服务器位置相似,但Web流量实际上经过了NGINX集群转发。

架构通过“无状态”来降低管理成本。所谓“无状态”，是指每一台服务器的作用对等，相应的软件和配置一致。可以在核心NGINX层实现流量分组（如内外网隔离、爬虫和非爬虫流量隔离）、缓存静态文件、请求头过滤、故障切换（机房故障切换到其他机房）、流量控制、防火墙（FW）等一些通用型功能，支持水平扩容。调整服务器时，不需要针对不同服务器的“个性”化需求做配置，实现数据中心整体管理成本最低。

图1 基于NGINX技术的综合管理体系架构

提高Web访问质量

除了网站和信息系统自身响应速度，网络速度对访问质量影响也很大，特别是互联网带宽和时延。当前高校数据中心一般使用校园出口资源作为校外用户访问入口，通常配备一条或数条运营商链路。由于客观存在的运营商互联互通问题，往往单一运营商链路无法提供理想的校外访问效果，需要综合、合理利用多运营商链路。

策略路由、源线路进和源线路出

在操作系统层面设置合适的策略路由，使来自特定运营商链路的访问请求，回应报文从原链路返回。本文使用Linux操作系统作为配置案例【1】，首先创建两个默认路由表T1和T2，令第一块网卡的名为$IF1，第二块网卡名为$IF2；然后，设置网卡1和网卡2的IP地址分别为ISP分配的IP地址$IP1和$IP2，设置ISP1和ISP2的网关地址分别为$P1和$P2，网络地址分别为$P1_NET和$P2_NET。配置如下：

随后，设置缺省路由和路由规则，即选择用什么路由表进行路由转发。需要确认当数据从一个给定接口路由出数据包时，是否已经有了相应的源地址，这就要求保证如果知道相应的源地址，就能够把数据包从相应的网卡路由出去。以下命令保证所有的回应数据按用户访问地址源线路进和源线路出：

对高校而言，ISP分配给高校的IP地址资源有限，或多或少存在地址短缺的现状。通过本方案，可以节约IP地址资源，减少应用服务器管理配置。

域名解析采用“智能DNS”，将用户访问引导到最优的资源上

根据访问者来源，将访问请求解析到合适的运营商链路上。可根据资源状况，选择商业产品或者使用BIND view功能【2】。BIND配置示例如下：

acl "CERNET" {

//https://www.nic.edu.cn/RS/ipstat/

//region=BJ

162.105/16; 166.111/16; 202.4.128/19;

}

此配置中，以CERNET为例定义了ISP IP地址段的访问控制策略（ACL），来自这个IP范围的用户请求解析域名时，会从特定的数据库查询解析IP地址并回复给用户，实现按照用户来源优化使用ISP链路资源的功能。其他ISP的访问控制也可以参照此建立视图保证用户的高速访问。

NGINX 体系集中访问者请求，转发到真实服务器

NGINX配置示例【3】如下：

此配置中，UPSTREAM为提供服务的原始服务器（上游服务器）。

利用Memcache缓存静态资源

Memcache是分布式内存高速缓存，内置于NGINX中，适合混存网页静态对象，可以降低原始Web服务器因IO瓶颈造成的性能问题。配置示例【4】如下：

配置中把所有请求URI的访问用Memcached模块进行内容读取，同时使用请求URI作为Memcached的key。当缓存没有命中或者出错时，调用@fallback进行处理（比如访问实际的应用并重新写入缓存）。

NGINGX默认将资源缓存到硬盘。当无法从原始服务器获取最新的内容时，NGINX可以分发缓存中已有的内容。避免了因关联缓存内容的原始服务器宕机或者繁忙时，返回客户端错误信息，而可以发送其内存中已有的文件。考虑到访问量大后的文件系统承载能力问题，本文架构中使用Memcache缓存到内存，通过配置UPSTREAM支持访问多个Memcached服务节点。同时，设置缓存过期时间，并在缓存内容前添加浏览器缓存相关的响应头，将将页面缓存在浏览器中，从而不必每次访问都请求服务器。

安全管理

屏蔽对真实服务器的直接访问，转发经过适当过滤的Web访问。由于NGINX对Web的转发工作于应用层，NGINX可以设置一些转发规则来屏蔽对敏感信息的访问，有利于提高Web整体安全性。

NGINX设置转发过滤规则

由于个别系统管理员的疏忽，可能会把本该限定在校内访问的资源（如后台管理、数据备份等）暴露在互联网上，增加了安全隐患。在NGINX下，可以设置全局或针对特定Web系统的过滤规则来降低安全风险。配置示例【5】如下：

此配置中，屏蔽了对admin目录和rar、zip后缀文件的访问。

可增加WAF模块提供更全面的Web安全防护功能

传统的防火墙工作在网络层，这种方式对于Web应用没有任何的防护。IDS/IPS作为防火墙的有利补充，加强了Web的安全防御能力。但是，IDS/IPS需要预先构造攻击特征库来匹配网络数据，技术本身存在一定的局限性。

与传统防火墙及IDS/IPS不同，Web应用防火墙（Web Application Firewall，WAF）工作在应用层，一般位于Web应用服务器前，可以从行为来分析应用层的流量以发现安全威胁，帮助减少由于开发人员的疏漏造成的常见攻击问题。将发现的漏洞作为自定义规则嵌入WAF中，能够减轻目前Web漏洞解决的滞后性问题。如果暂时没有配备商业WAF系统，可以选用NGINX兼容的WAF软件，进一步增强Web安全防护能力。常见的有NAXS、ModSecurity等。

HTTPS卸载

HTTPS对Web应用安全非常重要，越来越多的高校Web业务会使用HTTPS证书。与其把证书分散部署在各服务器相比，集中式的Web管理体系配合通配符型的证书更经济，管理更方便，同时降低了证书泄漏的风险，保证了安全性。

遗留Web系统启用HTTPS协议时，往往会遇到网页链接混乱问题，使用NGINX可以灵活的替换网页内容，也可以用rewrite解决这个问题。配置示例【6】如下：

在此配置中，NGINX对特定的连接进行了全文查找并替换，可以在不修改原始网站或系统代码的情况下，引导用户使用HTTPS协议访问系统，提高信息安全性。

Web管理和安全应急响应

应对网站、Web应用管理需求和安全事件应急响应时，使用NGINX作为应用层代理，存在一个真实服务器与域名之间的管理问题。通常使用多个DNS系统来解决，但管理工作量较大，灵活性较差。通过借助合适的NGINX第三方模块，可以简化管理工作，提供更高的灵活性。

UPSTREAM的动态管理

通过UPSTREAM动态管理模块提供的API接口构建管理体系，利用管理平台来管理Web系统域名与真实服务器（上游服务器）的对应关系。下面以ngx_http_dyups_module为例【7-8】:

ngx_http_dyups_module提供的API接口为REST类型，REST API主要目的在于为App后台提供后台管理入口，可实现简单的数据管理、单发/群发消息，开发者可以在控制台上进行简单的数据管理、查看及测试。为了安全性，REST API仅提供HTTPS接口。添加UPSTREAM示例如下：

为安全应急响应提供快速处置接口

利用API接口，可以在发生安全事件时及时响应，将出现问题的网站实时重定向到特定的页面，尽可能降低影响。为自动化运维和值班提供可靠的工具。

为开发环境、测试环境和生产环境提供快速切换

规范化的开发一般要区分开发环境和生产环境，甚至有些还需要测试环境。利用集中的Web管理体系，可以方便地切换上游开发、测试和生产服务器，对用户的干扰较小。

屏蔽非授权域名使用校内服务器资源

NGINX工作于应用层，可以设置允许访问的域名，避免非授权域名使用校内IDC资源提供服务。

全面收集Web访问日志

使用集中的Web管理体系，可以汇集所有的Web访问日志，为“大数据”应用提供素材，为网站日常维护提供依据。

运行效果

根据业务类别和优先级别，我们在校园网数据中心部署了两套NGINX服务器集群，节点1负责学校主页访问控制，节点2则承载了200多个校内院系和部门主页的集中访问。2017年7月最新数据统计显示，节点1和节点2日页面流量（Page View，PV）峰值均达百万级，节点1为110万，节点2为150万，系统承载性能可靠。目前的方案从数据中心管理中遇到的实际问题出发，解决了校园网公网IP资源紧张，大量应用系统配置繁琐，开发完成后维护跟不上等状况；对于一些核心的业务系统如教务管理系统，可能出现密集访问高峰期，如集中选课、集中评教等，可以通过配置NGINX的负载均衡模块来平衡流量。

[1] Bert Hubert. A very hands-on approach to iproute2, traffic shaping and a bit of netfilter. Linux Advanced Routing & Traffic Control HOWTO. 2002.From http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html

[2] Internet Systems Consortium, Inc. ("ISC"). BIND 9 Configuration Reference. BIND 9 Administrator Reference Manual. From https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html

[3] NGINX documentation. Module ngx_http_proxy_module. 2017.From http://nginx.org/en/docs/http/ngx_http_proxy_module.html

[4] NGINX documentation. Module ngx_http_memcached_module. 2017.From http://nginx.org/en/docs/http/ngx_http_memcached_module.html

[5] NGINX documentation. Module ngx_http_access_module. 2017.From http://nginx.org/en/docs/http/ngx_http_access_module.html

[6] Igor Sysoev. NGINX documentation. configuring_https_servers. 2017.From http://nginx.org/en/docs/http/configuring_https_servers.html

[7] Update upstreams' config by restful interface. 2017.From https://github.com/yzprofile/ngx_http_dyups_module

[8] Stephen Corona, NGINX a practical guide to high performance, O’Reilly, 2017.