在ArcGIS for Server 10.1中采用了新的模型结构：Site - GIS Servers。这里将它称为nGIS Servers，即多节点GIS Servers。新的模型架构取代了10.0以前的基于SOM – SOCs结构。
ArcGIS for Server 10.1 架构模型如下图所示：
新型的nGIS Servers模型已经没有像10.0及9.x版本的SOM主控制节点，采用点对点(p2p)的方式，即每一个GIS Server节点都是平等的。这样新模型即使是某一个GIS Server节点意外的宕掉，也不会导致整个地图服务的停止运行；同样，当需要增加一个GIS
Server节点时，以plug-in方式插入一个节点为服务提高负载能力。而这种松散的、热插拔的架构是构建云GIS应用的基石。
在逻辑上，这n个GIS Servers节点组织为一个Site站点。
ArcGIS for Server 10.1新架构模型的逻辑关系简单概括为：以Site为架构单位；Cluster为GIS 服务的逻辑单位；GIS
Server为实际处理单位；GIS Instance实例为每个GIS功能的处理容器。
1.1、Site为架构单位
ArcGIS for Server 10.1 在安装完成以后，需要确定创建一个新的Site站点，还是添加到已经存在的Site站点。如果是创建一个新的ArcGIS
Server环境，就需要选择New Site操作，在创建新的站点过程中配置了Directories和Configuration Store路径、以及Site用户信息。
只有添加到Site站点的GIS Server，才能称为Siteful的GIS Server节点，要不就为孤立的节点，是不属于架构之内。
每个Runnable的GIS Server所需的一系列数据，它们都被保存到Site相关属性里。如：所属的集群信息、服务信息、服务所依赖的数据信息、目录信息以及日志信息等等。GIS Server也是基于这些信息才能提供具体服务的。
一个具体的应用GIS环境只有一个Site站点。
1.2、Cluster为GIS
服务的逻辑单位
安装完GIS Server节点，创建一个新的Site站点后，ArcGIS Server默认会产生一个名为“default”的默认集群。以后创建的Runnable GIS Server节点都可以添加到这个集群内，当然某个Site站点可以创建多个集群。
对于某个特定的Cluster，它是某个具体服务的逻辑容器，承载的具体服务如：Map Service、GP Service等等。举个例子：现在需要发布某区域的基础地形的地图服务，就需要选择是有哪个Cluster承载这个地图服务。到此为止，用户发布地图服务的过程就完成了。当然，具体的服务能力是有下面的GIS
Server提供。
但并不是一个Cluster不是只承载某一个服务、或者某一类服务，每一个Cluster可以为不同类型，多个服务提供容器。
ArcGIS Server为 Cluster内的GIS Server通信提供了完善的协同保障，如：TCP轮询、UDP广播、心跳感应等等。
1.3、GIS
Server为实际处理单位
每一个安装ArcGIS Server的机器为一个GIS Server节点，这里的机器可以是物理机，也可以是虚拟机，当然这样的每个机器内只能有一个GIS Server节点。
上述的GIS Server节点，其实也是Siteless的节点。要想转成为Runnable的GIS Server节点，首先需要添加到Site站点内，转为Siteful的GIS
Server节点，然后添加到Cluster内，就成为Runnable 的GIS Server节点。
在每一个Cluster逻辑内可以存在多个GIS Server节点，这些GIS Server节点负载均衡上层的逻辑功能。ArcGIS Server提供了多种负载均衡的算法，对于不同的请求情况，如：密集I/O型、长事务型、高CPU型等，会自动配置到不同的负载算法。
在新模式下，GIS Server是全缓存模式的，这样性能将得到提升。
1.4、GIS
Instance实例为每个GIS功能的处理容器
GIS Instance为GIS Server的处理实例。默认情况下，一个GIS Server节点自动设置最大实例数为两个。对于ArcGIS
Server for windows版本，如果这个节点运行饱和下就是产生两个java.exe进程，这些就是处理具体功能的实例进程。
当然，对于某个负载较重的GIS Server节点，通过相关接口可以调整最大实例数，以满足处理量的需求。
ArcGIS for Server 10.1 对比于前些版本，不但提供基于操作各类Service的Rest/Soap SDK
API，如：ArcGIS API for Javascript、ArcGIS API for Flex等等；而且提供操作和管理后台的Admin API。
ArcGIS Server Admin API是基于主流的Rest框架，这样无论使用的是C/S，还是B/S；无论使用Javascript、Sliverlight，还是Flex，都可以轻松的操作ArcGIS
Server暴露出来的后台接口。
ArcGIS Server Admin API对于建设云架构的GIS应用环境是至关重要的。它提供了粒度适中的接口，让用户可以轻松的控制后台ArcGIS
Server整个运行情况，无论是动态创建、或者删除GIS Server；调整某个GIS Server的实例数；还是动态迁移Site；合并多个Cluster集群；乃至统计某Map服务的访问量；监控某个GP服务的处理时间。
Admin API让ArcGIS for Server完美的支持云架构，主要体现在主流云计算的以下几大特征中
2.1、GIS服务的智能弹性调整。
在通用的GIS应用中，伴随着用户量或者使用频率的增加，超负荷并发量的请求推向后端的GIS服务器。此时，GIS服务处理性能就遇到瓶颈。
这种情况下，我们通常需要停止GIS服务，重新构建满足客户需求的GIS环境。这就涉及到：物理服务器环境变更，如：添加服务器、或者替换为更高性能的机器；再者需要在新环境中重新部署ArcGIS Server，如：安装和配置软件、数据迁移、服务重新发布等等无法避免的操作。这些都是耗时耗力的过程，并且使得GIS应用无法满足7*24的运行。
当此应用的用户量或者使用频率下降时，根本不需要如此多资源，这样又造成严重的资源浪费。
基于ArcGIS for Server 10.1新架构下，结合Admin API可以智能的弹性调整资源。调整分为两个级别：GIS Server机器级别 和 Server Instance实例级别。资源弹性调整分为两种情况：
· 当并发负载开始增加时，首先检查现有GIS Servers机器的物理处理能力是否饱和，如果不饱和的话，增加现有GIS Server机器中的Server Instance实例数，使其达到饱和状态；随着并发量的持续增加，现有的GIS Server机器已经达到饱和状态，此时启动备用的GIS Server机器，并且平滑的将新的GIS
Server加入到GIS 服务逻辑单位中。如果并发量再增加导致新的GIS Sever机器也达到饱和，则可以继续平滑增加新GIS Server机器，达到满足用户并发量的GIS环境。 当然如果资源充足的话，可以无限的并发扩展。
· 当并发访问量开始下降时，现有的GIS Servers出现亚饱和状态，此时减少某台GIS Server机器上的实例数。伴随着访问量下降到一定程度，现有环境GIS Servers出现不饱和，此时可以平滑的将某台GIS Server移除。这样不断的动态调整，在低并发时使用少量的GIS Servers机器，而删除掉其余的机器，以达到最合理的利用资源。
上述情况的性能检查和服务调整，不管是实例级别的，还是GIS Server机器级别的，其核心功能是基于Admin API提供的。
在实际生产情况，上述两种过程是交替、平滑的发生在云端，对ArcGIS的用户来说完全是黑箱的，无论用户端使用情况如何复杂，用户都能获得流畅的用户体验。
2.2、GIS服务可度量。
GIS服务的智能弹性调整的基础是：服务可度量。通过Admin API暴露出来的某些服务度量数据，云GIS应用才能进行智能的调整资源。但是资源的弹性调整并不是GIS服务可度量的唯一用途，除此之外，它还可以向管理者反映：某服务的历史访问量、某服务操作的成功率等等。
Admin API暴露出以下重要的可度量的信息：
· 宏观信息。如Site中集群数；某个Cluster服务逻辑中的GIS Server数；每个GIS Server的最大实例数等。
· 微观信息。如：截至到当前时刻服务的访问量；该访问量占用的处理时间；服务实例数实时使用情况等。
2.3、精准的成本核算。
基于Admin API提供的成本核算也是建立在服务可度量的基础之上。根据事先定制好的服务成本系数，可以精准的核算出每个服务在某段时间的成本费用。除此之外，在Admin API上传数据时可以获得数据量大小，在按照事先定制数据成本系数，可以获得GIS数据的成本费用；再者可以结合Web服务监视接口可以获得托管在云端的应用成本费用。
2.4、完善的日志描述
在ArcGIS Server 10.1中通过Admin API暴露了完善的日志接口，不但包含系统日志，而且包含操作日志。例如：系统日志就分为：SEVERE, WARNING, INFO, FINE, DEBUG等级别，每种级别中有不同的日志代码，根据日志代码可以查询到问题表述，可以帮助管理人员有效的解决问题。
