ICS 35.020 州 市 DB3212
CCS L 70
泰 地 方 标 准
DB3212/T 1170—2024
网格化社会治理平台应用规范
Specification for grid social governance platform application
2024-10-10 发布 2024-11-10 实施
泰州市市场监督管理局
发 布
DB3212/T 1170—2024
前
言
本文件按照 GB/T 1.1—2020《标准化工作导则
定起草。
第 1 部分：标准化文件的结构和起草规则》的规
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由泰州市市域社会治理现代化指挥中心、泰州市网格化服务管理中心提出。
本文件由中共泰州市委政法委归口并组织实施与监督。
本文件起草单位：泰州市市域社会治理现代化指挥中心、泰州市网格化服务管理中心、中国电信股
份有限公司泰州分公司。
本文件主要起草人：许鑫、施驰乐、周正坤、唐小妹、印丹、郑泽军、夏葳、陈毅、邓恺、孙津哲。
I
DB3212/T 1170—2024
网格化社会治理平台应用规范
1
范围
本文件规定了网格化社会治理平台（以下简称“平台”）应用的总体要求、架构设计、技术需求、
用户设计、功能设计、接入要求等。
本文件适用于网格化社会治理平台应用建设以及基层网格化社会治理特色应用接入。
2
规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，
仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本
文件。
3 GB/T 20269 信息安全技术 信息系统安全管理要求
GB/T 20270 信息安全技术 网络基础安全技术要求
GB/T 20271 信息安全技术 信息系统通用安全技术要求
GB/T 20273 信息安全技术 数据库管理系统安全技术要求
术语和定义
下列术语和定义适用于本文件。
3.1
网格化社会治理平台
grid social governance platform
按照“网格化管理、精细化服务、信息化支撑”的理念，以“网格”为单位划分社会治理单元，依
托信息化平台及手段，“人、地、事、物、组织”等全要素信息常态化服务与管理的平台。
4
总体要求
网格化社会治理平台应满足以下要求：
a) 平台设计应充分考虑与政务平台的各类数据资源共享和互通，应采用模块化设计；
b) 应保证接入平台的设备、系统、用户以及数据传输的安全；
c) 平台应具备用户分层分类功能，满足不同用户不同权限的需求；
d) 平台交互界面应简洁、友好、清晰；
e) 平台应具备良好可扩展性，满足各市（区）、乡镇（街道）网格化社会治理特色应用接入。
5 架构设计
5.1 总体架构
平台总体架构分为基础设施层、数据层、功能应用层、展示层四个部分，以及安全保障与标准规范
两大体系。架构设计见图 1 总体架构图。
1
DB3212/T 1170—2024
图 1 总体架构图
5.2
基础设施层
基础层包括设备资源（感知设备、控制设备、执行设备等）、IT 系统（部门应用、区县/街道/社
区应用）、数据（业务数据、时空数据、分析数据），由政务云提供各系统基础运行环境，并通过电子
政务外网或互联网进行访问。
5.3 数据层
5.3.1 数据层包含接入层、核心能力、开放层及基础框架。
5.3.2 接入层包含接入各类设备、业务系统及专业数据；
5.3.3 核心能力主要为大数据治理能力、AI 建模能力、地图能力、基础能力、扩展能力。
5.3.4 开放层负责对平台各类能力、数据成果、应用相关服务开放。
5.3.5 基础框架保障平台技术路线的统一。
5.4 功能应用层
功能应用层包含党建引领、基础数据、巡查走访、矛盾调解、事件受理、任务派发、网格心声、指
挥调度、网格管理、态势感知、警网融合、专项行动、市（区）个性化应用、乡镇（街道）个性化应用
等。
5.5
展示层
展示层面向各级用户提供不同的接入服务，针对不同业务不同用户按需开放。
6
技术要求
6.1
技术路线
平台设计应遵循以下技术路径：
a)
基于微服务的架构模式进行设计，前后端应分离，后端业务逻辑采用接口方式，前端通过调用
统一数据接口展现后台业务数据。
2
DB3212/T 1170—2024
b)
WEB 端采用SpringCloud 微服务技术栈，语言为java，前端使用 Vue框架，后端使用SpringBoot，
数据库为 mysql，采取容器平台进行部署；APP 端采用原生安卓+uni 小程序。
6.2
性能要求
平台应符合表 1 所规定的性能要求。
表 1
网格化社会治理平台性能要求表
序号 性能名称 指标要求
1 操作性 用户操作系统响应时间≤0.5 秒； 平均故障间隔时间（MTBF）≥2160 小时； 系统具有集成其他应用系统接口的能力；
2 交互性 指录入，修改或删除一条记录、发布一条信息等操作，平均响应 时间：0.2—0.8 秒，峰值响应时间：0.5 秒—1 秒；
3 查询 简单查询平均响应时间：1 秒—3 秒，复杂查询平均响应时间：3 秒—5 秒。
6.3
数据要求
应满足以下要求：
a)
《江苏省网格化社会治理基础数据规范》的相关要求；
b)
图片格式宜采用 jpg、png 等通用格式；
c)
数据库管理系统应满足 GB/T 20273 的要求。
6.4
安全要求
应满足以下要求：
a)
信息系统安全符合 GB/T 20269 的要求；
b)
网络基础安全符合 GB/T 20270 的相关规定；
c)
信息系统安全通用技术要求符合 GB/T 20271 的相关规定。
6.5
维护要求
一般故障响应时间不超过 1 h，重大故障响应时间不超过 2 h。
7
用户设计
平台应设置市县乡三级中心、网格长、网格员、民辅警、乡镇（街道）联动部门、群众等用户。
8 功能设计
8.1 统一门户
应支持提供统一登录界面，提供对各类用户的登录、授权、认证、信息管理、日志记录、消息提醒
功能；各类应用能够通过统一门户进行接入和上下架管理。
8.2
党建引领
应提供各级党组织、党员、党建活动信息采集及接入功能，将党员、党组织设置与管理网格有机融
合。
8.3
基础数据
应提供一标三实、关注人群、关爱对象的信息采集功能，做到人进户、户进房、房进网格、网格进
图。
3
DB3212/T 1170—2024
8.4
巡查走访
应实现对各地区服务走访规则的自定义化，各地区可根据当地实际业务场景对关爱对象、关注人群、
房屋等业务进行定制化配置，能准确记录各网格员巡查信息。
8.5
矛盾调解
应支持网格员对辖区内涉及的矛盾纠纷事件进行记录和管理，做好矛盾纠纷的源头预防、接待化解
和依法处置工作。
8.6
事件受理
应提供自下而上的事件上报信息流转通道，并与泰州市 12345 系统关联，纵向上实现市、县（市、
区）、乡（镇、街道）、村（社区）、网格五级工单流转，横向上与各部门联通、一键转派，并定义各
环节处理时限，对各环节处理时限进行考核。同时提供事件办理评价功能，提供事件处理信息的全流程
展示。
8.7
任务派发
应能够接入与各部门、各地区平台转入事件，基于网格指挥体系实现各类任务的精准触达，使各类
网格事件在线上就能闭环处理，按步推进事件的下发、催办、回复处理、审核、办结等。
8.8
网格心声
市民可通过该功能查询所属网格、网格长、网格员的基本信息，通过该功能上报网格内的事件、诉
求、社情民意线索等，上报后通过事件受理功能进行闭环处置并反馈至本功能。
8.9
指挥调度
能够视频点调网格员的工作终端，便于中心开展统一的指挥调度工作。同时，与政法委视频会议系
统对接，实现市县乡三级硬终端和网格员工作终端的联动视频点调。
8.10
网格管理
应提供网格、网格员、微网格联络员的基础信息管理功能。
8.11
态势感知
实时准确掌握各类事件发生情况，实现对地区基层治理事件的全面监测和精细化的闭环管理，结合
GIS、视频分析、大数据分析监测呈现总体态势，同时聚焦热点事件呈现主题热点问题及事件状态追踪，
实现态势看得清，资源找得到、事件管得住。
8.12
专项行动
整合社保、医保、不动产、税务、12345 等民生数据，逐步实现基层社会治理问题全口径汇聚，通
过建立数据推送机制，以各类专项行动形式将社会治理数据及分析结果推送至网格员，开展网格巡查、
入户走访、矛盾纠纷排查等工作。
8.13
市（区）个性化应用
根据社会治理实际需求，市（区）部门可基于平台构建个性化应用，按照相关要求接入市级平台。
8.14
乡镇（街道）个性化应用
根据社会治理实际需求，乡镇（街道）部门可基于平台构建个性化应用，按照相关要求接入市级平
台。
9
应用对接流程
9.1
应用接入流程
接入流程见图 2。
4
DB3212/T 1170—2024
图 2 应用接入流程
9.2
接入申请
接入方提交相关材料至市中心，包括机构信息、联系人、联系方式和应用信息，应用信息中需包含
应用名称、接入 IP、所需参数、应用图标等内容。
9.3
接入测试
接入方在授权的测试环境中，根据市中心提供的测试密钥，按对接规范进行实施，开展联调，形成
测试报告。
9.4
上线启用
a)
接入方向市中心提交上线申请，市中心分配正式密钥；
b)
页面接入：接入方获得正式密钥，由市中心配置应用系统，接入方自行授权（仅区县用户），
完成上线；
c)
接口（API）对接：接入方获得正式密钥，自行配置正式环境应用，确认接口、数据无误，完
成上线。
9.5
应用接入方式
页面接入方式应符合附录 A 的要求，API 接入方式应符合附录 B 的要求。
5
DB3212/T 1170—2024 附 A A A
录
（规范性）
页面接入方式
A.1
接入APP端应提供互联网URL，接入WEB端需提供电子政务外网URL。
A.2
平台通过接入方提供的URL，跳转到相应页面。
A.3
平台将接入方所需要的参数，组装成JSON字符串，并生成随机的 16 位key对字符串进行AES加密，
生成加密数据data；同时平台还会对 16 位key进行RSA的公钥加密，生成加密数据sign。加密值会以“?
data=xxxxxxx&sign=xxxxxxx”的方式，拼接在接入方提供的URL后面。
A.4
接入方获取到URL传输的中参数data和sign值，通过RSA的私钥对sign值解密，解密后获取到 16
位的key，通过 16 位key对data数据进行AES解密，最终获取到平台提供的数据。
A.5
接入方通过解密链接中data的值，获取平台提供的数据。
A.6
接入方通过解密获取的数据判断当前登录人的信息，对页面进行相应的渲染。
6
附 BB B DB3212/T 1170—2024
录
（资料性）
API 接入方式
B.1
接入方根据申请的正式环境appid和appsecret调用平台“获取token”的接口，获取到accessTok
en，accessToken的有效期为 2 小时。
B.2
接入方获取到accessToken后，应调用平台“获取随机数（nonce）”的接口，获取到随机数。
B.3
接入方携带accessToken和nonce向平台发起请求时，生成一个签名，这个签名将作为请求的一部
分发送给平台，用于验证请求的合法性。签名算法以接口文档为准。
B.4
平台收到请求后，使用相同的算法和参数重新计算签名，并与收到的签名进行比较。如果两者匹
配，则认为请求是合法的；否则，请求被拒绝；调用完成后，平台清除随机数，如接入方需要再次调用，
则需要重新调用“获取随机数”的接口来获取随机数。
B.5
签名相关的公共参数统一放在请求HTTP的header中。API访问签名参数表见表B.1，API请求参数表
见表B.2。
表 B.1
API 访问签名参数表
参数 是否必填 类型 说明
accessToken 是 字符串 通过获取 token 的接口获取
表 B.2
API 请求参数表
参数 是否必填 类型 说明
ip 是 字符串 应用服务 ip
port 是 字符串 应用服务端口
sceneCode 是 字符串 应用场景编码
serviceCode 是 字符串 接口服务编码
apiName 是 字符串 具体接口名称
B.6
请求格式：http://{ip}:{port}/dy/{sceneCode}/{serviceCode}/{apiName}。
B.7
接口数据响应：应采用统一标准规格的JSON数据进行响应；应提供相应的接口说明、编码说明文
档，每个接口对应一个接口说明表，每个业务模块对应一个响应编码说明表，编码说明表中的 200、50
0 为固定返回值，API访问签名参数见表B.3，支持平台业务返回的API访问接口编码见表B.4。
表 B.3
API 访问接口编码表（HTTP 返回）
序号 编码 说明 示例
1 200 成功 { "timestamp": "2024-03-18 09:50:23", "status": 404, "error": "Not Found", "message": "No message available", "path": "/dy/user/add11213" }
2 400 请求出错
3 401 认证失败
4 403 权限异常
5 404 资源不存在
6 502 网关出错
7 0 其他错误
7
DB3212/T 1170—2024
表 B.4
API 访问接口编码表（平台业务返回）
序号 编码 说明 示例
1 200 成功 { "code": 200, "message": "添加成功！", "data": {}, "timestamp": 1710731329515 }
2 500 校验失败
3 501 验签失败
4 101 异常的行政区划
5 0 其他错误
━━━━━━━━━━━
8