1. 为什么现在还要自己动手发布地图服务很多人第一次接触地理信息开发脑子里冒出来的第一个念头就是现在底图调用这么方便随便找个在线的瓦片服务拼一拼不就行了为什么还要折腾自己发布地图服务这个问题我在带新人的时候被问过不下二十次。答案其实很朴素——当你需要展示的数据是内部测绘成果、是某个园区自己采集的管线数据、是带有敏感属性的专题图层时公共底图根本满足不了你。你需要的是一个完全由自己掌控、能定义样式、能控制访问权限、能叠加私有数据的服务端点。ArcGIS Server 这套东西在地理信息行业里算是老资历了它的地图服务发布流程成熟、稳定支持的功能也足够全动态图层、切片缓存、要素查询、空间分析基本你能想到的 GIS 服务形态它都能覆盖。但它的门槛也确实存在——安装配置环节多、授权机制绕、发布流程里藏着不少容易踩的坑。我见过太多人卡在“服务发布成功但打开一片空白”或者“切片跑到一半报错”这种问题上一卡就是大半天。这篇内容就是写给那些手里有 ArcGIS Server 环境、但还没完整走通过一遍发布流程的人。不管你是刚入行的 GIS 工程师还是被临时抓来顶包的后端开发只要跟着把整个链路走一遍就能理解每一步到底在干什么、为什么要这么干。我会把动态服务、切片服务两条主线都讲清楚顺带把那些文档里不会写的坑一个个标出来。整个流程从数据准备一直讲到服务验证中间涉及的关键参数我都会给出计算依据不让你对着界面瞎猜。2. 发布之前必须搞清楚的几件事2.1 地图服务的两种基本形态在动手之前你得先决定自己要发布的是动态地图服务还是切片地图服务。这两个东西看起来都是“把地图挂到网上”但底层机制完全不同选错了后面全是返工。动态地图服务Map Service动态模式的工作方式是客户端每次请求服务器实时去读数据源、按当前请求的范围和图层定义渲染出一张图片返回。它的好处是灵活——你改了数据、调了符号刷新一下就能看到效果不用重新发布。缺点是每次请求都要实时渲染并发一高服务器压力就上来了响应速度也会明显变慢。切片地图服务Map Service缓存模式则是提前把地图按不同缩放级别切成一张张小图片存起来客户端请求时直接返回对应的瓦片。它的响应速度极快因为服务器不需要实时渲染但代价是数据更新后必须重新切图而且切片文件会占用大量磁盘空间。一个中等复杂度的城市级底图切到十几级占用几十上百 GB 是很正常的事。我的一般建议是如果数据更新频繁、主要用于内部查询分析选动态如果数据相对静态、面向大量用户浏览选切片。当然你也可以先发动态等数据稳定了再基于同一个服务生成缓存这样两不耽误。2.2 数据源的准备与检查ArcGIS Server 支持的数据源类型不少但最常用、最稳妥的还是文件地理数据库File Geodatabase和空间数据库如 PostgreSQL 配合空间扩展。对于新手我强烈建议先用文件地理数据库练手因为它不依赖额外的数据库服务拷贝迁移也方便。数据准备阶段有几个必须检查的点这些点任何一个出问题都会导致后面发布失败坐标系是否明确数据必须带有明确的坐标系定义。如果数据是“未知坐标系”发布时服务器不知道该按什么投影渲染轻则位置偏移重则直接报错。用 ArcGIS Pro 或 ArcMap 打开数据属性确认坐标系那一栏不是“Unknown”。字段名是否规范中文段名、特殊字符段名在某些服务类型下会出问题。建议发布前把字段名统一改成英文加下划线比如把“道路名称”改成“road_name”。数据是否有几何错误自相交、空几何、坐标超出范围这些问题在桌面端可能看不出来但发布成服务后查询时会报错。用“检查几何”工具跑一遍把错误修掉。数据量是否合理单个要素类要素数量超过百万级别时动态服务的首次加载会非常慢。这种情况建议先做概化或者建立空间索引。提示文件地理数据库的路径里不要出现中文和空格。我遇到过好几次因为路径带中文导致服务发布后数据源找不到的情况排查起来很费时间。2.3 服务账户与权限的坑ArcGIS Server 在运行服务时是使用一个特定的系统账户去访问数据源的。这个账户如果对数据所在目录没有读取权限服务就会启动失败或者显示为空。默认情况下安装 ArcGIS Server 时会创建一个名为arcgis的本地账户你需要确保这个账户对数据文件夹有读取权限。具体操作是右键数据所在文件夹 → 属性 → 安全 → 编辑 → 添加 → 输入arcgis→ 检查名称 → 确定然后给它“读取和执行”“列出文件夹内容”“读取”这三项权限。这一步看起来简单但很多人会漏掉尤其是数据放在网络共享路径或者外接硬盘上的时候。另外如果你用的是企业级空间数据库还需要在数据库端为arcgis账户配置相应的登录名和查询权限。这部分涉及数据库管理建议让 DBA 配合处理不要自己硬扛。3. 从零走通动态地图服务发布3.1 在桌面端配置地图文档发布服务的起点是一个配置好的地图文档。虽然现在 ArcGIS Pro 是主流但 ArcGIS Server 对.mxdArcMap 文档和.aprxPro 工程都支持。我这里以.mxd为例因为它的发布流程更经典遇到的问题也更有代表性。打开 ArcMap把准备好的数据拖进来然后做以下几件事设置数据框坐标系右键数据框 → 属性 → 坐标系选择一个合适的投影。如果是大范围区域建议用等积投影或者等距投影避免形状变形太严重。调整符号系统把每个图层的符号、颜色、标注都调好。注意服务发布后客户端看到的样式就是你现在设置的样式所以这一步要仔细。设置可见比例范围对于细节丰富的图层设置最小可见比例避免缩得很小时显示一团乱麻。右键图层 → 属性 → 常规 → 设置“最小比例尺”。保存文档保存为.mxd文件路径同样不要带中文和空格。这里有个经验在桌面端把地图缩放到不同级别都看一眼确认没有明显的显示问题。我见过有人在桌面端只看了全图范围结果发布后用户放大到某个级别发现标注重叠得一塌糊涂又得重新调。3.2 连接到服务器并分析文档打开 ArcCatalog 或者 ArcMap 里的 Catalog 窗口找到“GIS 服务器”节点双击“添加 ArcGIS Server”输入服务器地址。地址格式通常是https://服务器名:6443/arcgis或者http://服务器名:6080/arcgis。输入管理员用户名和密码后连接。连接成功后右键你的地图文档 → 共享为服务。这时候会弹出一个“服务编辑器”窗口。在发布之前强烈建议先点一下“分析”按钮。分析器会检查文档里有没有会导致发布失败的问题比如数据源路径无效、图层使用了不支持的类型、标注表达式有语法错误等等。分析结果会分等级错误必须解决警告可以酌情忽略消息只是提示。我一般会把所有错误和大部分警告都处理掉再发布因为很多警告在实际运行时会变成问题。比如“数据源使用绝对路径”这个警告如果你不处理服务发布后一旦数据移动位置服务就挂了。解决办法是在文档里设置相对路径或者把数据放到服务器能访问的统一位置。3.3 配置服务参数的关键项在服务编辑器里有几个参数需要特别关注能力选择默认勾选“地图”和“要素访问”。如果你需要客户端能查询要素属性就保留“要素访问”如果只是展示图片可以取消勾选以减少资源占用。还有“WMS”“WFS”这些 OGC 标准能力按需勾选。池化模式分为“池化”和“非池化”。池化模式下服务器会维护一组共享的进程实例来处理请求适合无状态的服务资源利用率高。非池化模式下每个请求独占一个实例适合需要保持状态的服务。绝大多数地图服务用池化就行。实例数量最小实例数和最大实例数。最小实例数是服务启动后就常驻的实例数量最大实例数是并发高时可以临时增加的实例上限。这两个值需要根据服务器内存和预期并发量来定。一个粗略的估算方法是每个实例大约占用 100-200 MB 内存用服务器可用内存除以这个数再留出 30% 的余量给系统和其他服务。超时设置包括“使用超时”和“等待超时”。使用超时是指一个实例处理一个请求的最长时间超过就强制回收。等待超时是指请求在队列里等待可用实例的最长时间。对于复杂的地图渲染使用超时建议设大一点比如 60 秒等待超时设 30 秒左右比较合理。3.4 发布后的验证与常见问题点击“发布”后服务会上传到服务器并启动。发布完成后在 Catalog 里展开服务器节点找到刚发布的服务双击打开 REST 服务目录页面。这个页面是验证服务是否正常的最直接方式。在 REST 页面里点击“ArcGIS JavaScript”或者“查看地图”链接能看到地图正常渲染出来说明基本没问题。然后测试几个关键功能缩放和拖动是否流畅点击要素是否能弹出属性信息使用“查询”功能是否能按条件筛选要素如果打开是一片空白按以下顺序排查现象可能原因排查方法地图全白数据源路径无效检查服务日志看是否有“无法打开数据源”错误地图全白服务账户无权限确认 arcgis 账户对数据文件夹有读取权限部分图层不显示图层可见比例设置不当检查该图层的比例范围设置标注不显示标注表达式错误在桌面端重新验证标注表达式服务启动失败端口被占用或服务未启动检查服务器上的 ArcGIS Server 服务状态服务日志在服务器安装目录\arcgis\server\logs下按日期分文件夹存放。日志文件是排查问题的第一手资料遇到报错先去看日志比瞎猜快得多。4. 切片地图服务的完整实操4.1 切片方案的设计与选择切片服务的核心是切片方案Tiling Scheme它定义了瓦片的坐标系、缩放级别、瓦片尺寸和存储格式。切片方案选得好后续使用顺畅选得不好要么瓦片数量爆炸要么精度不够。ArcGIS Server 内置了几种常见的切片方案比如“ArcGIS Online/Bing Maps/Google Maps”方案用的是 Web 墨卡托投影缩放级别从 0 到 23。如果你的地图是面向互联网用户、需要和公共底图叠加直接用这个方案最省事。但如果你的数据是某个特定投影下的比如高斯-克吕格投影强行用 Web 墨卡托会导致位置偏移和形状变形。这时候就需要自定义切片方案。自定义时主要设置这几个参数坐标系选择和数据一致的投影坐标系缩放级别从哪个级别切到哪个级别分辨率每个级别对应的地面分辨率瓦片尺寸默认 256x256 像素也可以设 512x512瓦片格式PNG 支持透明JPEG 体积小但不支持透明缩放级别的分辨率计算有个公式第 n 级的分辨率 初始分辨率 / 2^n。初始分辨率通常取坐标系范围宽度除以瓦片像素宽度。比如坐标系范围宽度是 1000000 米瓦片宽度 256 像素那初始分辨率就是 1000000 / 256 ≈ 3906 米/像素。然后每一级除以 2直到达到你需要的精度。4.2 生成缓存的参数配置切片方案定好后就可以在服务编辑器里配置缓存参数了。在“缓存”选项卡里勾选“使用缓存绘制地图服务”然后选择“在发布服务时自动生成缓存”或者“稍后手动生成缓存”。自动生成的好处是发布完就不用管了坏处是如果参数设错要等很久才发现。我一般建议先手动生成确认参数没问题后再批量切。缓存生成有几个关键参数切片格式PNG 适合有透明背景的图层比如只显示道路网不显示底图的情况JPEG 适合有丰富色彩和渐变的底图体积比 PNG 小很多。如果地图里有透明区域用 JPEG 会把透明部分变成黑色或白色这时候必须用 PNG。压缩质量JPEG 格式才有这个参数取值 0-100。质量越高体积越大。一般设 75-85 之间比较平衡肉眼几乎看不出差别但体积能小不少。抗锯齿开启后瓦片边缘更平滑但生成时间会变长。对于线条密集的地图建议开启。缓存目录默认在服务器安装目录下的arcgiscache文件夹里。如果磁盘空间紧张可以改到其他盘。注意缓存目录所在磁盘的剩余空间要足够一个省级范围的切片缓存动辄几十 GB。4.3 切片任务的监控与优化切片任务启动后可以在服务器管理器中查看进度。管理器的地址通常是https://服务器名:6443/arcgis/manager登录后找到对应的服务在“缓存”选项卡里能看到已完成的瓦片数量和预计剩余时间。切片是个耗时操作一个中等复杂度的地图切到 15 级在普通配置的服务器上跑几个小时很正常。如果想加快速度可以调整“切片实例数”。这个参数决定了同时有多少个进程在切瓦片设大一点能充分利用多核 CPU但设太大反而会因为磁盘 IO 瓶颈导致整体变慢。一般设成 CPU 核心数的 1.5 到 2 倍比较合适。还有一个容易忽略的点切片过程中如果服务器重启或者服务被停止切片任务会中断。重新启动后需要手动“继续”切片而不是从头开始。在管理器里找到缓存选项卡点击“继续”按钮即可。已经切好的瓦片不会重复生成所以不用担心浪费时间。注意切片任务运行期间不要修改地图文档或者服务的数据源。一旦数据变了已经切好的瓦片和新的数据对不上整个缓存就废了只能删掉重切。5. 服务发布后的管理与调优5.1 服务目录的权限控制服务发布出去之后默认是公开访问的任何人拿到地址都能看。如果数据涉及内部信息必须配置权限。在服务器管理器的“安全性”选项卡里可以设置服务的访问权限公开任何人无需登录即可访问仅限组织内需要登录服务器账户才能访问私有只有服务所有者和管理员能访问对于内部使用的服务建议至少设为“仅限组织内”。如果需要对不同用户开放不同图层可以在服务里配置“要素访问”权限结合数据库的用户表来做行级权限控制。这部分涉及安全模型设计展开讲能写一整篇这里先不深入。5.2 性能监控与日志分析服务跑起来之后需要定期看两个东西服务日志和服务器资源占用。服务日志在管理器里可以直接查看也可以去日志文件夹翻文件。重点关注这几类信息警告比如“实例数达到上限”“请求等待超时”说明并发压力大了需要调整实例数错误比如“数据源连接失败”“渲染错误”说明有具体问题需要修复统计每个服务的请求次数、平均响应时间用来判断哪些服务是热点服务器资源占用主要看 CPU、内存和磁盘 IO。如果 CPU 长期跑满说明实例数太多或者地图渲染太复杂如果内存吃紧要减少最大实例数如果磁盘 IO 高可能是切片任务在跑或者日志写入太频繁。5.3 常见故障的应急处理服务运行过程中难免出问题我整理了几个高频故障和应急处理方式服务无响应先看服务器上的 ArcGIS Server 服务是否还在运行。如果服务停了启动它如果服务在运行但无响应尝试重启服务。重启后如果还是不行检查日志里有没有“内存不足”或者“实例崩溃”的记录。地图显示错乱通常是数据源被修改或者坐标系变了。检查数据文件的修改时间确认最近有没有人动过。如果是数据更新了动态服务刷新即可切片服务需要重新切。切片瓦片缺失某些级别的瓦片没切完或者切的过程中出错了。在管理器里找到缓存选项卡点击“重新生成缺失的瓦片”。如果缺失很多建议删掉缓存重新切。服务访问变慢先看是不是并发量上来了如果是增加最大实例数。如果不是检查数据源是不是变大了或者服务器磁盘是不是快满了。磁盘剩余空间低于 10% 时服务性能会明显下降。6. 几个让我印象深刻的踩坑记录第一个坑是关于中文路径的。早期我习惯把数据放在“D:\项目数据\城市底图”这样的路径下桌面端一切正常发布后服务就是打不开。查了半天日志才发现是服务账户对中文路径的读取有问题。后来把所有数据路径改成纯英文加下划线再也没出过这个问题。这个坑现在应该好一些了但为了保险还是建议用英文路径。第二个坑是关于切片级别的。有一次给一个园区做切片想着范围不大直接切到 18 级。结果切到 16 级的时候磁盘就满了因为高缩放级别下瓦片数量是指数增长的。后来算了一下从 16 级到 17 级瓦片数量翻四倍再到 18 级又翻四倍。所以切之前一定要估算一下瓦片总数和磁盘占用。估算方法是瓦片总数 ≈ (地图宽度 / 瓦片地面宽度) × (地图高度 / 瓦片地面高度)每一级都算一遍再累加。第三个坑是关于服务账户密码过期的。有些环境里arcgis账户设置了密码有效期到期后服务突然全部挂掉日志里报“登录失败”。这个问题的隐蔽性在于它不会在发布时暴露而是运行一段时间后突然出现。解决办法是把服务账户的密码设为永不过期或者在密码到期前主动更新并同步到服务器配置里。第四个坑是关于标注冲突的。桌面端看标注好好的发布后有些标注就消失了。这是因为服务端的标注引擎和桌面端有细微差别尤其是在标注密度高的时候服务端会更激进地隐藏重叠标注。解决办法是调整标注的“最小要素间距”或者改用“标注优先级”来控制哪些标注优先显示。这些坑说到底都是经验问题文档里不会写只有真正踩过才知道。但好消息是一旦踩过一遍后面再遇到类似情况就能快速定位了。7. 关于自动化发布的思路如果你需要频繁发布服务手动操作就太慢了。ArcGIS Server 提供了 REST 接口和 Python 库arcgis包可以把发布流程脚本化。基本思路是用 Python 连接到服务器读取地图文档调用publish方法发布服务然后配置缓存参数并启动切片任务。这样做的好处是整个流程可以纳入版本控制每次数据更新后自动重新发布和切片减少人工操作带来的不确定性。不过自动化发布对地图文档的规范性要求更高因为脚本不会像人一样去“看一眼”有没有问题。所以建议先把手动流程走顺确认每个环节都稳定了再考虑自动化。我在实际项目里用自动化发布处理过每周更新一次的专题图服务整个流程从数据准备到切片完成全自动节省了大量重复劳动。但前期调试脚本花的时间也不少主要是处理各种边界情况比如数据源路径变化、服务已存在时的覆盖逻辑、切片失败后的重试机制等等。所以自动化是个好东西但不要指望一开始就能跑通留出足够的调试时间。
1. 为什么现在还要自己动手发布地图服务很多人第一次接触地理信息开发脑子里冒出来的第一个念头就是现在底图调用这么方便随便找个在线的瓦片服务拼一拼不就行了为什么还要折腾自己发布地图服务这个问题我在带新人的时候被问过不下二十次。答案其实很朴素——当你需要展示的数据是内部测绘成果、是某个园区自己采集的管线数据、是带有敏感属性的专题图层时公共底图根本满足不了你。你需要的是一个完全由自己掌控、能定义样式、能控制访问权限、能叠加私有数据的服务端点。ArcGIS Server 这套东西在地理信息行业里算是老资历了它的地图服务发布流程成熟、稳定支持的功能也足够全动态图层、切片缓存、要素查询、空间分析基本你能想到的 GIS 服务形态它都能覆盖。但它的门槛也确实存在——安装配置环节多、授权机制绕、发布流程里藏着不少容易踩的坑。我见过太多人卡在“服务发布成功但打开一片空白”或者“切片跑到一半报错”这种问题上一卡就是大半天。这篇内容就是写给那些手里有 ArcGIS Server 环境、但还没完整走通过一遍发布流程的人。不管你是刚入行的 GIS 工程师还是被临时抓来顶包的后端开发只要跟着把整个链路走一遍就能理解每一步到底在干什么、为什么要这么干。我会把动态服务、切片服务两条主线都讲清楚顺带把那些文档里不会写的坑一个个标出来。整个流程从数据准备一直讲到服务验证中间涉及的关键参数我都会给出计算依据不让你对着界面瞎猜。2. 发布之前必须搞清楚的几件事2.1 地图服务的两种基本形态在动手之前你得先决定自己要发布的是动态地图服务还是切片地图服务。这两个东西看起来都是“把地图挂到网上”但底层机制完全不同选错了后面全是返工。动态地图服务Map Service动态模式的工作方式是客户端每次请求服务器实时去读数据源、按当前请求的范围和图层定义渲染出一张图片返回。它的好处是灵活——你改了数据、调了符号刷新一下就能看到效果不用重新发布。缺点是每次请求都要实时渲染并发一高服务器压力就上来了响应速度也会明显变慢。切片地图服务Map Service缓存模式则是提前把地图按不同缩放级别切成一张张小图片存起来客户端请求时直接返回对应的瓦片。它的响应速度极快因为服务器不需要实时渲染但代价是数据更新后必须重新切图而且切片文件会占用大量磁盘空间。一个中等复杂度的城市级底图切到十几级占用几十上百 GB 是很正常的事。我的一般建议是如果数据更新频繁、主要用于内部查询分析选动态如果数据相对静态、面向大量用户浏览选切片。当然你也可以先发动态等数据稳定了再基于同一个服务生成缓存这样两不耽误。2.2 数据源的准备与检查ArcGIS Server 支持的数据源类型不少但最常用、最稳妥的还是文件地理数据库File Geodatabase和空间数据库如 PostgreSQL 配合空间扩展。对于新手我强烈建议先用文件地理数据库练手因为它不依赖额外的数据库服务拷贝迁移也方便。数据准备阶段有几个必须检查的点这些点任何一个出问题都会导致后面发布失败坐标系是否明确数据必须带有明确的坐标系定义。如果数据是“未知坐标系”发布时服务器不知道该按什么投影渲染轻则位置偏移重则直接报错。用 ArcGIS Pro 或 ArcMap 打开数据属性确认坐标系那一栏不是“Unknown”。字段名是否规范中文段名、特殊字符段名在某些服务类型下会出问题。建议发布前把字段名统一改成英文加下划线比如把“道路名称”改成“road_name”。数据是否有几何错误自相交、空几何、坐标超出范围这些问题在桌面端可能看不出来但发布成服务后查询时会报错。用“检查几何”工具跑一遍把错误修掉。数据量是否合理单个要素类要素数量超过百万级别时动态服务的首次加载会非常慢。这种情况建议先做概化或者建立空间索引。提示文件地理数据库的路径里不要出现中文和空格。我遇到过好几次因为路径带中文导致服务发布后数据源找不到的情况排查起来很费时间。2.3 服务账户与权限的坑ArcGIS Server 在运行服务时是使用一个特定的系统账户去访问数据源的。这个账户如果对数据所在目录没有读取权限服务就会启动失败或者显示为空。默认情况下安装 ArcGIS Server 时会创建一个名为arcgis的本地账户你需要确保这个账户对数据文件夹有读取权限。具体操作是右键数据所在文件夹 → 属性 → 安全 → 编辑 → 添加 → 输入arcgis→ 检查名称 → 确定然后给它“读取和执行”“列出文件夹内容”“读取”这三项权限。这一步看起来简单但很多人会漏掉尤其是数据放在网络共享路径或者外接硬盘上的时候。另外如果你用的是企业级空间数据库还需要在数据库端为arcgis账户配置相应的登录名和查询权限。这部分涉及数据库管理建议让 DBA 配合处理不要自己硬扛。3. 从零走通动态地图服务发布3.1 在桌面端配置地图文档发布服务的起点是一个配置好的地图文档。虽然现在 ArcGIS Pro 是主流但 ArcGIS Server 对.mxdArcMap 文档和.aprxPro 工程都支持。我这里以.mxd为例因为它的发布流程更经典遇到的问题也更有代表性。打开 ArcMap把准备好的数据拖进来然后做以下几件事设置数据框坐标系右键数据框 → 属性 → 坐标系选择一个合适的投影。如果是大范围区域建议用等积投影或者等距投影避免形状变形太严重。调整符号系统把每个图层的符号、颜色、标注都调好。注意服务发布后客户端看到的样式就是你现在设置的样式所以这一步要仔细。设置可见比例范围对于细节丰富的图层设置最小可见比例避免缩得很小时显示一团乱麻。右键图层 → 属性 → 常规 → 设置“最小比例尺”。保存文档保存为.mxd文件路径同样不要带中文和空格。这里有个经验在桌面端把地图缩放到不同级别都看一眼确认没有明显的显示问题。我见过有人在桌面端只看了全图范围结果发布后用户放大到某个级别发现标注重叠得一塌糊涂又得重新调。3.2 连接到服务器并分析文档打开 ArcCatalog 或者 ArcMap 里的 Catalog 窗口找到“GIS 服务器”节点双击“添加 ArcGIS Server”输入服务器地址。地址格式通常是https://服务器名:6443/arcgis或者http://服务器名:6080/arcgis。输入管理员用户名和密码后连接。连接成功后右键你的地图文档 → 共享为服务。这时候会弹出一个“服务编辑器”窗口。在发布之前强烈建议先点一下“分析”按钮。分析器会检查文档里有没有会导致发布失败的问题比如数据源路径无效、图层使用了不支持的类型、标注表达式有语法错误等等。分析结果会分等级错误必须解决警告可以酌情忽略消息只是提示。我一般会把所有错误和大部分警告都处理掉再发布因为很多警告在实际运行时会变成问题。比如“数据源使用绝对路径”这个警告如果你不处理服务发布后一旦数据移动位置服务就挂了。解决办法是在文档里设置相对路径或者把数据放到服务器能访问的统一位置。3.3 配置服务参数的关键项在服务编辑器里有几个参数需要特别关注能力选择默认勾选“地图”和“要素访问”。如果你需要客户端能查询要素属性就保留“要素访问”如果只是展示图片可以取消勾选以减少资源占用。还有“WMS”“WFS”这些 OGC 标准能力按需勾选。池化模式分为“池化”和“非池化”。池化模式下服务器会维护一组共享的进程实例来处理请求适合无状态的服务资源利用率高。非池化模式下每个请求独占一个实例适合需要保持状态的服务。绝大多数地图服务用池化就行。实例数量最小实例数和最大实例数。最小实例数是服务启动后就常驻的实例数量最大实例数是并发高时可以临时增加的实例上限。这两个值需要根据服务器内存和预期并发量来定。一个粗略的估算方法是每个实例大约占用 100-200 MB 内存用服务器可用内存除以这个数再留出 30% 的余量给系统和其他服务。超时设置包括“使用超时”和“等待超时”。使用超时是指一个实例处理一个请求的最长时间超过就强制回收。等待超时是指请求在队列里等待可用实例的最长时间。对于复杂的地图渲染使用超时建议设大一点比如 60 秒等待超时设 30 秒左右比较合理。3.4 发布后的验证与常见问题点击“发布”后服务会上传到服务器并启动。发布完成后在 Catalog 里展开服务器节点找到刚发布的服务双击打开 REST 服务目录页面。这个页面是验证服务是否正常的最直接方式。在 REST 页面里点击“ArcGIS JavaScript”或者“查看地图”链接能看到地图正常渲染出来说明基本没问题。然后测试几个关键功能缩放和拖动是否流畅点击要素是否能弹出属性信息使用“查询”功能是否能按条件筛选要素如果打开是一片空白按以下顺序排查现象可能原因排查方法地图全白数据源路径无效检查服务日志看是否有“无法打开数据源”错误地图全白服务账户无权限确认 arcgis 账户对数据文件夹有读取权限部分图层不显示图层可见比例设置不当检查该图层的比例范围设置标注不显示标注表达式错误在桌面端重新验证标注表达式服务启动失败端口被占用或服务未启动检查服务器上的 ArcGIS Server 服务状态服务日志在服务器安装目录\arcgis\server\logs下按日期分文件夹存放。日志文件是排查问题的第一手资料遇到报错先去看日志比瞎猜快得多。4. 切片地图服务的完整实操4.1 切片方案的设计与选择切片服务的核心是切片方案Tiling Scheme它定义了瓦片的坐标系、缩放级别、瓦片尺寸和存储格式。切片方案选得好后续使用顺畅选得不好要么瓦片数量爆炸要么精度不够。ArcGIS Server 内置了几种常见的切片方案比如“ArcGIS Online/Bing Maps/Google Maps”方案用的是 Web 墨卡托投影缩放级别从 0 到 23。如果你的地图是面向互联网用户、需要和公共底图叠加直接用这个方案最省事。但如果你的数据是某个特定投影下的比如高斯-克吕格投影强行用 Web 墨卡托会导致位置偏移和形状变形。这时候就需要自定义切片方案。自定义时主要设置这几个参数坐标系选择和数据一致的投影坐标系缩放级别从哪个级别切到哪个级别分辨率每个级别对应的地面分辨率瓦片尺寸默认 256x256 像素也可以设 512x512瓦片格式PNG 支持透明JPEG 体积小但不支持透明缩放级别的分辨率计算有个公式第 n 级的分辨率 初始分辨率 / 2^n。初始分辨率通常取坐标系范围宽度除以瓦片像素宽度。比如坐标系范围宽度是 1000000 米瓦片宽度 256 像素那初始分辨率就是 1000000 / 256 ≈ 3906 米/像素。然后每一级除以 2直到达到你需要的精度。4.2 生成缓存的参数配置切片方案定好后就可以在服务编辑器里配置缓存参数了。在“缓存”选项卡里勾选“使用缓存绘制地图服务”然后选择“在发布服务时自动生成缓存”或者“稍后手动生成缓存”。自动生成的好处是发布完就不用管了坏处是如果参数设错要等很久才发现。我一般建议先手动生成确认参数没问题后再批量切。缓存生成有几个关键参数切片格式PNG 适合有透明背景的图层比如只显示道路网不显示底图的情况JPEG 适合有丰富色彩和渐变的底图体积比 PNG 小很多。如果地图里有透明区域用 JPEG 会把透明部分变成黑色或白色这时候必须用 PNG。压缩质量JPEG 格式才有这个参数取值 0-100。质量越高体积越大。一般设 75-85 之间比较平衡肉眼几乎看不出差别但体积能小不少。抗锯齿开启后瓦片边缘更平滑但生成时间会变长。对于线条密集的地图建议开启。缓存目录默认在服务器安装目录下的arcgiscache文件夹里。如果磁盘空间紧张可以改到其他盘。注意缓存目录所在磁盘的剩余空间要足够一个省级范围的切片缓存动辄几十 GB。4.3 切片任务的监控与优化切片任务启动后可以在服务器管理器中查看进度。管理器的地址通常是https://服务器名:6443/arcgis/manager登录后找到对应的服务在“缓存”选项卡里能看到已完成的瓦片数量和预计剩余时间。切片是个耗时操作一个中等复杂度的地图切到 15 级在普通配置的服务器上跑几个小时很正常。如果想加快速度可以调整“切片实例数”。这个参数决定了同时有多少个进程在切瓦片设大一点能充分利用多核 CPU但设太大反而会因为磁盘 IO 瓶颈导致整体变慢。一般设成 CPU 核心数的 1.5 到 2 倍比较合适。还有一个容易忽略的点切片过程中如果服务器重启或者服务被停止切片任务会中断。重新启动后需要手动“继续”切片而不是从头开始。在管理器里找到缓存选项卡点击“继续”按钮即可。已经切好的瓦片不会重复生成所以不用担心浪费时间。注意切片任务运行期间不要修改地图文档或者服务的数据源。一旦数据变了已经切好的瓦片和新的数据对不上整个缓存就废了只能删掉重切。5. 服务发布后的管理与调优5.1 服务目录的权限控制服务发布出去之后默认是公开访问的任何人拿到地址都能看。如果数据涉及内部信息必须配置权限。在服务器管理器的“安全性”选项卡里可以设置服务的访问权限公开任何人无需登录即可访问仅限组织内需要登录服务器账户才能访问私有只有服务所有者和管理员能访问对于内部使用的服务建议至少设为“仅限组织内”。如果需要对不同用户开放不同图层可以在服务里配置“要素访问”权限结合数据库的用户表来做行级权限控制。这部分涉及安全模型设计展开讲能写一整篇这里先不深入。5.2 性能监控与日志分析服务跑起来之后需要定期看两个东西服务日志和服务器资源占用。服务日志在管理器里可以直接查看也可以去日志文件夹翻文件。重点关注这几类信息警告比如“实例数达到上限”“请求等待超时”说明并发压力大了需要调整实例数错误比如“数据源连接失败”“渲染错误”说明有具体问题需要修复统计每个服务的请求次数、平均响应时间用来判断哪些服务是热点服务器资源占用主要看 CPU、内存和磁盘 IO。如果 CPU 长期跑满说明实例数太多或者地图渲染太复杂如果内存吃紧要减少最大实例数如果磁盘 IO 高可能是切片任务在跑或者日志写入太频繁。5.3 常见故障的应急处理服务运行过程中难免出问题我整理了几个高频故障和应急处理方式服务无响应先看服务器上的 ArcGIS Server 服务是否还在运行。如果服务停了启动它如果服务在运行但无响应尝试重启服务。重启后如果还是不行检查日志里有没有“内存不足”或者“实例崩溃”的记录。地图显示错乱通常是数据源被修改或者坐标系变了。检查数据文件的修改时间确认最近有没有人动过。如果是数据更新了动态服务刷新即可切片服务需要重新切。切片瓦片缺失某些级别的瓦片没切完或者切的过程中出错了。在管理器里找到缓存选项卡点击“重新生成缺失的瓦片”。如果缺失很多建议删掉缓存重新切。服务访问变慢先看是不是并发量上来了如果是增加最大实例数。如果不是检查数据源是不是变大了或者服务器磁盘是不是快满了。磁盘剩余空间低于 10% 时服务性能会明显下降。6. 几个让我印象深刻的踩坑记录第一个坑是关于中文路径的。早期我习惯把数据放在“D:\项目数据\城市底图”这样的路径下桌面端一切正常发布后服务就是打不开。查了半天日志才发现是服务账户对中文路径的读取有问题。后来把所有数据路径改成纯英文加下划线再也没出过这个问题。这个坑现在应该好一些了但为了保险还是建议用英文路径。第二个坑是关于切片级别的。有一次给一个园区做切片想着范围不大直接切到 18 级。结果切到 16 级的时候磁盘就满了因为高缩放级别下瓦片数量是指数增长的。后来算了一下从 16 级到 17 级瓦片数量翻四倍再到 18 级又翻四倍。所以切之前一定要估算一下瓦片总数和磁盘占用。估算方法是瓦片总数 ≈ (地图宽度 / 瓦片地面宽度) × (地图高度 / 瓦片地面高度)每一级都算一遍再累加。第三个坑是关于服务账户密码过期的。有些环境里arcgis账户设置了密码有效期到期后服务突然全部挂掉日志里报“登录失败”。这个问题的隐蔽性在于它不会在发布时暴露而是运行一段时间后突然出现。解决办法是把服务账户的密码设为永不过期或者在密码到期前主动更新并同步到服务器配置里。第四个坑是关于标注冲突的。桌面端看标注好好的发布后有些标注就消失了。这是因为服务端的标注引擎和桌面端有细微差别尤其是在标注密度高的时候服务端会更激进地隐藏重叠标注。解决办法是调整标注的“最小要素间距”或者改用“标注优先级”来控制哪些标注优先显示。这些坑说到底都是经验问题文档里不会写只有真正踩过才知道。但好消息是一旦踩过一遍后面再遇到类似情况就能快速定位了。7. 关于自动化发布的思路如果你需要频繁发布服务手动操作就太慢了。ArcGIS Server 提供了 REST 接口和 Python 库arcgis包可以把发布流程脚本化。基本思路是用 Python 连接到服务器读取地图文档调用publish方法发布服务然后配置缓存参数并启动切片任务。这样做的好处是整个流程可以纳入版本控制每次数据更新后自动重新发布和切片减少人工操作带来的不确定性。不过自动化发布对地图文档的规范性要求更高因为脚本不会像人一样去“看一眼”有没有问题。所以建议先把手动流程走顺确认每个环节都稳定了再考虑自动化。我在实际项目里用自动化发布处理过每周更新一次的专题图服务整个流程从数据准备到切片完成全自动节省了大量重复劳动。但前期调试脚本花的时间也不少主要是处理各种边界情况比如数据源路径变化、服务已存在时的覆盖逻辑、切片失败后的重试机制等等。所以自动化是个好东西但不要指望一开始就能跑通留出足够的调试时间。
