基于ArcGIS技术的SOA系统架构规划计算器的简介

一、概述

     近年来，随着国民经济的发展和人民认识水平的提高，GIS技术逐步地融入到了政府、企事业单位的日常办公，以及老百姓的衣食住行当中，并开始扮演者越来越重要的角色。同时，用户对GIS系统的要求也逐步地提高，他们已经不仅仅满足于功能性的需求，甚至还更关注于诸如性能、稳定性、安全性等非功能需求。而这些功能和非功能需求在系统实施过程中的平衡本身就是一个极其复杂的系统工程。因此，GIS系统实施前的架构规划至关重要。特别是近年来国际上抄得火热的SOA架构、云计算，以及国内正如火如荼开展的共享平台、数字城市的建设更能体现这点，因为这些GIS系统都具有用户量大，使用频度高，业务依赖性大等特点，因此唯有通过科学地系统架构规划才能确保整个系统具有高可靠性。然而，一直以来系统架构规划都停留在方法论的级别上，实施难度还是比较大，属于少数人的“游戏”，一般人难于入门。而为了适应当前GIS系统大量的建设需求，并降低基于ArcGIS技术的系统实施难度，Esri在其《系统设计策略》的白皮书中推出了基于Excel的系统架构规划计算器(CPT)。用户在这个计算器中能够定义基于服务的功能和非功能需求（如在线并发用户量等），以及服务器型号等参数，该计算器能够通过一系列的经验公式自动计算出系统架构规划的方案，如服务器CPU利用率、内存大小、最大并发用户量、网络支撑环境配置、分层部署方案等，并最终以图表形式展示服务访问性能的估算结果，从而快速地为架构设计者提供一个较为可靠的规划结果。如图：

图1、计算器内容结构

图2、Excel文件中的Calculator页

二、业务需求的定义

     该计算器是以ArcGIS Server提供的多种类型的服务为核心来进行业务需求的定义。如下图：

图3、功能需求的定义

      架构设计者可以对红色区域1中的白色区域对服务的参数进行设置，如服务的类型、服务文档类型（MSD或MXD）、服务地图渲染的复杂度、服务瓦片化百分比、客户端分辨率、数据类型（矢量、影像），以及图片输出格式（如png8~32、jpeg等）等参数。

在红色区域2中，设计者可以选择空间数据的存储方式，确定是采用SDE、FGDB或Shapefile等方式。如下图：

图4、数据源的定义

     在红色区域3中可以指定系统的在线访问量，方式主要有两种，即指定并发用户数或指定每小时的平均请求数(TPH)。一般来说，系统的并发用户数比较难确定，故指定TPH更能符合实际情况。

注：为了简化读者的学习难度，笔者将相关参数的介绍做了相应简化，对于那些默认值较稳定和计算器自动计算的参数，通常笔者不做介绍。若需详细了解请参看最新的《系统设计策略》文档。

三、SOA系统架构的规划

图5、系统架构的定义

在上图的红色区域4中，架构设计者可以选择ArcGIS Server集群的分层架构：

1、单层架构，即Web、SOC、数据库不分开部署，然后若干相同配置的机器组成集群；

2、2层架构，数据库与Web服务器、SOC分开部署，逻辑上分为两层构建集群；

3、3层架构，数据库、Web服务器、SOC均分开部署，逻辑上分三层分别构建集群。

同时，该计算器针对同一种分层架构提供了最低配置和最高性能两种集群结点的配置方案，如下图：

图6、最低配置                                                                       图7、最佳性能配置

      在红色区域5中，设计者能够为每层选择相应的服务器，这些服务器的配置参数（主要是CPU的相关参数，如芯片数、内核数、主频等）在Excel文件的Hardware标签页中定义，此处不详述。同时，设计者还可指定服务器的能够提供的计算能力百分比，如100%表示能为系统提供全部计算能力，50%表示能为系统提供一半的计算能力。

      在红色区域7中，设计者能够指定服务器结点是使用物理机方式还是其他各种虚拟化方式（VMware、HyperV、Xen Virtual等）部署，如下图：

图8、宿主机类型定义

      然后，计算器能够根据前面由设计者指定的参数，自动计算出如每个服务器结点的CPU利用率(区域5 Utilization)、服务器内存大小(区域5   Memory Per Node)、最大并发用户数(红色区域6 Peak Users)。

四、网络支撑环境的规划

      用户能够指定客户端网络环境中的网络带宽（LocalClient）。然后根据前面指定的服务参数，计算器就能够自动计算出每次请求的数据量，并根据在线访问量自动计算出为满足这些请求所需的最小网络带宽，以及网络带宽利用率。

五、架构性能的评估

      计算器中还提供了架构性能的评估结构，其大概估算出了在当前系统架构下，多用户访问时单用户从请求发出到请求响应过程中各阶段所需的时间，如SOC消耗的时间、Web服务器消耗的时间、网络的消耗，以及客户端消耗的时间等。见下图红色区域8。.

图9、架构性能评估

六、实例

下面以国内某大型集团公司使用ArcGIS实施的定位调度平台的需求为例。该平台要求：

1、能够支撑5万个用户同时在线使用ArcGIS Server ADF方式提供的地图要素查询服务；

2、据统计5万用户在线每小时的请求量为35万次；

3、数据库采用Oracle+ArcSDE；

4、用户网络为千兆网；

将以上需求输入计算器后，计算器得出的结果如下图所示：

图10、国内某大型集团公司使用ArcGIS实施的定位调度平台架构规划结果图

最后计算器建议采用3层架构，其中，

1、Web服务器3台共24核，CPU利用率是71%，内存24GB

2、SOC服务器5台共40核，CPU利用率是84.8%，内存24GB

4、数据库服务器1台共8核，CPU利用率是68.2%，内存58GB

平均单次请求的响应时间估算为1.02秒，与最终实际情况基本一致。

七、我们在哪

      该架构规划计算器的优势主要还是在对Web服务器和SOC服务器架构的规划上，其在数据存储以及数据库配置方面仍旧存在欠缺。而在大型空间数据提供平台上，数据存储方式往往是整个平台的最核心的问题，其对系统最终的性能、稳定性，以及可扩展性等非功能需求方面都起着决定性的作用。因此，尽管有这么方便的架构设计工具，但作为一名合格的GIS系统架构师还是应该努力地积累架构设计的方方面面的技能和经验，每次进行架构设计时，在心中就已构建出完整的设计蓝图，同时通过不断地实践和使用类似于该计算器的各种工具来验证和优化这个设计，以求真务实的态度来帮助用户设计出既能满足其需求，又能符合客观实际的系统架构。

注：计算器文件下载