
1. 为什么现在还有人坚持本地部署地图服务先抛一个可能有点反直觉的判断在各类在线地图API随手可调的今天仍然有大量项目必须走本地化地图服务这条路。我接触过的场景里做城市管网管理的、做园区安防调度的、做自然资源数据归档的几乎都绕不开自己搭一套地图服务。原因不复杂——数据不能出内网、底图要能自定义、图层权限要能精细控制这三点在线服务基本都给不了。ArcGIS Server 就是干这件事的老牌选手。它能把你在桌面端做好的地图文档发布成标准的地图服务供前端、移动端、其他系统去调用。听起来就一句话但真正从零走一遍你会发现坑集中在几个地方软件装完服务起不来、发布时报数据源路径错误、发布成功了但切片缓存死活生成不了、跨网段访问又被拦。这篇内容就是把这整条链路拆开讲清楚。适合谁看如果你手上有一份做好的地图工程文件需要把它变成别人能通过网络访问的服务而你之前没完整走过这个流程那这篇就是给你准备的。我会按真实操作的顺序推进每一步都告诉你为什么这么做以及我踩过的那些坑长什么样。需要提前说明的是下面涉及的所有路径、账号、项目名称都是示意性的你实际操作时替换成自己的环境即可。软件版本我以目前主流的 10.x 系列为参照不同小版本界面可能略有差异但核心逻辑一致。2. 动手之前必须想清楚的几件事2.1 服务类型选错了后面全白干很多人一上来就急着装软件结果发布完才发现选错了服务类型。ArcGIS Server 能发布的服务有好几种最常见的是地图服务Map Service和要素服务Feature Service还有影像服务、地理处理服务等。它们的区别直接决定了你前端能干什么。地图服务本质上是把渲染好的图片或者矢量切片发给客户端客户端拿到的是画好的图不能直接编辑数据。要素服务则把要素的几何和属性都暴露出去客户端可以做查询、编辑、同步。如果你只是要展示地图服务足够且性能更好如果你要做在线编辑、数据回传那必须走要素服务而要素服务又依赖地理数据库。我见过一个典型翻车案例某团队要做移动端巡检打点结果发布的是纯地图服务前端死活提交不了数据回头返工重发白白耗了两天。所以第一步不是装软件是拿张纸写清楚谁用、用来干什么、要不要编辑、并发量大概多少。这四个问题答完服务类型基本就定了。2.2 数据源路径这件事提前规划能省一半时间ArcGIS 对数据源路径的敏感程度是新手最容易低估的。你在桌面端做地图文档时引用的可能是本地某个盘符下的 shapefile也可能是文件地理数据库里的要素类。一旦发布到服务器服务器得能看见这些数据否则发布直接失败。这里有个核心概念叫注册数据存储Registered Data Store。它的作用是告诉服务器这个目录或这个数据库我桌面端和服务器端都能访问路径映射关系是这样的。注册好之后发布时数据不会被复制服务直接引用原数据更新数据后服务能立刻反映。如果不注册发布时服务器会把数据打包复制到自己的存储里这叫复制数据。小数据量还行数据一大发布慢得让人怀疑人生而且后续更新数据要重新发布。我的建议是只要数据会持续更新一律走注册数据存储。规划时把数据统一放在一个共享目录下桌面端和服务器端用相同的挂载路径比如都映射成同一个盘符或同一个网络路径。路径不一致是注册失败的头号原因这个后面还会细说。2.3 账号权限与端口装之前就要预留ArcGIS Server 安装时会让你创建一个站点管理员账号这个账号不是操作系统账号是 ArcGIS 自己的。但安装过程中它又需要一个操作系统层面的运行账号。这两个别搞混。运行账号需要有对安装目录、数据目录、注册的数据存储目录的读写权限。我遇到过服务启动后一直报错查了半天是运行账号对数据目录没有读权限。所以安装前先把运行账号建好把该给的权限一次性给足。端口方面默认是 6080HTTP和 6443HTTPS管理界面走 6080。如果这台机器上已经有别的服务占了这些端口安装时就要改。另外别忘了防火墙服务器本机能访问不代表别的机器能访问入站规则要放行对应端口。这些准备工作看着琐碎但每一条对应一个真实的坑。3. 安装与站点创建的实操细节3.1 安装包选择与依赖检查拿到安装包之后先别急着双击。确认几件事操作系统版本是否在支持列表里、是否装了对应版本的 .NET 运行时、磁盘空间够不够。ArcGIS Server 对磁盘的要求不只是安装目录它还会创建一个专门的配置存储Config Store和服务器目录Server Directory这两个地方会随着服务增多不断膨胀尤其是切片缓存几百 GB 很常见。安装过程本身比较线性一路下一步中间会让你指定安装目录和运行账号。这里有个细节安装目录不要放在系统盘也不要用带空格或中文的路径。我吃过亏路径里有中文某些工具调用时直接乱码报错。用纯英文、无空格的短路径最稳。安装完成后会自动弹出站点创建向导。这一步是分水岭创建站点意味着这台机器正式成为一个 GIS 服务器节点。向导里要设置站点管理员账号密码、配置存储路径、服务器目录路径。配置存储建议放在一个独立的、有备份的目录它是整个站点的大脑丢了就得重建。3.2 创建站点时那几个容易填错的字段站点创建向导里几个字段值得单独说。站点管理员账号建议单独建一个不要用系统管理员权限太大反而不好管理。密码要符合复杂度要求否则向导会卡住不让你过。配置存储路径和服务器目录路径最好分开放。配置存储数据量小但极其关键服务器目录数据量大但可重建。分开存放便于分别做备份策略。创建过程会持续几分钟期间它会启动一系列后台服务。如果卡在某个百分比很久先别强制关闭去 Windows 服务列表里看看 ArcGIS Server 相关服务是不是在启动中。有时候是杀毒软件在扫描新写入的文件导致变慢把安装目录和数据目录加入杀毒软件白名单能明显改善。创建成功后浏览器访问http://服务器IP:6080/arcgis/manager用刚设的账号登录能看到管理界面就说明站点起来了。这一步跑通后面才有得谈。3.3 服务起不来时的排查顺序站点创建完但服务起不来是高频问题。我的排查顺序是这样的先看 Windows 服务里 ArcGIS Server 的状态是不是正在运行。如果是停止状态手动启动看报什么错。看日志。日志在服务器目录的logs文件夹下或者管理界面里也能看。日志里的错误信息通常很直白比如权限拒绝、端口占用、数据库连不上。检查运行账号权限。前面说过数据目录、配置存储、服务器目录都要有读写权限。检查端口占用。用netstat -ano | findstr 6080看端口是不是被别的进程占了。检查防火墙。本机能访问管理界面但别的机器不行八成是防火墙。这个顺序是从内到外先确认服务本身活着再确认它能被外部访问。按这个顺序走基本不会绕弯路。4. 把地图文档变成服务的完整链路4.1 桌面端准备地图文档的规范化发布服务的前提是有一份地图文档。这份文档在桌面端做的时候就要为发布做准备。几个规范动作图层命名用英文别用中文和特殊字符。服务发布后图层名会变成服务里的子图层标识中文在某些客户端调用时会出问题。数据源统一。所有图层的数据尽量放在同一个地理数据库或同一个目录下便于统一注册。符号系统检查。有些字体、符号在服务器端可能不存在发布后显示异常。用系统自带字体最保险。标注和比例尺范围。如果设置了标注确认标注表达式不依赖本地特有的字体或文件。做完这些保存地图文档。接下来在桌面端就可以直接发起发布或者先保存成服务定义文件.sd再上传。前者适合桌面端和服务器端网络互通的情况后者适合离线或跨网段的情况。4.2 注册数据存储路径映射的核心逻辑这是整个流程里最关键的一步也是最容易出错的一步。注册数据存储的本质是建立桌面端看到的路径和服务器端看到的路径之间的映射。举个例子桌面端数据放在D:\gisdata服务器端这台机器上同一个物理目录可能挂载成了E:\gisdata或者通过网络共享访问成了\\fileserver\gisdata。如果你直接发布服务器按桌面端的路径去找找不到就失败。注册数据存储就是告诉服务器桌面端的D:\gisdata对应我这里的E:\gisdata。操作路径在管理界面里站点 - 数据存储 - 注册文件夹。填两个路径一个是发布者路径桌面端看到的一个是服务器路径服务器端看到的。填完保存服务器会验证这个路径能不能访问验证通过才算注册成功。注意如果服务器端路径填的是网络共享路径运行账号必须有访问该共享的权限而且要用 UNC 路径\\主机名\共享名而不是映射盘符。映射盘符是用户会话级别的服务运行时可能看不到。注册成功后发布时勾选使用注册数据存储数据就不会被复制服务直接引用原数据。这一步做对后续数据更新只需要在桌面端改完保存服务刷新一下就能看到新内容效率天差地别。4.3 发布过程中的参数设置与取舍发布时有一堆参数要设我挑几个影响大的说。功能Capabilities地图服务默认开启 Mapping如果你需要查询要勾上 Query需要数据导出勾上 Data。功能开得越多服务占用的资源越多按需开就行。池化Pooling这是性能相关的关键设置。池化模式下服务实例被多个请求共享适合大量短请求非池化模式下每个请求独占一个实例适合长时间运行的任务。展示类地图服务用池化地理处理类用非池化。实例数最小实例数和最大实例数。最小实例数是服务启动后就常驻的实例设太小首次访问会慢最大实例数是并发高峰时能扩到的上限设太大吃内存。一般展示类服务最小 1 最大 2 到 4 就够具体看并发量。缓存Caching如果要做切片缓存发布时或发布后都可以配置。切片缓存能极大提升展示性能但生成过程耗时且占空间。是否做缓存取决于你的使用场景底图类、变化不频繁的图层适合做缓存频繁更新的业务图层不适合。这些参数没有绝对最优值都是根据你的数据量、并发量、硬件配置来权衡的。我的经验是先用保守配置跑起来观察一段时间资源占用和响应时间再针对性调整。4.4 切片缓存生成时间与空间的博弈切片缓存是地图服务性能优化的重头戏。原理是把地图按不同缩放级别预先渲染成一张张小图片客户端请求时直接返回对应图片不用实时渲染。代价是生成过程慢、占用磁盘大。生成缓存时要选缩放级别。级别越多能支持的缩放范围越广但生成时间和磁盘占用呈指数增长。每增加一个级别切片数量大约翻四倍。所以别贪多按实际需要的最深级别来定。比如只做城市级展示到 15 级左右通常够用要做街道级细节可能要到 17、18 级。切片方案可以选择 ArcGIS Online 的默认方案也可以自定义。默认方案兼容性好自定义方案适合有特殊坐标系要求的场景。选错切片方案会导致前端加载时坐标对不上这个坑很隐蔽发布时看着一切正常前端一调就发现图层位置偏了。生成缓存是个耗时任务可以后台跑。跑的时候盯着日志如果报错中断多半是磁盘满了或者某个级别数据量太大超时。可以分级别生成先出低级别快速验证再补高级别。5. 发布之后验证、调用与常见故障5.1 服务到底通没通三步验证法服务发布完别急着交付先自己验证三件事。第一步管理界面里看服务状态。服务列表里能看到刚发布的服务状态是已启动点进去能看到各个功能的开关情况。第二步用服务目录Services Directory预览。访问http://服务器IP:6080/arcgis/rest/services找到你的服务点进去能看到服务的元信息、支持的操、以及一个内置的预览界面。在预览界面里能看到地图正常显示说明服务本身没问题。第三步从另一台机器访问。这一步是验证网络和防火墙。如果本机能预览、别的机器打不开问题一定在网络层面回去查防火墙入站规则和端口。这三步走完服务基本就算通了。前端调用时用的就是这个 REST 端点把端点地址给前端开发就行。5.2 前端调用时坐标对不上怎么办坐标对不上是高频问题表现是图层位置偏移、缩放级别错乱、或者干脆显示不出来。根因通常是坐标系不一致。地图文档有它自己的坐标系服务发布后会继承这个坐标系。前端底图如果是另一种坐标系两者叠加就会错位。解决办法有两个要么统一坐标系把地图文档和底图都设成同一种要么在服务层面做投影转换但这会增加性能开销。还有一个隐蔽原因是切片方案。如果服务做了缓存缓存用的切片方案和前端期望的不一致也会错位。发布缓存前一定要确认切片方案的坐标系和前端底图匹配。排查这类问题先看服务的 REST 页面里显示的坐标系是什么再对比前端底图的坐标系不一致就统一。这个信息在服务元信息里写得很清楚别靠猜。5.3 服务突然变慢或挂掉的排查思路服务跑着跑着变慢甚至挂掉原因通常集中在资源层面。我的排查清单现象可能原因排查动作响应越来越慢内存不足实例频繁回收看服务器内存占用调小最大实例数间歇性无响应数据库连接池耗尽检查数据源连接数配置服务直接停止运行账号密码过期或权限变更检查账号状态和目录权限缓存加载慢磁盘 IO 瓶颈看磁盘队列长度考虑换 SSD并发一高就崩实例数配置不合理调整池化设置和实例上下限这张表是我这些年攒下来的经验基本覆盖了八成以上的性能问题。核心思路是先分清是服务本身的问题还是资源的问题再往具体方向查。日志永远是最好的朋友别跳过日志直接猜。6. 几个我踩过、你大概率也会踩的坑6.1 路径里有中文或空格引发的连锁反应这个坑我踩过不止一次。安装路径、数据路径、配置存储路径只要有一个带中文或空格就可能在某一步莫名其妙失败。表现五花八门安装时报错、发布时找不到数据、服务启动后读不到配置。根因是某些底层组件对路径的处理不够健壮遇到非 ASCII 字符或空格就解析异常。解决办法简单粗暴所有路径一律用纯英文、无空格、尽量短。比如D:\ArcGIS\Server、D:\GISData这种。规划环境时就把这条当铁律能省掉后面无数排查时间。6.2 注册数据存储时路径映射写反了注册数据存储要填两个路径一个是发布者路径一个是服务器路径。这两个填反了注册时可能也能通过验证因为两个路径在各自机器上都存在但发布时服务器按错误的映射去找数据直接失败。判断哪个是哪个的方法发布者路径是你桌面端打开地图文档时数据所在的路径服务器路径是服务器这台机器访问同一份数据用的路径。填的时候默念一遍桌面端看到的是这个服务器看到的是那个能有效避免填反。如果两个路径恰好一样比如数据就在服务器本机桌面端也是连的这台机器那填成一样也没问题。但跨机器的情况一定要区分清楚。6.3 防火墙放行了端口但服务还是访问不了防火墙放行了 6080本机能访问别的机器还是不行。这种情况我遇到过几次原因各不相同放行的是错误的网络配置文件域/专用/公用实际流量走的是另一个配置文件。服务器上有多个网卡服务绑定到了其中一个网卡的 IP另一个网段访问不到。中间还有一层网络设备做了限制不只是服务器本机防火墙的事。排查时先用telnet 服务器IP 6080从客户端测端口通不通。不通就是网络层的事逐层往上查。通但访问不了可能是服务绑定问题去管理界面看服务的绑定 IP 配置。6.4 切片缓存生成到一半失败缓存生成到一半失败最心疼因为前面的时间白花了。常见原因磁盘空间不足、某个级别数据量过大超时、数据源在生成过程中被修改。预防措施生成前确认磁盘剩余空间是预估需求的两倍以上分级别生成别一次性全级别跑生成期间不要修改数据源。如果失败了看日志定位是哪个级别、哪个范围出的问题可以只重新生成失败的部分不用从头来。7. 关于运维和后续扩展的一些个人体会服务发布出去只是开始后面还有运维的活。我自己的习惯是给每个服务建一个简单的台账记录服务名、数据源、坐标系、切片方案、负责人、发布时间。看着土但出问题时能快速定位交接时也省事。监控方面至少盯着几个指标服务响应时间、实例数变化、服务器内存和磁盘占用。这些在管理界面里都能看到定期扫一眼能在问题变大之前发现苗头。扩展方面单机扛不住的时候可以考虑多节点部署把服务分布到多台机器上前面加负载均衡。但多节点会带来配置存储共享、数据存储共享的新问题复杂度上一个台阶。我的建议是单机能撑就先单机把缓存和参数优化做到位实在撑不住再考虑集群。最后说一个心态上的体会地图服务这东西装和发布本身不难难的是环境差异带来的各种意外。同样的步骤在这台机器上顺顺利利换台机器就卡住。所以别指望一次成功把每一步的验证做扎实出问题按服务本身 - 权限 - 网络 - 资源的顺序排查大部分问题都能自己解决。真正解决不了的日志里通常也写了答案只是需要耐心读。