在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等級別，每種級別中有不同的日誌代碼，根據日誌代碼可以查詢到問題表述，可以幫助管理人員有效的解決問題。
