利用Nginx做反向代理搭建ArcGIS 10.1 for Server集群环境

　　搭建GIS Server集群环境时，通常不建议在GIS Server之间设置防火墙；而建议在服务器环境的前端设置反向代理来隐藏服务器环境的真实地址及端口，保险起见可将反向代理放入DMZ区（前后都设置防火墙），增加安全性。

　　ArcGIS 10.1 for Server做出的架构改进使得我们在搭建GIS服务器集群环境时更加容易和省心；Nginx因其高性能，耗资源少，稳定性高，成本低廉，配置简单等诸多特性被越来越多地使用。这里简单介绍如何利用Nginx做反向代理并实现Web层的负载均衡效果，来搭建ArcGIS 10.1 for Server集群环境的过程。具体环境如下：

• 192.168.0.247（Windows Server 2008 R2）：安装Web Server（IIS 7.5），Web Adaptor（使用默认80端口），ArcGIS 10.1 for Server（使用默认6080端口）；
• 192.168.0.244（Windows Server 2003 R2）：安装Web Server（IIS 6.0），Web Adaptor（使用默认80端口），ArcGIS 10.1 for Server（使用默认6080端口）；
• 192.168.0.69（Windows 7）：运行Nginx，监听本地80端口；

其中192.168.0.247和192.168.0.244两台机器安装ArcGIS 10.1 for Server，加入同一个site，组成GIS Server集群，并分别安装Web Server和Web Adaptor，组成Web Server集群；192.168.0.69机器上运行Nginx，监听80端口，充当反向代理服务器，并将接受到的请求负载均衡到247和244两台机器上。这样既利用了企业级Web Server的性能，也一定程度上保证了内网环境的安全。Nginx配置过程如下。
　　由于是Windows环境，从官网上下载稳定的1.2.3版本，解压到192.168.0.69机器的c:\nginx-1.2.3目录下。因为我们打算让Nginx监听80端口，所以需要将本身占用80端口的IIS默认网站停掉。打开conf目录下的nginx.conf文件，修改如下：
　　命令行方式输入'start nginx'启动Nginx，然后发送请求到192.168.0.69机器的80端口：
　　看到请求被转发到了247机器的IIS 7.5上，再次刷新，
　　请求已经轮询到了244机器的IIS 6.0上。最后通过69机器来访问ArcGIS Server的Services Directory，
　　此时Nginx会以轮询的方式访问247和244两台机器的Web Adaptor。
　　这里只是针对ArcGIS for Server集群环境配置做了简单介绍，在实际中可能还需考虑搭建可容错的共享存储环境，DNS服务器的配置，硬件防火墙的配置，Nginx具体参数的配置等因素。

ArcGIS 10.1 for Server机器判断本机是否已经加入site的依据

　　在一台机器上安装ArcGIS 10.1 for Server后，它还无法立即工作，必须将其加入site（的cluster）之中才行。首次登录manager时，也会询问创建新的site还是加入已有的site；如果已经加入site，登录manager则会显示该site的管理目录。那么机器自身是如何判断出自己是否已经加入site了呢？
　　依据就在于Program Files\ArcGIS\Server\framework\etc目录下的两个xml文件，config-store-connection.xml和machine-config.xml。加入site时会在本机创建这两个文件，退出site时会删除之。前者记录site的公用信息，后者记录本机在site中的信息，具体内容大家可以自己查看。
　　登录manager时会读取这两个文件，如果找不到，则认为自己没有加入site，会询问创建新site还是加入已有site；如果有这两个文件，会首先访问site的config-store目录验证其内容，合法的情况下就打开site管理目录。 如果在一台机器关机时，从site中将其删除，开机后会根据config-store-connection.xml内容去site的config-store目录中验证，发现自己已经被从site中移除后，会自己删除本机的这两个xml文件。
　　此外，如果你的机器已经加入了site A，但现在需要临时加入site B去做一些工作，就不用在admin api去删除site A了，只需将上述两个xml文件先转移到别的地方，然后登录manager，选择加入site B即可；之前site A的config-store内容可以保留，以便将先前挪走的两个xml文件复原后（需要重启ArcGIS Server服务），登录manager即可直接返回site A。

ArcGIS 10.1 for Server中Web Adaptor的工作原理

　　ArcGIS 10.1 for Server的安装目录中，都会内置一个tomcat（Program Files\ArcGIS\Server\framework\runtime\tomcat\），无需单独的Web Server即可发布各种GIS服务（对于熟悉.NET的朋友来说，更省去单独安装和配置IIS的步骤）；AGS应用程序的端口号也由之前版本的80（ArcGIS Server for .NET）和8099/8399（ArcGIS Server for Java）统一到了6080上，比如http://localhost:6080/arcgis/rest/services和http://localhost:6080/arcgis/manager等。但对于内置的这个tomcat，我们并不能进行过多的操作，如果需要部署Web应用或通过别的端口来访问ArcGIS for Server的服务，这时就需要用到新的组件：Web Adaptor了。
　　Web Adaptor实际上是安装在Web Server机器上的一个Web应用程序，负责将Web Server接收到的GIS请求转发到ArcGIS Server site内的GIS Server机器上去。通过Adaptor这个桥梁，我们就能使ArcGIS for Server利用到企业级Web Server的诸多优势。根据安装帮助中的解释，安装Web Adaptor后主要有以下好处：

• 将单独的企业级Web Server集成到ArcGIS for Server的部署架构中来。可以将利用ArcGIS for Server服务的Web应用部署到Web Server上去；可以为site内所有的GIS Server提供不含有6080端口及arcgis等字样的统一访问入口点；
• 可阻止最终用户通过Web Adaptor的访问地址连接到ArcGIS for Server的相关管理程序。比如用户如果得知了类似6080端口的GIS服务访问地址，就可通过固定的url地址访问到Manger，Admin api等涉及到整个站点操作的内置应用。而Web Adaptor给我们提供了选项，可禁止用户通过Web Adaptor暴露出的GIS服务地址访问到这些管理应用。

此外，相对于site内的多台GIS Server机器，Web Adaptor还可以再次（除了Web Server集群外）起到负载均衡的作用，这在大并发量的情况下会比较有效。假设一个site内有n台GIS Server，它们所能处理的最大并发请求是1w个；根据ArcGIS for Server中p2p的实时通信架构，当我们将1w个并发请求发送到任一GIS Server的tomcat上时，GIS Server之间会自动以轮询（默认设置）的方式处理这些请求，GIS Server们完全可以及时响应；但1w个Web请求会首先使接收请求的这个tomcat过载，产生瓶颈。如果有了Web Adaptor，当这1w个请求到达Web Server（集群）时，Adaptor会将这些请求轮询发送到每个可用的GIS Server去，这样每个tomcat就只需支持1w/n个并发即可，可最大限度利用硬件资源。
　　以IIS中的Web Adaptor为例（经过Java高手验证WebLogic和WebSphere的Adaptor工作过程与此是完全一致的），看看反编译后的代码。通过查看inetpub\wwwroot\arcgis\Web.config文件得知，IIS中的Web Adaptor主要的工作过程都集中在ESRI.ArcGIS.WebAdaptor.dll（在GAC目录中）里。这个dll里首先找到两个类：
　　一个Node就对应一个GIS Server机器，_healthy标记该机器的可用状态；NodeManager是所有Node的管理类。Web Adaptor启动时，会调用WebAdaptorConfig.GetMachines()方法，此方法会向http://siteip:port/arcgis/admin/machines发送get请求，获取site内所有GIS Server机器的列表，然后利用UpdateNodeList方法保存在NodeManager类中，并写入WebAdaptor.config文件。
　　此外，最重要的是一个叫AGSHandler的类，它实现了IHttpHandler接口：
  　　发送到Web Server的GIS请求都会由其中的ProcessRequest方法进行处理。前面说过Web Adaptor是以轮询方式转发请求的，而_currentNodeIndex便记录了请求转发目标GIS Server的在Nodes列表中的索引：
　　Web Adaptor接收到发到Web Server的GIS请求后，首先会读取初始化时保存的WebAdaptor.config配置文件并查看里面存储的GIS Server机器列表，如果读取失败或者机器个数为0，都会响应500的错误。如1所示；接下来会利用try里的TransferRequest方法将请求转发到具体的GIS Server（的tomcat）上去，如果转发的这个机器没有响应，则会在catch中将此机器利用MarkUnHealthy方法标记为不可用；而不论当前节点是否成功接收请求，TransferRequest方法中都会将_currentNodeIndex节点加一，保证下一个请求发送到下一台GIS Server上去，以实现轮询请求的事实：
　　最后来看看Web Adaptor是如何根据配置文件的间隔时间去追询标记为下线机器的状态，在机器上线后又将它们加回可用机器列表的：
　　可以看出，Web Adaptor检测到没有响应的机器后，除了标记其为不可用，也会同时启动一个定时器，此定时器逝去配置文件中的检测下线机器状态时间间隔（分钟）后，会立即将这台机器重新标记为可用，而不会去检测它事实上是否可用。判断机器是否真正可用的过程还是通过前面TransferRequest方法来完成的，即直接向其转发请求，如正常响应，证明其已经在线；如不能正常响应，则再次标记其不可用，重新启动定时器进入下一个轮回…
　　大家可以想一想，整个过程是否有不合理的地方呢？