5.1 WebGIS架构与服务体系
5.1 WebGIS 架构与服务体系
本节摘要：地图印出来只送达一张办公桌，服务发出去能送达每一块屏幕。本节是第 5 章的地基：先把 WebGIS 三层架构立起来，认一遍服务家族的成员，再跟踪一次地图请求在层与层之间的完整流转。架构概念不清就急着发布，出问题时无从排查——这一节的投资在 5.2 的运维排障里会连本带利收回。
先把三层骨架立起来
WebGIS 不是把桌面软件搬到网页上，而是把 GIS 能力拆成三层重新组织。客户端跑在用户的浏览器或手机里，负责展示与交互；服务层跑在机房的服务器上，IGServer 就住在这一层，负责出图、查询、分析这些重活；数据层是地理数据库与文件仓库，存着矢量、栅格与影像。三层的分工逻辑很朴素：计算集中在服务端，展示分散到客户端，数据锁在底层。
分层的第一收益是并发。一台桌面软件一个人用，一套服务几百人同时刷图。第二收益是维护——数据更新只动数据层，符号调整只改地图文档，客户端不用重新安装任何东西。第三收益是复用，同一份服务既能被网页调用，也能被移动端、大屏调用，一次发布多端受益。
图：WebGIS 三层架构与一次地图请求的流转
图中虚线是回程。整个旅程里最值得记住的是第 2 步的分支：缓存命中，毫秒级返回；缓存未命中，现场渲染，几百毫秒起步。用户抱怨"图慢"，八成问题出在这个分支上——这也正是 5.2 要讲的缓存预生成的理论根据。
学习目标
阅读完本节，你应当能够：
- 画出三层架构图，说清每层的职责、部署位置与通信方向
- 区分地图服务、要素服务、瓦片服务、地理处理服务的用途差异
- 跟踪一次瓦片请求的完整流转，指出每一步可能的故障点
- 为给定业务场景（浏览、查询、编辑、分析）选择正确的服务类型
- 解释"客户端不直连数据库"这条纪律背后的安全与耦合逻辑
服务家族：四个成员各管什么
服务层不是一块铁板，是一个分工明确的家族。判断一个业务该用哪种服务，先问业务动作是什么——看图、取数据、改数据、跑分析，四个动作对应四类服务。
# 服务类型选型表（按业务动作选） 动作 服务类型 返回形态 典型场景 浏览底图 瓦片服务 预切好的小图片 底图加载 大屏展示 看专题图 地图服务 现场渲染的图片 专题图浏览 打印出图 查要素 要素服务 矢量数据 点选查询 属性表 改数据 要素服务加编辑 提交写回 外业修正 审批标注 跑分析 地理处理服务 分析结果 缓冲区 统计 最短路径 # 两条经验： # 1 底图用瓦片 专题用地图服务 混着用是常态 # 2 给公众的用瓦片与地图服务 能写的入口越少越安全
四类服务里最容易混淆的是地图服务与要素服务。前者返回的是"图片"，客户端拿到一张渲染好的图，看不到背后的坐标；后者返回的是"数据"，坐标、属性原样交到客户端，浏览器里可以高亮、闪烁、弹窗。要支持点击查询和前端样式重绘，必须用要素服务；只是安静地铺一层底图，瓦片或地图服务更省带宽。
OGC 标准服务（WMS、WFS、WCS）值得单独一提。它们是跨厂商的通用语言——别的平台发出的 WMS 请求，IGServer 也能应答。项目里遇到多方数据汇聚、甲方指定标准接口的场景，OGC 服务就是那把通用的钥匙。
跟踪一次请求：排障思维训练
架构图背下来不算懂，能拿着它排障才算懂。模拟一次"地图打不开"的故障排查过程，看三层架构怎么当检查清单用：
# 故障：浏览器里地图白屏 三层逐层排查 第一层 客户端 打开浏览器控制台 看报错 常见：脚本地址失效 跨域拦截 瓦片地址写错 特征：报错在页面加载阶段 一张瓦片都没请求 第二层 服务层 服务管理器里看服务状态 是否启动 直接访问服务地址试一下 能否返回信息页 常见：服务未启动 端口被占 服务名拼写错 特征：控制台里请求返回连接拒绝或404 第三层 数据层 服务在跑但出图报错 查日志 常见：数据被移走 数据库密码改了 地图文档路径失效 特征：服务能返回错误详情 日志里有数据源连接失败 # 排障口诀：从外向内 先网络后服务再数据 # 每一层都过一遍 十分钟内必能锁定故障层
这个排障框架在真实项目里的价值远超背概念。服务化系统的一个特点是故障被分层隔离——数据层坏了，静态瓦片还能撑一阵；服务层挂了，所有客户端同时白屏。能迅速判断"故障在哪一层"，就能迅速判断"找谁修、影响多大"。
💡 关键直觉：三层架构本质是把"计算在哪里发生"安排清楚。客户端负责轻量的展示计算，服务层承担重的渲染与分析计算，数据层专职存储。任何 GIS 系统设计的争论，最后多半能还原成"这段计算放在哪一层"的争论。
⚠️ 常见坑：小项目图省事，让网页直接连数据库读表。短期看快了两天，长期看死路一条——数据库密码暴露在前端代码里，SQL 注入门户大开；数据结构一变，所有页面跟着改。服务层这层"隔离带"省不得。
三种部署形态：架构落地的物理选择
三层架构画在纸上是三个框，落到机房里是三种常见形态。单机一体：三层挤在一台服务器上，县科室级应用的典型起步形态，成本最低，风险也集中——机器一宕全停。纵向分离：数据层独立成数据库服务器，备份与权限管理立刻清晰，这是多数正式项目的标配。横向扩展：服务层多机负载均衡，前置分发请求，适合全市级、多部门并发场景。三种形态不是递进淘汰关系，是按并发规模与可用性要求选配——十几个人的科室应用上集群属于过度设计，全市一张图还单机裸奔属于欠账。
# 部署形态选型（按规模与要求） 形态 服务层 数据层 适用并发 可用性特征 单机一体 同机 同机 十级 机器宕全停 起步验证用 纵向分离 独立 独立库机 百级 库可独立备份与权限管理 横向扩展 多机均衡 独立或集群 千级 单台服务故障自动摘除 # 选型口诀：按明年的并发买设备 不按峰值幻想买 # 扩容路径：一体起步 预留分离接口 库先分离 服务再横向
常见问题快答
内网环境能用 WebGIS 吗？ 能，政务项目大多就这么干。浏览器与服务都跑在内网专网里，与互联网物理隔离，架构一分不变，只是"出厂分销"的分发范围从公网换成了专网。
为什么不用共享文件夹直接发数据文件？ 共享文件夹分发的是"文件副本"，十个人拷走十个版本，数据一改全作废；服务分发的是"访问能力"，数据在库里只有一份，改一次全体受益。这就是分发数据与分发服务的本质区别。
WebGIS 会不会取代桌面 GIS？ 不会，分工持续。重编辑、深分析、批量生产的内业场景，桌面端效率仍然占优；轻浏览、广分发的对外场景，服务化无悬念胜出。第 6 章的四条开发路线，正对应这两侧的不同深度需求。
承上启下
本节立起了骨架，回答了"服务是什么、有哪些、怎么流转"。下一节进入供给端视角：把第 4 章做好的地图文档真正发布成服务，配置缓存策略，盯着日志看它跑起来——那是一次更接近运维的体验。
- 三层分工：客户端管展示、服务层管计算、数据层管真相，客户端永不直连数据库
- 四类服务：瓦片给底图、地图服务给专题图、要素服务给查询编辑、地理处理给分析
- 图片与数据：地图服务返回图片、要素服务返回数据，前端要交互就得用后者
- 排障框架：从外向内，先网络后服务再数据，十分钟锁定故障层
- 缓存分支：命中毫秒回、未命中现场渲染，慢图问题八成在这
- OGC 通用语：多方汇聚与标准接口场景，WMS 与 WFS 是通用钥匙