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

  ArcGIS 10.1 for Server的安装目录中,都会内置一个tomcat(Program FilesArcGISServerframeworkruntimetomcat),无需单独的Web Server即可发布各种GIS服务(对于熟悉.NET的朋友来说,更省去单独安装和配置IIS的步骤);AGS应用程序的端口号也由之前版本的80(ArcGIS Server for .NET)和8099/8399(ArcGIS Server for Java)统一到了6080上,比如http://localhost:6080/arcgis/rest/serviceshttp://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工作过程与此是完全一致的),看看反编译后的代码。通过查看inetpubwwwrootarcgisWeb.config文件得知,IIS中的Web Adaptor主要的工作过程都集中在ESRI.ArcGIS.WebAdaptor.dll(在GAC目录中)里。这个dll里首先找到两个类:
image  一个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接口:
image  发送到Web Server的GIS请求都会由其中的ProcessRequest方法进行处理。前面说过Web Adaptor是以轮询方式转发请求的,而_currentNodeIndex便记录了请求转发目标GIS Server的在Nodes列表中的索引:
image  Web Adaptor接收到发到Web Server的GIS请求后,首先会读取初始化时保存的WebAdaptor.config配置文件并查看里面存储的GIS Server机器列表,如果读取失败或者机器个数为0,都会响应500的错误。如1所示;接下来会利用try里的TransferRequest方法将请求转发到具体的GIS Server(的tomcat)上去,如果转发的这个机器没有响应,则会在catch中将此机器利用MarkUnHealthy方法标记为不可用;而不论当前节点是否成功接收请求,TransferRequest方法中都会将_currentNodeIndex节点加一,保证下一个请求发送到下一台GIS Server上去,以实现轮询请求的事实:
image image  最后来看看Web Adaptor是如何根据配置文件的间隔时间去追询标记为下线机器的状态,在机器上线后又将它们加回可用机器列表的:
imageimageimage  可以看出,Web Adaptor检测到没有响应的机器后,除了标记其为不可用,也会同时启动一个定时器,此定时器逝去配置文件中的检测下线机器状态时间间隔(分钟)后,会立即将这台机器重新标记为可用,而不会去检测它事实上是否可用。判断机器是否真正可用的过程还是通过前面TransferRequest方法来完成的,即直接向其转发请求,如正常响应,证明其已经在线;如不能正常响应,则再次标记其不可用,重新启动定时器进入下一个轮回…
  大家可以想一想,整个过程是否有不合理的地方呢?

Leave a Comment

Your email address will not be published. Required fields are marked *