3sNews讯 为期两天的2012地理信息开发者大会(简称：WGDC)在北京国家会议中心举行，本次大会以“新技术、新模式、新商业”为主题，是地理信息领域最具影响力的技术性盛会，其宗旨是不断引领和促进地理信息技术的创新与变革。在第二天“Map+与开发者训练营”分会场，来自易智瑞(中国)信息技术有限公司的高级应用咨询师许哲发表了题为《ArcGIS 10.1 for Server技术架构》的演讲。
易智瑞(中国)信息技术有限公司的高级应用咨询师许哲
以下为文字实录：
刚才我在外面跟很多朋友聊天的时候，我说下午的讲座一般两场讲座都是比较困难的，都是有历史责任的。第一是下午第一场讲座，负责把大家的耳朵叫醒，把眼皮撑开，最后的一场讲座往往是结束大家快乐或者是痛苦的一个过程。今天我跟大家分享的内容会稍微简单一些，大家从低头做我们应用或者是开发的同时，能抬起头来看一看现在大家怎么样去应用这些新的技术，去构建自己的产品或者是服务，有什么样的实施可以用于我们的项目或者是后续的内容。
我想对于ArcGIS for Server这个产品，大家如果做开发的话会比较了解，在10.1这个新的版本上会为我们带来哪些改变，今天我们从一个架构的角度来去跟大家解析一下新的产品有哪些新的改变。我们平时在做大量的产品或者应用的时候，尤其接触到很多的客户做一些产品或者是做一些功能，做了很多功能，客户的需求都达到了，有很多非常丰富的功能。后来谈到面临的是性能的问题，后来说把这些东西进行整合，面临着这些东西到底如何去整合?它会从一个比较大的角度去考虑，就会考虑到什么是架构，或者说我们这个架构到底应该怎么做。
这里面架构的定义无序过多的复述。我们做了大量的应用，相信在座很多的开发人员应该是用ArcGIS for Server做开发，今天大家有些人问我你们的产品是什么样的?我简单给大家说一下ArcGIS for Server。其实我们平常的日常工作当中会经常遇到这些的问题，经常打交道的就是我们的数据如何去管理，我们如何到最后去支持大用户量的并发以及如何去满足我们用户对性能上的需求，以及现在我们的智能终端，以及在手机上有更多这样的应用。对于这些问题，你们的产品或者是用一个什么样的方式可以很好的解决这些内容。
我们现在重新来看ArcGIS for Server。其实它就是一个用于共享的平台，大家说我们如此简单定义的这些内容，对于我们开发人员来说会考虑哪些内容?我们可以看一下，这些问题我们是不是经常问自己?你既然是一个共享的平台，或者说我们做了那么多的功能，其实在最后我们会问自己，我们在共享什么?或者说我们拿什么样的东西去满足用户的需求?东西越来越多，这些资源如何去整合?怎么样去完成这样一个共享的命题?我们共享出来的这些内容，跟谁一起去分享?基于一种共享的环境，我们能做哪些内容?我会跳出我们做具体的功能上来完善，跳出这个圈子我们来考虑一下这些内容，这是很多客户做了很多东西的罗列之后，会从上至下考虑这个问题。现在大家做了很多工作的是共享平面的地图，这是大家现在做得非常成熟的，对于GIS核心的内容有这样的需求，无论是从管理方面的需求，还是基于影像的一些运算，核心的是我们的数据是不是能和大家分享，愿意不愿意分享是另外一回事。还有GIS说的分析，或者是基于GIS数据的统一、整合和发掘是GIS的核心内容，我们能不能把我们一些日常工作的经验，这些工具拿出来也跟大家分享，去减少其他人在做同类工作的一些时间。我们会完成这么多内容的分享，大家看到外面的展台或者是新兴应用，你的位置信息，有大量的位置信息产品，POI以及物流配送的应用，都会用到这些东西。
我们如何把这些内容通过一个统一的平台，以一种整合的方式和大家一起在这个上面做一些应用?我们看这个平台能为我们带来什么?以前我们可能通过最早的这种方式，比如说文件，或者是通过局域网的等等。随着互联网这种发展，第一天一直谈到GIS是不是主流IT的追随者，或者是创新的这样一个话题，其实归功于主流IT的发展，随着互联网的发展，Web Service逐渐的成为大家共享的平台，提供什么方法和渠道通过Web Service进行共享?Rest API是近两年来大家一直追捧和热捧的方式。相对于Rest，另外一种主流的或者大家用的比较多的是基于Soap的方式，会比Rest有非常严格的协议或者是规则。我们都可以借助Web Service共享上面的内容，我们可以共享平面的地图，基于三维的这种服务或者是实体的影像去做一些更高级的应用。一些异构的资源，就要求你的平台也好，或者说你自己做的产品也好，能不能有一个很好的支持。我们谈到这些工具的使用，现在逐渐被大家所认知的应该是把经验积累，我们可以采用这种方式，可以满足需求。我们这样一些技术手段到底谁来用?我们给谁去用?现在这种共享的方式大家可以看一下这个截图，如果我们做完了这样一个服务和应用的话，我们可以通过非常简单的方式就可以嵌入到自己的业务系统里面来。比如说我们从上面的接触来看，以一种应用的方式共享出来。另外现在大家的这些自己的网站，或者说社交的这种媒体，我可以把这些基于地图的一些应用，位置的信息，很快速的和其他IT资源进行整合。
前面谈到了我们如何去做，提供什么，以什么样的方式跟大家进行共享。下面的内容是跟大家分享的核心内容，就是说你能够做到这样的东西，你可能会考虑到下一个问题，你能够保障你的性能，你用什么样的方式去保证你的性能，我们来看一下如何去考虑这些问题。其实这个架构的问题是无关于功能的，和功能没有什么相关性的，它只是去考虑在你的整体应用里面，那个2%和性能相关的一部分，很大的一个关系的内容。在10.1Server的架构图更加的清晰和简单，但是这里面存在着一个很大的变化，一会儿我可以给大家详细解析这个变化主要发生在哪里。我给大家看一下现在应用的方式仍然没有变，无论你的终端是桌面的、Web的，只要希望加载这个资源，都可以对你的Server提出请求，在大型应用系统里面，你肯定会考虑在Web Server这一层架构这个内容。访问GIS Server，这部分的内容是GIS真正在发挥作用的一个地方。下面当然是我们的数据资源，可以是异构的，也可以是统一的，或者说我们前些年所提到的这种一张图或统一式的管理。不管怎么样，下面是数据资源。
我们对这样一个大型的平台，或者是Server这样一个分享的机制，我们如何去管理后面这样一个平台?可以在这个层面上，通过两种方式进行整合和管理。你可以通过一个Web页面的工作界面去管理众多的GIS Server，也可以通过桌面软件去管理我们这些上述的资源。GIS Server和以往有一个很重要的架构上的变化，大家可以看到，以往的架构里面上面可能还有其他一些东西，之后才是GIS Server自己内部的核心，而现在整合架构图上大家可以看到，这部分空间被明显的压缩了，只有一个GIS Server，这个GIS Server和以往我们所提供的GIS Server有什么样的区别?当然这个GIS Server可以理解成是和任何产品和平台都没有关系的，你去做一个或者是拿到一个开源的GIS Server，只要是做GIS的，可能都要去满足这样的一些功能。核心的你要能够满足客户端对于GIS的各种请求，包括客户端地图的绘制，工具的这些，或者是数据的查询。包括刚才讲的这种查询，在数据库层面上是怎么样一个实现的过程。对于前端来说，无论从哪里提交这样的一个请求，真正帮你完成实际工作的，是以GIS Server为强大的力量，对后台数据库进行一个交互。当然，对于Web来说，你能够提供HTTP这种服务，是最基础的内容。
这里面对重要的一部分，大家对于这个能不能够进行分组，这里面现在在这种大规模的群集性架构的时候变得尤为突出，当你的性能遇到瓶颈的时候，大家总会想到用什么样的方式去解决。现在大家比较通用的，其实无论是哪种平台，或者是哪种技术，他会支撑这种庞大的复杂请求，或者是并发的时候都会采取这种架构，包括数据库也是一样。像Oracle也有这种群集架构的基础，GIS Server也会有这样的内容。对于我们小规模的应用，或者是传统的应用没有那么大型的一些并发请求的时候，我们能不能去节省一部分经费，压缩一下整体的所有组件的内容，或者说我们经费的开支?GIS Server其实内置了一个Web Server，当你的请求或者说你的任务量没有那么大的时候，GIS Server内置的Web Server就足可以满足我们这样的一个需要。
刚才谈到了这种群组或者大规模集群应用面临的问题，就是说你的软件能否进行自己的负载均衡?如果你没有个机制的话，那么我可能会借助于外部的技术或者是一些软件，或者是一些硬件，无外乎会给大家整体的从技术角度来说，把你的系统变得非常复杂，因为你这里面会搀杂着各种各样的技术或者是产品。如果说我们自己就可以完成这个事情的话，相对从各方面来说，会变得简洁，也会变得非常简单。
这里面GIS Server在10.1之后会提供一个非常有趣的功能，或者是非常实用的一个功能，这个功能叫做群集。这种需求在哪里呢?比如说我们现在这种大型的应用，里面地图当然是主体。还有一部分内容，比如我们刚才谈到的，要做一些实际的业务应用，比如说我们的选址，肯定是有一个分析的过程。当我把这些所有的一个请求一股脑的丢给GIS Server的时候，是又要地图，又要请求，大家一起来做，这是负担比较重的一件事情。并且从某一种系统底层架构来说，它们之间会产生频繁的交互，或者说从隔离的角度来讲，可能都是很复杂的一个事情。现在我们能不能期待这样一种东西?你的这些服务器拿出来做一个分组，它只接受单一的一种请求，就是让很擅长的这一部分人去做他所擅长的事情。那么对于GIS Server10.1这个结构，它提供了这样一个群组的功能。比如说我们现在有10台机器，其中有两台机器性能是非常好的，或者说有其他的几台机器性能非常好，我们就可以把它单独的划出来，去完成一些运算频率比较高，或者说负载任务量比较重的面。而把相对来说做这种地图切片请求的，单独放到一台服务器上。因为我们无论是Google为也好，百度也好，或者是搜狗做地图的，现在在互联网上大家做Web地图，很多的都会采用缓存机制。对于服务器来说，已经缓存成图片了，可以以流媒体或者是其他的方式返回回去。这部分的内容并不需要性能非常好的机器去支持，就可以把以前大家可能在几年前购置的一些硬件利用起来，把它作为一个群组，给它完成这部分的内容。刚才我们谈到对机器性能要求比较高的这些内容，这些机器组织在一起，完成一些需要花费很大的资源才能完成的请求，也就是说你的分析、处理请求，这是10.1上Server里面比较新的一些特点。
在10.1里面现在增加了这样一种组件，叫做Web Adpator，如果是单机应用的话，不需要去装这样一个组件。刚才我说了，本来GIS Server内置了一个Web Server，如果请求不是那么多，它自己完全可以支撑住。如果用下面很多机器做了一个群集之后，你这些机器要识别，哪些请求发送到哪些机器上，从这些机器再选择一个结果，并且让这些机器做这个事，那些机器去做那个事情，这些任务，这个请求怎么分配?我们就可以通过这种组件来完成。并且这个组件也可以去监测到它下面所管理的这些Server的状态，它是否Down机了，之后我不会把这个请求发送到这些机器，以免耽误工作流程，这是10.1里面新嵌入的一个组件，Web Adpator。
Web Server其实大家已经很熟悉了，无论是做GIS也好，非GIS也好，做互联网应用的话，很多都有Web服务器，在整个10.1的架构里面会被分成两部分。第一就是它自己内置的一个Web Server，刚才大家已经谈到了。如果你觉得我现在的应用负载比较强，有可能我需要一个很好的性能，并且我在这个层面上恐怕还有一些其他的要求。比如说我这种带宽就这么多，我需要在Web Server这个层面上去做一些负载，去做一些其他的应用需求，你可以把它换成这种商业化的IIS、WebSphere这种Web Server，可以给大家更多更灵活的选择空间。
在整个架构里面突出的一个概念叫做站点。什么意思呢?以前我们发布了一个Web应用可能就是一个请求，现在加入了刚才我们所说的，我们可以多台机器一起去完成这个事情，这些机器如何分配和协调，现在把所有多台的GIS Server组成了这样一个东西，就是站点。这个站点之内可以有一台或者是多台的GIS Server，如果是多台机器协调的话，这里面可以有Web Adpator，对于数据这些层面，怎么样让大家知道这些数据资源是怎么样分布的，可以通过站点里面的这些配置，或者说这些目录里面所带的配置文件来进行识别。里面多了一些目录，我们如果看一下，这些东西真正的去完成哪些内容，帮助我们解决哪些问题。
配置这些目录，其实是我们在创建站点的时候，无论你是装一台机器还是多台机器，这个时候你都要在这样的一些机器系统里面去配置这些位置。在创建站点时期，存储的是整个大站点里面关键的一些应用的配置信息，能够使整个庞大的系统能够协调在一起关键的地方。它包含了比如说参与到你这个大的站点的这样一个组织里面，所有的机器信息，还有我们如果划分群集的话，你这些群集是由哪些机器完成的，或者由哪些机器所组成的，也是利用站点的配置来完成的。对于站点的整个假设来说是非常关键的，也就是说里面配置信息的存储。现在我们多了很多这样的目录，这里面有我们所熟悉的，比如说我们的Cache，我们的Jobs，或者是一个请求提交过来之后，会在里面帮你建一系列的目录，识别你的请求。这里面还有我们经常所熟悉的Output，你所有的请求会以一张图片的形成或者是什么样的形成保存在目录里面。但是大家可以看到，这里面多了一些其他的目录，比如说我们的Input，我们的System、Upload，这些目录都是用来做什么的?我们可以从下面来看一下。
相对于这样一种架构，这是10.1之前的架构，它们之间有什么样的对比或者变化?大家看到，以前的是一样的，客户端的请求是一样的，对于Web Server也没有什么太大的差别。以前我们SOM、SOC类似于一个消息总线，你所有的请求经过它，它只是把你的请求分配给具体完成这个请求的机器，那么请求完之后，它又从原路返回到客户端。大家设想一下，对于这种架构，当你所有的任务量所有都集结在这里的时候，下面再分发，无外乎它会成为一个性能的瓶颈。对于这种架构有什么样的优势?我们可以看一下，首先可以看一下GIS Server变化单一的组件，不再采用这种SOM、SOC的管理机制。另外我们可以看到，Web Server现在分成了两部分。本身在GIS Server里面有一个内置的Web Server，如果大型应用的话也可以和Web Adoptor共同组合成在Web层面的负载和层次，并且这些所有的Server之间是互相预知或者互相感知的。这意味着什么?以前这两采机器之间是互相没有通讯的，那么它所有的通讯都是通过上你的SOM，一旦划了之后，它要经过SOM一定的检测才能知道我的请求不能再往这里发了，或者说这台机器的负荷已经满了，我需要分配到其他的机器上，多了这样一个环节，对于用户最终的体验上，你的时间，你的转发机制，里面耗费的时间请求，最终就体现到我们的这种用户体验上，感觉打开很长时间没有反映，可能是因为里面一台机器已经挂掉了。但是采用这样一种架构之后，所有的请求归结到Web Server或者是Web Adpotor这个层面，可以优先选择我们下面多台的GIS Server。它们之间互相识别的好处就是说，以前这种架构是像我们写论文一样的模式，但是现在完全是一种交叉的，这种网状结构，你给我一个请求，但是你的任务量已经满负荷了。我就会知道，我的部门里面还有其他的同事是可以，还是业务量不饱和的，可以把这个内容请求给他。所以它们之间是一种网状，互相能够通信和互相能够协调的这样一种机制。在我们所谈到的云环境下，这一点其实就有一个非常好的先天优势，可以充分的去调配其他的资源。
GIS Server取代了SOM和SOC这种架构方式，另外内置了Web Server，当多台和GIS Server需要协调和保持一致工作的时候，我们可以用适配器的模式，去为我们多一个非常灵活的选择。还有就是说，我们可以在GIS Server之间集成群组。这样的一个架构，相对以往的这种组织方式是一种全新的模式。大家可以看一下，这种模式对于现在我们谈了很多用云的一些内容，云是有很多的特性，大家其实是抓不着，看不见的。但是有一个特性大家是耳熟能详的，比如说你的弹性，你的这种可调性，或者是你的这种服务的体现。比如说这种弹性是云非常重要的一个特点，这种弹性如何去实现?大家考虑过吗?如果你的机器一定要装到一个机器上去，你的软件一定装到一个机器上去，当资源不够的时候怎么办?还要先装一个放进来，连进来。现在采用这种方式，其他所有的机器，你的资源如果不够了，紧张了，它可以动态的去调配。因为所有的GIS Server之间是平等的，不存在谁是管理的角色，谁是被管理的角色。我们大家都是互相平等，互相交叉的一个组网的情况，就可以有利于这些资源快速的调配和分发。
刚才谈到几步的组件或者说这样一种架构的模式。对于我们如何去部署我们的应用，其实就给大家一个很大的灵活空间了。在讲部署的时候有一个原则，就是你所有的GIS Server要知道你的资源在哪里，这是要先解决的问题。我的Server架构是好的，但是我的内容却不知道在哪儿，这是一个很糟糕的事情。这样的话，我首先会去完成我数据对于Server的可到达性。另外对于一些比如说这种情况，我的数据比如说做好了，很多部门做好了这样一些数据，通过GIS Server发布出来，他们之间并不知道这些数据是在哪个部门的，那么怎么办?我们可以通过一种注册的方式，告诉你这部分东西注册到GIS Server里面来，告诉你这部分资源是在这里的，这样的话，它会很智能的去感知你的数据在什么位置，还有一个非常重要的就是，你要能够确保你的Server能够访问到你的数据。你的数据要对GIS Server这个帐号设置一定的权限，保证它的可到达性。
我们解决了数据的问题，资源的问题，还是刚才那个假设，如果所有的东西都在一起，都在各个不同的部门。但是我的数据又不希望是这种统一的用到一个集中的库里满去管理，我们怎么办?这种资源是否无法发挥功能和大家共享呢?实际上不是这样的，当你发布的时候，都是一个大的站点。GIS Server会帮你做一件事，就是说当你这个数据如果没有注册，那么它会检测到你没有进行注册，那我把这些数据拿走。它会把这个数据拷贝到自己的Input的目录下，这样的话，我就从另外一个技术的角度，或者从技术的层面上保证了我的数据的到达性，所以说这也是给大家去解决的一些数据的维护和管理的内容。
相对于数据的存储，如果是我的这些数据发布者和数据的所有者是一个人的时候，那么这个时候还好办一些。如果是不同的地方，那么我们刚才谈到了，是要保证你的数据能够被Server访问。另外的一种模式就是说，我们可以去保证大家约定俗成的，对一份数据进行应用。这里面就提出了一个这样的机制，你有你的数据，我有我的数据。但是我们为了共享这样一个共同的目标，可以把数据约定俗成的放到一个地方，你把你要共享的数据拷贝下来，你也无需注册，大家共同维护这个目录。这种构架和方式，以前其实通过人为的方式或者通过行政的方式来保证。比如我们北京市构建的信息系统，最终各个委办局都有一个自己的共享库，把需要共享的信息放在里面，它定期的去整合这些共享信息。当然我们看这样一种方式，就是如果说所有的数据都在各自的库里面，它们之间要保证数据的这种同步，我们用技术手段是不是可以不通过这种行政强制的命令去保证数据的完整?GIS Server其实也提供了这样一些功能，我们可以通过这样一个服务，来维护一户与多户之间的数据的共享、同步和更新。
我们刚才解决了数据的问题，数据的异构性或者数据的分布性，现在我们如果加上这样一个系统的话，其实就有非常灵活的选择了。如果对于小型应用，我们可以把数据放在一台服务器上，去维护你统一的Server。如果我们的任务量或者所维护的数据量比较大的时候，我们来看一看是否可以有其他的任务选择。像刚才谈到的，我可以去用多台GIS Server来完成我们上述的一些内容。刚才讲到智能通讯，GIS Server之间都是平衡的网状的，它们之间会利用自己的端口进行通讯，互相感知自己的业务状态。这是它们之间的通讯结构，刚才是一个过程的模拟。另外如果是说我们这里面的环境和应用的业务比较特殊，里面有很复杂的业务逻辑或者是业务归属，我们可以采用多台的Server组成不同的模式。如果我们的系统在这里，以前很多客户跟我聊到这个问题，一个SOC或者多个SOC，或者一个Web Server，如果Web Server Down掉了怎么办?可以在Web Adpator里面去请求，通过Web Adpator访问不同的群组，这样的话大家有多种选择，单机、多台，以及负载均衡、灾备和群组，所以说是灵活配置。现在10.1这个版本对照着以前10的版本，其实从架构的层面有一些本质的变化。另外去谈这个字眼，大家说这是技术还是炒作?其实不太想去关注这个问题，就是说无论是怎么样一种技术或者是一种包装，只要能够解决我们的问题，我们觉得这个东西是可以被我们来用的。
大家可以看到，这种灵活的架构，如果说云计算或者是并行计算，背后的技术就是并行计算了，这种架构其实完全是非常适合在云端我们进行部署以及进行应约和开发的结构。这种灵活的结构给大家带来的就是灵活性更多的选择。你也可以根据你的业务需求，也可以根据你的经费要求，灵活的去组合，我们到底是选择什么样的一种架构，从而能适合满足我们这样的一些需求。其实关于我们所有的产品，包括share其他更详细的产品，大家可以关注我们9月份的用户大会。
我今天从架构的角度跟大家对于10.1这个新产品进行了一些分享，以便大家以后有更多更灵活的选择。我今天演讲的内容就是这些，谢谢大家!
(以上内容根据速记整理，未经本人审核)
{{item.content}}