严格基于指定文件（核心为《01智慧城市一网统管平台-系统总体架构及其功能要点-20251018修订.docx》，简称《01总体架构》），结合《03系统数据库表》《05数据中枢》等，聚焦后台支撑10+技术底座的“部署规范”与“协同逻辑”，重点拆解“系统管理”“数据汇聚”两大核心模块，所有内容均来自指定文件，不涉及外部信息。
一、后台支撑架构的核心定位：技术底座的“全局支撑”角色
《01总体架构》21章“后台支撑系统”明确：后台支撑是一网统管平台的*“技术地基”*，通过10+技术底座模块（系统管理、基础设施、数据汇聚等），为上层“数据中枢”（《05数据中枢》16大模块）和“17大业务领域”（《06行业文件》）提供*“权限控制、数据衔接、资源调度、安全保障”四大核心支撑*，确保全平台稳定运行、数据互通、业务协同。
其架构设计需遵循两大原则（《01总体架构》P80-81）：
- 高可用部署
：核心模块（如系统管理、数据汇聚）采用多节点部署，避免单点故障；
- 分层协同
：技术底座内部模块按“功能定位”协同（如系统管理提供权限→数据汇聚按权限筛选数据），同时向上支撑数据中枢的“运行监测”“预警告警”等模块。
二、后台支撑10+技术底座模块清单（《01总体架构》21章提炼）
根据《01总体架构》21.1-21.10节，后台支撑包含10大核心技术底座模块，各模块定位及文件依据如下，后续重点聚焦“系统管理”“数据汇聚”：
模块名称 | 核心定位（《01总体架构》原文提炼） | 关键支撑场景（关联文件） |
|---|---|---|
1. 系统管理 | 提供租户、用户、角色、菜单、权限、日志等基础管理能力，是“全平台权限控制的核心” | 支撑所有模块的权限隔离（如《04工作台》1.6节“账号安全”、《06行业文件》的部门数据权限） |
2. 基础设施 | 提供代码生成、表单构建、数据源配置、定时任务等开发运维工具，“降低开发与运维成本” | 支撑《04工作台》表单开发、《05数据中枢》定时统计任务（如事件日统计） |
3. 数据汇聚 | 汇聚城市基础数据、运行数据、管理数据等，“解决数据孤岛问题，为数据中枢提供统一数据源” | 支撑《05数据中枢》“运行监测”“预警告警”的数据输入（如城管设施数据、水利水质数据） |
4. 数据交换 | 提供设备接入、API开放调用、接口监控能力，“实现平台与外部系统/设备的数据互通” | 支撑《05数据中枢》设备管理（对接ThingsBoard）、《06行业文件》第三方系统对接（如交警卡口数据） |
5. 工作流程 | 提供流程管理、审批中心能力，“支撑业务流程自动化（如工单审批、事件分拨）” | 支撑《04工作台》“我的待办”审批、《06-01城管》违建处置流程 |
6. 支付管理 | 提供应用信息、订单管理、退款、钱包管理能力，“支撑涉及支付的公众服务场景” | 支撑《06-15停车管理》缴费、《06-16物业管理》物业费支付 |
7. 会员中心 | 提供会员配置、等级、积分管理能力，“支撑公众服务的会员体系” | 支撑《06-10智慧社区》业主会员、《06-08文体旅游》游客会员 |
8. 公众号管理 | 提供公众号账号、粉丝、消息、菜单管理能力，“支撑政民互动的公众号渠道” | 支撑《04工作台》消息推送、《06-14营商服务》政策推送 |
9. 集群监控 | 监控集群资源、节点状态、组件健康、网络安全，“保障K8s集群与业务组件稳定运行” | 支撑《01总体架构》K8s集群运维、《05数据中枢》设备状态监控 |
10. 安全管理 | 提供权限审计、数据脱敏、网络安全、漏洞管理能力，“保障平台数据与运行安全” | 支撑《02命名规范》敏感字段加密、《06-06卫生健康》患者数据保护 |
三、核心模块1：系统管理模块的部署与协同
《01总体架构》21.1节“系统管理”明确其包含“租户管理、用户管理、角色管理、菜单管理、部门管理、日志管理”等子模块，是全平台权限控制的核心，需重点保障“高可用”与“数据一致性”。
3.1 部署设计（基于《01总体架构》K8s集群规划）
（1）部署目标
支撑全平台用户（管理员、业务操作员、网格员）的身份认证与权限控制；
保障用户数据、权限配置的持久化存储与高可用（RTO≤4小时，RPO≤1小时，《01总体架构》P96）；
适配《03系统数据库表》的“基础信息层（sys_*）”表结构，确保数据互通。
（2）核心组件与配置
子模块 | 部署组件（《01总体架构》推荐） | 存储方案（《01总体架构》P84） | 关键配置要点 |
|---|---|---|---|
用户/角色管理 | 芋道sys-user模块、KubeSphere RBAC权限组件 | 用户数据（sys_user、sys_role）存储于Ceph共享存储（避免单点故障），日志（sys_oper_log）存储于ElasticSearch | 1. 用户ID采用UUID（《03系统数据库表》sys_user.user_id）；2. 角色权限关联sys_role_menu表，确保“菜单-权限”一一对应 |
菜单管理 | 芋道sys-menu模块 | 菜单数据（sys_menu）存储于MySQL（Ceph挂载），缓存于Redis（降低查询压力） | 1. 菜单URL按《04工作台》规范配置（如“我的待办”对应/biz/myWo）；2. 菜单权限关联sys_role_menu表 |
日志管理 | 芋道sys-log模块、ElasticSearch（日志存储） | 操作日志（sys_oper_log）、登录日志（sys_login_log）存储于ElasticSearch（集群部署，3节点） | 1. 日志需包含“用户ID、操作模块、IP、时间”（《04工作台》1.6节“个人操作日志”）；2. 日志保留3个月（《01总体架构》运维规划） |
租户管理 | 芋道sys-tenant模块 | 租户数据（sys_tenant）存储于MySQL（Ceph挂载） | 1. 租户隔离数据（如不同区县租户仅看本区域数据）；2. 关联《03系统数据库表》sys_area.area_code |
（3）部署验证（文件合规性检查）
访问系统管理控制台（K8s Ingress暴露，路径/sys/admin），测试“用户新增”功能，确认数据写入《03系统数据库表》sys_user；
创建“城管操作员”角色，分配“市政设施监测”菜单权限，登录该角色用户，确认仅能访问指定菜单（《06-01城管》权限控制需求）；
查看操作日志，确认用户新增、权限修改操作均有记录（符合《01总体架构》“可追溯”要求）。
3.2 协同逻辑（内部+外部协同）
（1）内部子模块协同
租户管理→用户管理：租户创建后，自动生成该租户的“管理员用户”（关联sys_tenant与sys_user，通过tenant_id关联）；
角色管理→菜单管理：角色创建时，从菜单列表中选择可访问菜单，权限配置存储于sys_role_menu表（《03系统数据库表》）；
日志管理→所有子模块：用户操作（如新增用户、修改菜单）自动触发日志记录，日志内容包含“操作人（sys_user.user_id）、操作模块（sys_menu.menu_name）”。
（2）与其他模块协同
与《04工作台》协同：系统管理的“用户权限”决定《04工作台》“我的待办”的可见范围（如网格员仅看网格内待办）；
与《05数据中枢》协同：系统管理的“部门权限”控制《05数据中枢》“指挥协调”的事件分拨范围（如区城管仅分拨本区事件）；
与《06行业文件》协同：系统管理的“角色权限”控制《06-02水利》“水质监测”的数据查看范围（如水利操作员仅看分管水库数据）。
四、核心模块2：数据汇聚模块的部署与协同
《01总体架构》21.7节“数据汇聚”明确其核心是“汇聚城市全量数据，清洗融合后推送至数据中枢”，解决传统治理“数据孤岛”问题，是数据中枢的“数据源头”。
4.1 部署设计（基于《01总体架构》数据流转逻辑）
（1）部署目标
汇聚“城市基础数据、运行数据、管理数据、服务数据、综合评价数据”（《01总体架构》P87）；
实现数据清洗（格式统一、冗余剔除）、融合（关联多源数据），输出符合《05数据中枢》要求的标准化数据；
支撑《03系统数据库表》各层级数据的自动同步（基础层sys_、业务层biz_）。
（2）核心组件与配置
子模块 | 部署组件（《01总体架构》推荐） | 数据来源（关联文件） | 存储与输出（《03系统数据库表》） |
|---|---|---|---|
城市基础数据系统 | 数据采集Agent、MySQL（基础数据存储） | 行政区划（sys_area）、网格数据（sys_grid）（《05数据中枢》20.2节） | 存储于sys_area、sys_grid_info，推送至《05数据中枢》“地理编码管理”模块 |
运行数据系统 | Kafka（数据缓冲）、Flink（实时清洗） | 物联网设备数据（sys_device_telemetry_data）（ThingsBoard对接）、传感器数据（《06行业文件》） | 清洗后存储于biz_device_telemetry_data，推送至《05数据中枢》“运行监测”模块 |
管理数据系统 | ETL工具（DataX）、MySQL | 城管设施（sys_urban_fac）、水利管网（sys_water_pipe）（《06行业文件》） | 存储于biz_urban_fac、biz_water_pipe，推送至《05数据中枢》“资产管理”模块 |
服务数据系统 | API接口采集器、Redis（缓存） | 公众投诉（biz_public_complain）、政务服务（《06-14营商服务》） | 存储于biz_public_complain，推送至《05数据中枢》“公众服务”模块 |
数据清洗融合 | Flink（实时清洗）、Hive（离线融合） | 多源数据（如sys_urban_fac+biz_device_telemetry_data） | 融合后输出至stat_*表（分析统计层），推送至《05数据中枢》“分析决策”模块 |
（3）部署验证（文件合规性检查）
模拟接入城管摄像头数据（《06-01城管》），通过数据采集Agent推送至Kafka，确认Flink清洗后数据写入biz_device_telemetry_data（《03系统数据库表》）；
查看《05数据中枢》“运行监测”模块，确认清洗后的摄像头数据已同步至“设备分域监测”页面；
触发数据融合任务（如“设施数据+设备数据”融合），确认融合结果写入stat_device_online（设备在线率统计表）。
4.2 协同逻辑（内部+外部协同）
（1）内部子模块协同
数据采集→数据清洗：采集Agent将原始数据（如传感器的非标准格式pH值）推送至Kafka，Flink实时清洗（格式转换、异常值剔除）后，写入对应业务表；
数据清洗→数据融合：清洗后的单源数据（如城管设施数据、设备数据）通过Hive离线融合，生成多维度统计数据（如“某区域设施在线率”），写入stat_*表。
（2）与其他模块协同
与《01总体架构》“数据交换”协同：数据交换模块接入的第三方数据（如交警卡口数据），通过数据汇聚模块清洗后，推送至《05数据中枢》“交通运输”相关模块；
与《05数据中枢》协同：数据汇聚输出的标准化数据，分别推送至“地理编码管理”（基础数据）、“运行监测”（实时数据）、“分析决策”（融合数据），支撑数据中枢闭环；
与《06行业文件》协同：数据汇聚的水利水质数据（biz_water_qual_mon），推送至《06-02水利》“供水运行监测”模块，支撑水质预警。
五、后台支撑模块的全局协同：以“系统管理+数据汇聚”为核心
基于《01总体架构》“横向到边、纵向到底”原则，后台支撑10+模块以“系统管理（权限控制）”和“数据汇聚（数据输入）”为核心，形成全局协同网络，示例如下：
- 权限-数据协同
：系统管理为数据汇聚提供“数据权限过滤”（如区水务用户仅能汇聚本区水质数据），数据汇聚为系统管理提供“权限验证的数据源”（如用户所属区域来自sys_area）；
- 数据-业务协同
：数据汇聚输出的标准化数据，通过“数据交换”模块推送至《06行业文件》的业务模块（如城管设施数据→《06-01城管》），系统管理为业务模块提供“操作权限”（如仅城管操作员可修改设施状态）；
- 运维-安全协同
：集群监控模块监控“系统管理”“数据汇聚”的Pod运行状态，安全管理模块为数据汇聚提供“数据脱敏”（如公众投诉的手机号加密，《02命名规范》P9）。
六、总结：后台支撑架构设计的“文件合规性”
后台支撑架构设计需严格遵循《01总体架构》的“高可用、可扩展、安全合规”要求：
部署上：核心模块（系统管理、数据汇聚）多节点部署，存储采用OpenEBS+Ceph（《01总体架构》P84），适配K8s集群规划；
数据上：对接《03系统数据库表》的分层结构（sys_、biz_），确保数据格式符合《02命名规范》；
协同上：向上支撑《05数据中枢》《04工作台》，向下适配《06行业文件》，实现“权限-数据-业务”的全链路协同。
该架构为后续“数据中枢架构设计”“行业功能开发”奠定稳定的技术底座，所有设计均来自指定文件，确保与平台整体架构一致。
