第14章 数据底座与平台架构

本章导读

前面各章讨论“用 GIS 做什么”，本章讨论“靠什么支撑”。看似是工程问题，实际上是整个体系能否持续运转的根：一个应急 GIS 平台失败，很少是某个算法不灵，多数是数据找不到、对不上、更新不了，或者系统在上一次升级之后就没人再敢动。本章说到底是解决三个“对不上”：数据与对象对不上、能力与场景对不上、投入与运维对不上。分层是为了让每一层只解决自己的问题，标准是为了让任何一层都能被替换，治理是为了让数据在两年后仍然可信。几项判断值得先记住：一张图不是一块大屏，它的实质是统一基准、统一编码、统一接口；部级统建供给能力、地方建设落地场景，二者不可互相替代；数据治理的产出是可执行的规则而不是文档；架构演进的方向是减少耦合、增加复用，而不是追逐新技术。本章最后单独强调“运维”——它在目录里排在最后，实践中却应当被最先考虑：一个没有运维安排的平台，从上线第一天起就在折旧。

学习目标

读完本章，你应当能够：

• 用三个“对不上”（数据与对象、能力与场景、投入与运维）解释应急 GIS 平台失败的常见原因；
• 说明分层架构中各层只解决什么问题，以及“可替换”为什么是判断架构健康的标准；
• 区分部级统建与地方建设的职责边界，说出两者对接的三种方式与接口最小约定；
• 说明数据治理的产出为什么应当是“可执行的规则”而不是文档，并写出规则落地的两项检查；
• 指出性能问题时峰值并发、数据体量、计算复杂度三类原因的区分方法；
• 解释“运维经费、数据更新经费、模型率定经费写进年度预算”为什么比承诺先进架构更决定系统寿命。

前面各章讨论的是“用 GIS 做什么”，这一章讨论“靠什么支撑”。看似是工程问题，实际上是整个体系能否持续运转的根。一个应急 GIS 平台失败，很少是因为某个算法不灵，多数是因为数据找不到、对不上、更新不了，或者系统在上一次升级之后就没人再敢动。这些问题的根源都在架构。

本章的核心判断可以提前给出：应急 GIS 的架构问题，本质上是把“不确定的业务”映射到“确定的系统”上的问题。灾害的种类、规模、发生时间都不确定，但系统的分层、接口、数据模型必须确定。把不确定性强加到系统里，系统就会僵化；把确定性当成业务的前提，系统就会在第一次超预期事件中失效。好的架构是在两者之间留出余量与替换空间。

14.1 总体架构分层

架构分层的作用不是把图画整齐，而是把责任切开。每一层都应该能回答三个问题：这一层归谁管、坏了谁修、升级谁批。答不上来的分层，画得再精致也只是系统清单的重新排列。

14.1.1 横向三层与纵向三条

应急 GIS 平台通常可以划分为横向三层：数据层、平台层、应用层；再加纵向三条：标准规范体系、安全保障体系、运维运营体系。横向三层解决“能力从哪来”，纵向三条解决“能力能不能持续”。

数据层回答“有什么、以谁为准”，它的核心资产是时空数据库与目录，不是某套软件。平台层回答“怎么算、怎么发”，包括空间分析引擎、服务发布、三维渲染、任务调度、接口网关。应用层回答“给谁用、用来干什么”，包括一张图、监测预警、指挥调度、恢复重建等业务界面。

三条纵向体系经常被写成“保障措施”一笔带过，实际上它们才是决定系统寿命的变量。标准规范决定能不能换供应商，安全保障决定能不能过审，运维运营决定三年后还有没有人会用。

14.1.2 各层的职责边界

分层最怕的是职责串位。常见的串位有三种。第一种是数据层的职责被应用层接管：每个业务系统自己存一份底图、自己维护一套行政区划，结果是同一栋楼在不同系统里位置不同。第二种是平台层的职责被应用层接管：每个应用自己实现一遍缓冲区分析、自己写一遍坐标转换，结果是同类分析在不同模块里结论不一致。第三种是应用层的职责被平台层接管：平台为了“通用”，把业务流程硬编码进服务里，结果任何一次业务调整都要改平台。

判断是否串位有一个简单办法：看“变更的影响范围”。底图更新应当只影响数据层，分析算法升级应当只影响平台层，界面改版应当只影响应用层。如果一次改动会牵动三层，说明边界已经模糊。

14.1.3 一张图不是一个大屏

这是本章最需要强调的判断。大屏是表现层的一个视图，它可以是一张图的呈现方式之一，但绝不等于一张图本身。一张图的实质是三件事：统一空间基准、统一对象编码、统一服务接口。

统一空间基准，指的是所有图层落在同一个坐标系、同一个高程基准、同一套分幅与格网下。缺了这一条，叠加出来的图看着对、量出来错。统一对象编码，指的是同一栋房子、同一个隐患点、同一个安置点在所有系统里用同一个标识，缺了这一条，跨系统的数据永远对不上账。统一服务接口，指的是图层与能力以标准服务的方式提供，任何应用都能调用，缺了这一条，一张图就退化成某个厂商的封闭产品。

三件事做成，没有大屏也是一张图，因为它已经可以被任何界面调用、被任何系统集成。三件事没做，大屏再炫也只是几个系统的截图轮播，指挥员看到的仍然是拼接出来的画面，而不是同一份数据的不同视角。

14.1.4 纵向体系的真实作用

标准规范体系的作用是降低替换成本。应急管理信息化领域已集中制定发布百余项技术标准（应急管理部科技和信息化司访谈），这些标准的价值不在于文本本身，而在于它们让“换一家单位接着做”成为可能。一个没有标准约束的系统，本质上是被供应商锁定的系统。

安全保障体系的作用是让系统“能上线”。地理信息涉及《中华人民共和国测绘法》第四十六条规定的安全管理制度与技术防控体系要求，涉及《地图管理条例》与《公开地图内容表示规范》的表示边界，也涉及《中华人民共和国网络安全法》修改后自 2026 年 1 月 1 日起施行的数据安全义务。这些不是上线前补的材料，而是架构设计阶段就要预留的能力。

运维运营体系的作用是让系统“活得久”。它包含账号、权限、日志、监控、备份、演练六件事，缺任何一件，系统在第二年就会出现“没人敢重启”的状态。

表14-1 应急 GIS 平台的分层架构与各层职责

14.2 时空数据底座

判断一个数据底座是否成立，标准只有一条：能不能在一个统一的时空基准上，把一次事件涉及的所有对象一次找齐。找得齐，就是底座；找不齐，就只是几个数据库的集合。这条标准比任何技术指标都严格，因为它同时检验了覆盖度、关联性和时效性。

14.2.1 五类数据及其分工

时空数据底座通常包含五类数据，各有各的更新节律与权威来源。第一类是基础地理与公开底图，解决“在哪”。第二类是三维与实景数据，解决“什么样”。第三类是专题数据，解决“风险多大”。第四类是实时流数据，解决“现在如何”。第五类是业务台账，解决“谁负责、有多少”。

五类数据的性质差别极大。基础地理是稳定的、低频更新的；三维数据是重资产、高成本、长周期的；专题数据是周期性成果，随普查与区划更新；实时流是高频、易失、需要即时处理的；业务台账是高频变动、与行政流程强绑定的。把这五类混在一个库里管理，是数据底座设计中最常见的错误，因为它们的更新机制、质量要求、权限策略完全不同。

区分“底座”与“专题”的判据有两个：共用性和稳定性。共用性指有多少个业务需要它，稳定性指它的变化频率。两类都高的才进底座，共用性高但稳定性低的进平台层的缓存，共用性低的一律留在应用侧。按这个判据，底图、行政区划、地名地址、基础地形属于典型底座；隐患点台账、物资库、队伍属于专题；实时水位、视频流属于缓存。很多平台把所有数据都往底座里塞，结果是底座变成垃圾场，谁也不敢清理，谁也不敢依赖。

底座还有一条隐含要求：它的错误必须是可以承受的。如果底座里的某个图层错了，所有依赖它的业务都会错，因此底座数据的入库必须有比其他数据更严格的复核流程。把“快”放在“对”前面的底座，会把误差放大到整个体系。

14.2.2 公开底图：天地图与标准地图

公开底图是整个体系的“共同语言”。天地图完成全新改版后，一张底图汇聚发布了规划、地调、林草、海洋和测绘地理信息等 24 个自然资源专题；截至 2025 年 12 月 25 日，在线注册开发用户 148.29 万个，累计授权应用 112.93 万个，日均地图服务接口访问量 10 亿次，支撑 40 多个行业或部门、7000 多个政府用户、约 3.3 万家企业（自然资源部，2025-12）。

这组数字的意义不在规模，而在“接口经济”。日均 10 亿次接口访问意味着底图已经以服务形态被大量系统嵌入，而不是以数据拷贝的方式被各自拿走。服务化的底图天然解决了版本一致性问题：底图更新一次，所有调用方同步受益。相比之下，拷贝式的底图分发，每分发一次就多一个版本，一年之后没人说得清哪份是最新的。

标准地图则是另一条线。国家、省、市三级服务架构，全国发布总量 1.3 万幅（自然资源部，2025-12）。标准地图解决的是“边界与要素怎么表示”的合规问题，避免各单位自行绘制边界导致的表示错误。在应急场景中，标准地图常用于对外发布的示意图与新闻配图，内部指挥图则可以在此基础上叠加专题图层。

14.2.3 三维底座：从全国格网到城市级模型

实景三维中国的进展提供了三维底座的现实基线：初步建成，5 米、10 米格网等系列产品覆盖全国陆地国土，1:1 万数据覆盖 70% 陆地国土（自然资源部，2025-12）。这个“全国有粗模、重点区域有细模”的格局，决定了三维应用的基本策略：宏观分析用格网产品，局部精细分析用城市级模型。

城市级三维的进展是 300 余个地级以上城市完成 LOD1.3 三维模型生产，67 个城市开展智慧城市时空大数据平台建设试点（自然资源部，2025-12）。LOD1.3 这一级别的模型，本质上是带屋顶结构的体块模型：能表达建筑轮廓、高度、大致体量，不能表达立面细节与内部结构。对应急业务而言，这个精度已经能支撑相当多的分析：淹没范围与建筑的叠加、遮挡与通视分析、疏散通道的净空判断、区域性的人口暴露估算。它撑不住的场景也很明确：需要立面细节的火灾蔓延模拟、需要结构信息的倒塌研判、需要室内结构的救援路径规划。

把 LOD1.3 当成“三维城市已经建成”是常见的误读。它的价值在于“全国可比、成本可控、可批量更新”，而不在于“逼真”。

14.2.4 专题数据与实时流

专题数据的主体是第一次全国自然灾害综合风险普查成果。普查形成了 11 号公报（国务院普查办，2024-05），建立了 48 项调查类、61 项评估与区划类技术规范体系，并形成 89 项上千个指标的数据共享清单（国务院普查办，2024-05）。这些成果已经接入国家自然灾害综合监测预警系统和灾害事故电子地图（国务院普查办，2024-05），构成风险评估类应用的底数。

实时流数据的主体是监测预警数据。国家自然灾害综合监测预警平台接入气象、水利等 6 个涉灾部门 50 余类实时监测预报预警数据，以及第一次全国自然灾害综合风险普查 30 余类灾害数据（应急管理部，2025-07）。50 余类这个量级意味着接入不是“接一条线”，而是几十套异构接口的持续维护：协议不同、频率不同、坐标系不同、质量参差。实时流的工程难度不在带宽，而在“归一”——把不同来源的观测统一到同一时空基准上，并给出可信度标记。

14.2.5 时空基准与更新节律

时空基准是底座的地基，包含三项：平面基准、高程基准、时间基准。平面基准与高程基准应当采用国家统一规定的坐标系统与高程基准，并在元数据中明确标注版本；时间基准需要统一到同一时区并明确 UTC 偏移。三项中任何一项不一致，叠加分析都会产生系统性偏差，且这种偏差往往隐蔽——图上看着重合，量算结果却差出可观的数值。

更新节律必须按数据类别分别定义，不能一刀切。基础地理的更新应与基础测绘周期衔接；三维模型的更新应按“重点区域年度、一般区域按需”分级；专题数据的更新应与普查与区划的周期衔接；实时流按秒级到分钟级；业务台账按业务流程触发。把五类数据的更新都写成“及时更新”，等于没有规定。

表14-2 时空数据底座的五类数据与更新机制

14.3 部级与地方平台的关系

部级统一建设解决的是能力供给，地方分级建设解决的是场景落地。二者是供给关系，不是替代关系。把这句话理解反了，就会产生两种典型错误：地方重复建设底图与通用能力，浪费投资；或者地方完全依赖上级系统，本地台账与本地场景无人建设。

14.3.1 部级供给的是什么

部级供给的第一项是地理信息服务能力。应急管理部地理信息服务系统（EGIS）由部统一建设，省市级“应急管理一张图”依托其地图服务能力（应急管理部，公开文件）。这一表述明确了层级关系：底图与基础服务由部级提供，地方在此基础上叠加本地图层与业务。

第二项是业务系统。应急管理部统一建设并向全国免费推广的业务系统包括应急资源管理平台、“互联网+执法”、应急管理“一张图”、“天眼”卫星监测系统（《应急管理部关于推进应急管理信息化建设的意见》）。这些系统的共同特点是“通用性强、标准化程度高、地方单独建不划算”。

第三项是数据与网络。国家自然灾害综合监测预警平台汇聚跨部门监测预报预警数据，并构建了国家、省、市、县四级应急信息共享网络（应急管理部，2025-07）。四级网络的价值在于它已经把“纵向通道”打通，地方不需要再自建一套上报链路。

第四项是标准。百余项技术标准与连续多年印发的地方信息化建设任务书，构成了全国范围的“共同语言”（应急管理部科技和信息化司访谈）。

14.3.2 地方该建什么

地方不该重复建的是底图、通用分析能力、通用业务系统。地方必须建的是三样：本地台账、本地场景、本地数据更新机制。

本地台账是“部级系统里没有的东西”：本地的应急队伍、物资储备点、避难场所、重点防护目标、属地责任人。这些东西的颗粒度到乡镇、到村、到具体点位，任何上级系统都无法替代维护。

本地场景是“本地才有的业务组合”：山区的沟道洪水、沿海的风暴潮、化工园区的泄漏扩散、大型活动的人群管理。场景的差异决定了图层组合、分析模型、处置流程的差异，这部分只能本地建。

本地数据更新机制是“让台账不变旧”的制度安排。多数地方平台失败的地方不在建设期，而在建成后第二年：数据没人更新，系统逐渐与现实脱节，最后被弃用。

14.3.3 三种对接方式

部级与地方的对接，技术上只有三种方式，各有适用边界。

服务调用是最轻的一种：地方系统直接调用部级的地图服务、影像服务、地名地址服务，不落地数据。优点是版本永远最新，缺点是对网络与可用性高度依赖，一旦链路中断，本地功能受影响。

数据同步是较重的一种：按约定周期把部级数据同步到本地，形成本地副本。优点是断网可用，缺点是要解决版本一致性与增量更新，否则副本很快过期。

系统集成是最重的一种：通过单点登录、消息推送、工单流转，把部级系统与本地系统在业务流程上串起来。优点是体验统一，缺点是耦合度高，任何一方升级都可能影响另一方。

三种方式不是互斥的，实践中最常见的是组合：底图用服务调用，风险普查成果用数据同步，业务工单用系统集成。

表14-3 部级统建能力与地方平台的关系

14.3.4 接口的最小公约数

接口标准不统一是对接环节的常态。在这种情况下，能落地的最小公约数通常是三样：OGC 系列服务、政务数据共享目录、统一身份认证。

OGC 标准族（WMS、WFS、WCS、WPS、KML、CityGML 等）是空间数据与服务互操作的基础（OGC，公开标准）。采用 OGC 服务的好处是“任何符合标准的客户端都能读”，坏处是性能与功能受标准约束，复杂分析仍需专有接口。折中的做法是“标准接口保底、专有接口增强”。

CityGML 与 INSPIRE 的关系值得单独提一句：INSPIRE 以 CityGML 承载三维建筑主题（欧盟 INSPIRE，公开资料），这意味着三维数据的跨域交换有成熟路径可循，不必自创格式。

管理层面可以参照 ISO 22320:2018 的原则。该标准统一了事件管理的指挥、协同、全灾种、风险管理、准备、信息管理等原则（ISO，2018）。它不是技术标准，但它定义了“信息应该怎样在组织之间流动”，这对接口设计有实际约束力：接口不只是传数据，还要传状态、传责任、传确认。

标绘图层则可以直接采用现行国家标准。《突发事件应急标绘图层规范》为应急一张图的标绘图层提供了统一约定，采用它可以避免“同一个符号在不同系统里含义不同”的低级问题。

接口对接中最容易被低估的问题是版本同步。部级服务升级、字段调整、鉴权方式变化，都会让地方系统在某个早晨突然不可用。可行的做法有三条：接口调用必须做失败降级，不能因为上游抖动就让整个页面白屏；接口契约要版本化，新旧版本并行一段时间；建立变更通告机制，让上游的升级计划能被下游提前知晓。这三条都不是技术难题，难的是把它们写进双方的运维协议里。

14.4 数据治理

数据治理的产出不是一摞制度文件，而是几条能被系统自动执行的规则。判断治理是否见效，有一个很直接的标准：新来的数据能不能自动通过校验入库，不能通过时系统能不能说清楚为什么。做不到这两点，治理就还停留在文件层面。

14.4.1 六条规则

数据治理可以收敛为六条规则：目录、主数据、质量、更新、版本、权限。

目录回答“有什么”。它不只是资产清单，还应当包含责任单位、更新频率、精度、覆盖范围、共享属性。《现代化应急体系建设“十五五”规划》提出建立数据资源采集目录（国发〔2026〕15号），这一要求的实质是把“数据从哪来、谁来采、多久采一次”固定下来，而不是年终统计时临时汇总。

主数据回答“以谁为准”。同一个对象在多个系统里存在多个版本时，必须指定唯一权威源。主数据不确定，比对就永远做不完。

质量回答“合格线在哪”。质量规则必须是可执行的判断，而不是“数据应准确完整”这类表述。

更新回答“谁负责、多久一次、不更新怎么办”。最后半句最关键，没有约束的更新责任等于没有责任。

版本回答“能不能回到从前”。时空数据尤其需要版本，因为灾害调查、责任认定、审计都要回到特定时点的状态。

权限回答“谁能看、看到什么粒度”。这不是附加功能，而是《地理信息数据分类分级工作指南（试行）》落地的基本载体。

14.4.2 对象编码：治理的物理基础

所有治理规则最终都要落到“对象”上。一栋房子、一个隐患点、一个安置点、一支队伍，都应当有唯一编码，且这个编码在全域内稳定、不复用、可解析。

编码设计有三个常见错误。第一是用名称做主键，名称会变、会重名、会有别名。第二是用坐标做主键，坐标会因测绘更新而微调，一旦调整，历史关联全部断裂。第三是把编码设计成“含义丰富”的复合码，例如把行政区、类别、序号拼在一起，看似信息量大，实际上行政区一调整，历史编码就失效。

更稳妥的做法是“无含义主键加属性字段”：主键只保证唯一与稳定，所有分类、归属、状态都放在属性里。这样行政区划调整、类别细分都不会破坏历史关联。

14.4.3 质量规则的可执行化

质量规则要能被执行，必须落到五类检查上：拓扑检查、必填检查、值域检查、时相检查、精度检查。

拓扑检查解决几何关系，例如房屋不能重叠、河道必须连通、行政区不能有缝隙与重叠。必填检查解决完整性。值域检查解决取值合法性，例如灾种代码必须在标准代码表内。时相检查解决时效性，例如超过一定年限的台账自动标记为“待核实”。精度检查解决尺度匹配，例如把 1:1 万数据用于村级选址就应当告警。

五类检查里，时相检查最容易被忽略，也最能反映真实状态。多数数据问题不是“错”，而是“旧”。一套三年前的避难场所台账，标注的容量、联系人、开放状态大概率已经变化，但系统里看不出任何异常，因为它“格式正确”。把时相作为一等公民纳入质量规则，是数据治理从“格式合规”走向“内容可信”的分水岭。

元数据是质量规则的载体。基础地理信息数字成果元数据之所以被单独标准化，正是为了让数据的来源、精度、时相、处理方法可被机器读取与校验。没有元数据的质量规则，只能检查表面。

比元数据更进一步的是数据血缘：一条数据从哪个源系统来、经过了哪些加工、被哪些应用使用。血缘的价值在故障排查时最为明显——某个图层显示异常，能顺着血缘在几分钟内定位到源头的某次更新，而不是挨个系统排查。血缘的建造成本不低，通常只在关键数据集上做，但一旦建成，它会成为治理体系里最耐用的部分。

14.4.4 治理的现实阻力

数据治理最大的阻力从来不是技术，而是“部门不愿交出权威数据”。原因不复杂：数据一旦交出，口径就要被统一，口径统一意味着某些历史结论要被修正；数据一旦共享，责任边界就模糊，出了问题说不清是谁的。

破解这个阻力，靠说服不管用，靠三条制度安排更有效。第一是“谁提供、谁署名”，共享数据在成果中标注来源，保护提供方的贡献。第二是“谁使用、谁负责”，使用方对使用后果负责，提供方不对二次加工的结果负责。第三是“目录强制、内容自愿”，目录必须完整申报，具体内容可按分级分类规则确定共享范围。这三条不解决所有问题，但能把对抗变成谈判。

表14-4 数据治理的六条规则与落地要点

14.5 共享交换与开放

共享的瓶颈不在“能不能通”，而在“通了之后敢不敢用”。链路上打通只是第一步，真正决定共享成效的是三件事：数据能不能被理解、责任能不能被界定、合规能不能被证明。

14.5.1 三种共享模式

目录共享是最浅的一层：只共享元数据，说明“有这么一份数据、在哪、什么精度、找谁要”。它的价值是降低搜寻成本，缺点是“看得到拿不到”。

接口共享是中间一层：以服务方式提供数据与能力，调用方按需取用，不落地。优点是版本统一、权限可控，缺点是对网络与性能有要求。

数据落地是最深的一层：把数据同步或拷贝到使用方本地。优点是断网可用、可深度加工，缺点是版本分裂、责任扩散。

三种模式应当按数据敏感度与使用频度组合使用，而不是全用一种。高频、低敏感的数据适合接口共享；低频、高敏感的数据适合目录共享加审批调用；应急现场、断网场景必须支持数据落地。

14.5.2 权限模型的粒度

权限模型的粒度决定了共享的可行性。粗粒度权限只有“能看/不能看”两档，结果往往是要么全放开、要么全封闭。可行的权限模型至少要有五个维度：角色、区域、图层、要素、时相。

区域维度解决“只能看本辖区”，图层维度解决“能看路网不能看管线”，要素维度解决“能看隐患点分布不能看具体属性”，时相维度解决“能看历史不能看实时”。五个维度组合，才能在“够用”与“安全”之间找到位置。

14.5.3 可用不可见的技术路径

很多场景下，使用方需要的是“结论”而不是“数据”。这时可以采用“可用不可见”的方式：数据不出域，只输出计算结果。

常见路径有三条。脱敏是在数据出口处做字段级处理，去掉敏感属性保留空间位置。聚合是把个体数据汇总到统计单元，例如把点位汇总到格网或行政村。栅格化是把矢量对象转成连续表面，既保留空间格局，又消除个体标识。三条路径都会损失信息，损失的多少需要在具体业务中权衡。

沙箱是更彻底的做法：使用方在受控环境中运行分析，只能带走结果，不能带走数据。这种方式对平台的计算能力要求较高，但在跨部门数据融合中往往是唯一可行解。

14.5.4 共享不等于开放

共享是政府内部或授权主体之间的数据流动，开放是面向社会的数据提供，两者在合规要求上完全不同。对外开放必须经过地图审核，遵守《地图管理条例》与《公开地图内容表示规范》的表示要求；对内共享也要遵守《地理信息数据分类分级工作指南（试行）》的分级规则。

实践中常见的混淆是把“内部共享平台”当成“对外开放门户”，把内部图件直接发布到互联网。这类问题的后果不是技术性的，而是合规性的，且往往是不可补救的——一旦发布，撤回也无法消除已经扩散的副本。

14.6 性能与高可用

应急场景的性能问题不是“峰值高”，而是“峰值不可预测且不允许降级”。日常访问量平稳的系统，可能在一次重大灾害发生的几小时内承受数十倍的并发，而这个时刻恰恰是最不能出故障的时刻。

14.6.1 三类瓶颈

性能瓶颈通常集中在三处：瓦片服务、三维渲染、空间分析。

瓦片服务的瓶颈在并发与命中率。同一时刻大量用户拉取同一区域的地图瓦片，如果缓存未命中，请求会直接压到数据源。解决办法不是加大服务器，而是提高缓存命中率：预生成重点区域瓦片、设置多级缓存、按访问热度分级存储。

三维渲染的瓶颈在数据量与端侧能力。城市级三维模型动辄数十 GB，浏览器端无法一次加载。解决办法是轻量化与服务端渲染：按视锥裁剪、按层级加载、几何简化、实例化重复对象。

空间分析的瓶颈在计算复杂度。缓冲区、叠加、网络分析在数据量大时会呈非线性增长。解决办法是预计算与分级：把常用的分析结果预先算好存成服务，把复杂分析放到异步任务队列，允许用户“提交后回来看结果”。

容量规划要按“事件驱动”而不是“日常均值”来做。日常访问量只能决定基线资源，真正决定架构的是“一次重大灾害同时有多少人使用、用哪些功能”。经验上，灾害期间的访问集中在四类操作：拉底图、查周边资源、看实时态势、导出图件。这四类操作的资源特征完全不同，混在一起做容量估算必然失真，应当分别估算再取叠加峰值。

表14-5 三类性能瓶颈与应对策略

14.6.2 降级与容灾

比“扛住峰值”更现实的目标是“峰值下仍可用”。这需要设计降级路径：三维渲染失败时回落到二维，实时流中断时回落到最近一次快照，在线服务不可用时回落到离线包。

离线包是应急场景的特殊要求。在“三断”（断电、断网、断路）条件下，任何依赖云端的架构都会失效。离线包的设计要点有三个：范围要覆盖实际作战半径，内容要包含底图、影像、重点目标、预案，更新要能通过移动介质完成。

容灾的常见误区是只做“数据备份”不做“业务切换”。备份能恢复数据，但不能在灾害期间维持服务。真正的容灾要回答：主中心不可用时，多长时间内能在备用环境提供哪些功能。这个问题的答案应当写在预案里，而不是写在架构图里。

14.6.3 压测与真实峰值的差距

压力测试给出的数字，与真实灾害期间的负载往往不在一个量级，原因有三。第一，压测的请求是均匀的，真实访问是脉冲式的：一条通知发布后几分钟内，某个图层会被反复拉取。第二，压测的查询是随机的，真实查询高度集中：所有人都在看同一个乡镇、同一段河道。第三，压测不包含“人”的异常行为：反复刷新、重复提交、多标签页同时打开。

因此容量规划应以“场景”为单位而不是以“TPS”为单位。常见做法是列出三到五个典型场景（首屏打开、周边资源查询、实时态势刷新、图件导出），分别测出每个场景的资源消耗，再按“同时使用人数乘以场景分布”估算峰值。这样得到的数字未必精确，但它对应的是真实的使用形态。

14.7 运维与成本

应急 GIS 的全生命周期成本里，建设是小头，运维与数据更新是大头。这个判断在采购阶段经常被忽略，因为建设费用是一次性的、可见的，运维费用是持续的、分散的，容易被逐年压缩，直到系统不可用。

14.7.1 成本构成

成本主要由五部分构成：人力、算力、存储、数据更新、软件许可。

人力成本最容易被低估。一个省级平台稳定运行，需要的不是“一个运维人员”，而是数据管理、系统运维、模型维护、用户支持四类角色，且这四类角色的能力要求完全不同。

算力与存储成本随三维与 AI 应用快速上升。三维模型、影像、点云都是“重资产”，且需要多版本留存，存储需求往往在第三年翻倍。

数据更新成本最容易被砍。它是“看不见的投入”，不更新也不立刻出问题，但两年之后系统的可信度会断崖式下降。

软件许可成本与国产化进程相关。这里的关键不是“贵不贵”，而是“能不能替换”。许可条款中如果包含数据格式封闭、接口不开放、迁移需授权等条件，长期成本会远超采购价。

14.7.2 四个断点

运维失效通常发生在四个断点上。

第一个断点是没人管数据。系统有运维团队，但没有数据管理员，数据更新停留在“谁提需求谁负责”的状态。

第二个断点是没人管模型。洪水淹没、扩散模拟这类模型有大量参数，参数需要随下垫面变化而重新率定。没人管模型，模型就会在两年内变成“演示功能”。

第三个断点是没人管账号。人员调动后账号不回收，权限不调整，最终要么权限泛滥，要么为了安全一刀切关闭外部访问。

第四个断点是没人管演练。系统从未在真实压力下运行过，第一次真实使用就是第一次压力测试。

四个断点的共同特征是“不花钱也看不出问题”，因此最难争取预算。可行的做法是把它们写进年度考核指标，而不是写进项目建议书。

还有一个隐性断点值得单独提醒：没人管接口。平台与外部系统的对接往往由项目期的一次性开发完成，之后上游变了、下游变了，没有人负责跟进。接口失效不像系统宕机那样显眼，它表现为“某个图层不显示了”“某个数据一直是旧值”，用户逐渐学会绕开，最后这个功能就静悄悄地死了。把接口纳入资产台账、定期探测可用性，是成本极低但收益明显的运维动作。

14.7.3 国产化与可持续

国产化不是一次性替换，而是持续演进。替换操作系统、数据库、GIS 内核之后，性能特征、运维工具、故障模式都会变化，需要重新积累经验。把国产化当成“换一批软件”，往往会在上线后遇到性能与兼容问题。

更稳妥的路径是“分层替换、逐层验证”：先替换非关键路径，再替换核心服务；每一层替换后做完整的回归测试与压力测试；保留回退方案至少一个版本周期。

14.8 架构演进的判断

架构演进的正确方向是“减少耦合、增加复用”，而不是“追新技术”。新技术本身不产生价值，只有当它降低了某处的耦合或提高了某处的复用，才值得引入。

14.8.1 三条判断标准

可替换性：任何一个组件能否在不影响其他组件的前提下被替换。这是衡量架构是否健康的第一个指标，也是最容易被忽略的指标。一个不能被替换的系统，无论功能多强，都是负债。

可观测性：系统内部状态能否被外部观察。应急系统的可观测性要求比一般业务系统更高，因为在灾害期间，“系统慢”和“网络断”必须能被区分开。

可迁移性：数据和能力能否迁移到另一套环境。这直接决定了国产化替换、云环境变更、供应商更替的成本。

14.8.2 四个技术方向

第一个方向是云原生。容器化、微服务、弹性伸缩的价值在于“按需分配算力”，这对峰值不可预测的应急场景是刚需。但云原生也带来了运维复杂度，需要配套的可观测性与发布管理能力，否则会把“一个大系统”拆成“一堆小故障”。

第二个方向是湖仓一体。应急数据兼有结构化台账、半结构化上报、非结构化影像，传统的数据仓库与数据湖各自只能覆盖一部分。湖仓一体的价值是用一套存储支撑多种分析，避免“数据搬来搬去”。

第三个方向是 API 网关。把能力以接口形式统一出口，好处是权限、流量、审计可以集中管理，坏处是网关本身成为单点，需要高可用设计。

第四个方向是云边端协同。云端做全局分析与长期存储，边缘做实时处理与本地自治，端侧做采集与轻量展示。这个方向对“三断”场景尤其重要，因为它把“必须联网才能用”变成“断网也能用，联网再同步”。

边缘节点的部署位置需要提前规划，不能临时决定。合理的做法是在地市级设区域节点，在重点县设前置节点，节点上预置底图、影像、重点目标、预案与常用分析能力。节点的容量不求全，求“够用到等到支援”。同步策略也要设计：断网期间本地产生的标绘、核查、上报数据，恢复后如何合并、冲突如何裁决，必须在设计阶段就定好规则，否则恢复联网的那一刻就是数据混乱的开始。

14.8.3 两个反面

第一个反面是微服务过度。把一个业务简单的系统拆成几十个微服务，带来的不是灵活性，而是调用链复杂、故障定位困难、发布协调成本高。拆分的依据应当是“变更频率与团队边界”，而不是“技术潮流”。

第二个反面是中台空转。中台的建设目标是把通用能力沉淀下来供各业务复用，但如果中台团队不掌握业务、业务团队不愿用中台，中台就会变成“又一个系统”。判断中台是否成功，只看一个指标：有多少业务真正调用了中台的能力，而不是中台自己有多少功能。

14.8.4 与政策要求的对应

《现代化应急体系建设“十五五”规划》提出的算力一体化、数据资源采集目录、数据安全治理、人工智能融合等要求（国发〔2026〕15号），在架构上分别对应四件事：算力一体化对应资源池化与统一调度；采集目录对应数据治理的目录规则；数据安全治理对应分级分类与权限体系；人工智能融合对应模型服务化与样本管理。这四项要求都不是新增一套系统，而是对现有架构的约束与改造。

认识到这一点很重要：政策要求往往被理解为“要建新系统”，实际上多数是对既有架构的补齐。把政策要求翻译成架构任务，比翻译成项目清单更有价值。

14.9 边界与误区

第一，把架构图当成系统清单。架构图的价值在于表达职责与依赖关系，如果图上每个框都对应一套采购的系统，那它就不是架构图，而是采购清单。

第二，认为“上云就解决了弹性”。云提供的是资源弹性，不是架构弹性。一个单体应用放到云上，峰值来临时依然会垮。

第三，把数据治理等同于建目录。目录只是入口，主数据、质量、更新、版本、权限五条不做，目录就是一个不断过期的通讯录。

第四，把三维当成越高精度越好。三维的精度应当与业务动作匹配：淹没分析用格网产品足够，火灾内攻需要建筑内部结构。盲目追求高精度，成本会失控，性能会崩塌。

第五，把“通过等保”当成安全做完。等保解决的是基线的合规性，应急场景还需要考虑数据分级、供应链、离线介质、临时权限等特殊风险。

第六，把“接口打通”当成“业务打通”。接口能调通只说明协议对得上，业务能不能串起来，取决于编码是否统一、状态是否同步、责任是否明确。三者不解决，接口越多，系统越乱。

边界方面，本章讨论的架构都以“有稳定的运维主体”为前提。在运维主体不明确的情况下，任何架构都会在两年内退化。技术选型再合理，也替代不了“有人负责”这一条。

还有一条常被忽视的边界：架构解决的是“能力如何被组织”，不解决“业务是否应该做”。一个业务本身没有共识，再好的架构也只能把它固化得更快。因此架构设计之前，先确认业务边界与责任划分，比讨论技术选型更要紧。

本章小结

应急 GIS 的架构，说到底是在解决三个“对不上”：数据与对象对不上、能力与场景对不上、投入与运维对不上。分层是为了让每一层只解决自己的问题，标准是为了让任何一层都能被替换，治理是为了让数据在两年后仍然可信。

本章的几个判断可以归纳为：一张图不是一个大屏，它的实质是统一基准、统一编码、统一接口；部级统建供给能力，地方建设落地场景，二者不可互相替代；数据治理的产出是可执行的规则而不是文档；架构演进的方向是减少耦合、增加复用，而不是追逐新技术。

值得单独强调的是“运维”在本章中的位置。它被放在最后讨论，但在实践中应当被最先考虑：一个没有运维安排的平台，从上线第一天起就在折旧。把运维经费、数据更新经费、模型率定经费写进年度预算，比在项目建议书里承诺“先进架构”更能决定系统的实际寿命。

如果只允许记一件事，那应当是：判断一个应急 GIS 平台是否健康，不看它有多少功能，看它能不能被替换、能不能被观测、数据能不能被追溯。三条都成立，系统就有生命力；三条有一条不成立，早晚要推倒重来。

思考与练习

1. 为一个市级应急 GIS 平台画出四层架构（数据、服务、应用、接入），并标注每层的可替换点与替换代价。
2. 列出部级统建系统与地方平台对接的最小接口约定（至少五项），并说明不满足时会出现什么现象。
3. 某平台上线两年后数据可用率持续下降。请从治理规则、责任岗位、更新触发三方面各诊断一条原因。
4. 一次汛期高峰把平台压垮。请区分三类原因，并给出针对性的三项改造建议（不能只是“加服务器”）。
5. 写出三条“可观测”指标（能否被观测），要求运维人员可在不读代码的情况下判断系统健康度。
6. 把“数据可追溯”翻译成三条可检查的规则，并说明追溯失败时最可能先暴露在哪一层。