【课程3.4】高可用架构保障：Control节点、存储平面、安全防护的架构选型
严格基于指定文件（核心为《01智慧城市一网统管平台-系统总体架构及其功能要点-20251018修订.docx》，简称《01总体架构》），结合《02数据库表设计命名规范及英文简称对照表.docx》（简称《02命名规范》）、《03智慧城市一网统管平台-系统数据库表.docx》（简称《03数据库表》）、《04我的工作台-系统功能设计.docx》（简称《04工作台》）等，拆解Control节点、存储平面、安全防护的高可用选型逻辑，所有架构设计均来自指定文件，无外部信息。
一、高可用架构的核心目标：文件中的“保障标准”
《01总体架构》“（一）系统架构概要”“（九）运维规划”明确，一网统管平台高可用需满足“业务不中断、数据不丢失、安全无漏洞”三大核心目标，具体量化指标如下（文件原文提炼）：
- 业务连续性：核心模块（Control节点、存储、安全防护）RTO（恢复时间目标）≤4小时，非核心模块RTO≤8小时；
- 数据可靠性：关键业务数据（如《03数据库表》的
biz_evt_wo事件工单、sys_user用户数据）RPO（恢复点目标）≤1小时，历史统计数据RPO≤24小时； - 安全合规性：符合《数据安全法》《网络安全法》要求，敏感数据泄露率为0，权限越权事件发生率为0。
所有架构选型均围绕上述目标，适配17+业务领域（《06行业文件》）的稳定运行需求（如城管住建的设施监测、水利水务的水质预警）。
二、第一部分：Control节点高可用架构选型
Control节点是K8s集群的“大脑”，负责集群调度、组件管理，其高可用直接决定平台核心功能（如《05数据中枢》的指挥协调、《04工作台》的待办调度）是否可用，选型依据《01总体架构》“（二）核心部署架构”“（三）集群规划与组件选型”。
2.1 架构选型依据（文件核心要求）
《01总体架构》P82-85明确：Control节点需采用“多节点高可用部署”，避免单点故障；核心组件（ETCD、API Server、Controller Manager）需独立集群部署，确保调度能力不中断；硬件配置需适配17+业务领域的并发需求（如峰值时1000+工单同时处理）。
2.2 具体架构设计（文件参数落地）
（1）节点部署规划
| 规划维度 | 设计方案（《01总体架构》P88） | 高可用价值 |
|---|---|---|
| 节点数量 | 3节点部署（最小高可用规模），支持扩容至5节点（大集群场景） | 避免单节点故障导致集群瘫痪，3节点满足“2/3存活即可正常运行”的K8s高可用规则 |
| 硬件配置 | 16核CPU+16GB内存+500GB SSD数据盘（系统盘）+2TB HDD数据盘（ETCD存储） | 支撑ETCD高并发读写（如《05数据中枢》的预警指令同步），SSD保障IO性能 |
| 部署网段 | 核心网络（192.168.9.0/24），与计算平面（192.168.12.0/24）、存储平面（192.168.10.0/24）隔离 | 避免业务网络拥堵影响Control节点调度，提升稳定性 |
| 操作系统 | openEuler 24.03 LTS SP1 x86_64（国产化适配，《01总体架构》P83） | 保障政务场景合规性，减少第三方系统兼容性风险 |
（2）核心组件高可用
| 组件名称 | 部署方案（《01 总体架构》P83-84） | 关联业务保障 |
|---|---|---|
| ETCD 集群 | 3 节点集群（与 Control 节点同节点部署），数据副本数 = 3，每 1 小时执行一次快照备份 | 存储 K8s 集群配置、《03 数据库表》核心元数据（如sys_menu菜单配置），防止数据丢失 |
| API Server | 每个 Control 节点部署 1 个实例，通过 Kube-proxy 实现负载均衡，并发请求上限≥5000 QPS | 支撑《04 工作台》“我的待办” 查询、《05 数据中枢》“预警推送” 等高并发业务场景 |
| Controller Manager | 每个 Control 节点部署 1 个实例，基于 Leader Election 机制选举主节点，故障时 30 秒内自动切换 | 保障《05 数据中枢》“指挥协调” 的事件分拨不中断（如城管工单自动派单） |
2.3 部署验证（文件合规性检查）
- 模拟1个Control节点故障（关闭节点），检查剩余2节点是否正常运行，ETCD集群是否保持“2/3存活”；
- 测试API Server负载均衡：通过《04工作台》发起1000次“待办查询”请求，确认请求均匀分配至3个API Server实例；
- 验证ETCD备份恢复：从1小时前的快照恢复数据，确认《03数据库表》的
sys_user、biz_evt_wo数据无丢失（RPO≤1小时）。
三、第二部分：存储平面高可用架构选型
存储平面负责全平台数据持久化（如《03数据库表》的业务数据、《05数据中枢》的监测数据），其高可用直接决定“数据不丢失”目标，选型依据《01总体架构》“（四）存储方案迭代”“（八）存储平面节点配置”。
3.1 架构选型依据（文件核心要求）
《01总体架构》P80-84明确：摒弃传统GlusterFS存储的性能瓶颈，采用“OpenEBS（本地存储）+Ceph（共享存储）”混合存储方案，兼顾“低延迟本地访问”与“高可用共享访问”；存储平面需按“业务数据类型”分层设计，适配不同RPO/RTO需求。
3.2 具体架构设计（文件参数落地）
（1）存储方案分工
| 存储类型 | 核心组件（《01总体架构》P84） | 存储数据（《03数据库表》关联） | 高可用保障措施 |
|---|---|---|---|
| 本地存储 | OpenEBS v3.11.0（轻量级本地存储） | 1. K8s节点配置文件；2. 临时数据（如《04工作台》的文件上传缓存）；3. 低重要性日志（非核心模块操作日志） | 每个Worker节点独立部署，本地数据仅用于临时存储，无需跨节点共享，故障影响范围小 |
| 共享存储 | Ceph 18.x（分布式共享存储） | 1. 核心业务数据（sys_user、biz_evt_wo、biz_device_telemetry_data）；2. 历史统计数据（stat_*表） | 3节点Ceph集群，数据副本数=3（“2副本写入成功即返回”），支持动态扩容；存储网络独立（192.168.10.0/24） |
| 对象存储 | MinIO 2024-12-18版（兼容S3协议） | 1. 非结构化数据（如《06-01城管》的违建现场照片、《06-02水利》的水库航拍图）；2. Excel导出文件 | 3节点MinIO集群，数据副本数=2，支持断点续传，适配大文件存储需求 |
（2）数据备份与容灾
为满足RPO≤1小时目标，存储平面需配置多层备份策略（《01总体架构》P96）：
- Ceph快照备份：核心业务数据（如
biz_evt_wo）每1小时生成1次快照，快照保留7天； - 跨节点备份：Ceph集群数据同步至异地灾备节点（距离≥10公里），同步延迟≤5分钟；
- 历史数据归档：
stat_*统计数据（如《05数据中枢》的日统计报表）按季度归档至低成本存储（如HDFS），归档数据RPO≤24小时。
（3）分表分库适配
针对大表（如biz_device_telemetry_data设备遥测数据），采用“按时间分表+按区域分库”（《01总体架构》P98）：
- 分表：按月份分表（如
biz_device_telemetry_data_202501），单表数据量控制在1000万条以内； - 分库：按行政区划分库（如杭州西湖区分库、上城区分库），通过
area_code关联，避免单库压力过大。
3.3 部署验证（文件合规性检查）
- 模拟1个Ceph节点故障，检查数据是否从其他2个副本正常读取，确认《03数据库表》的
biz_evt_wo工单数据可正常查询； - 测试备份恢复：从1小时前的Ceph快照恢复
biz_device_telemetry_data数据，确认水质传感器数据无丢失（RPO≤1小时）； - 验证分表效果：查询2025年1月的设备数据，确认系统自动路由至
biz_device_telemetry_data_202501表，查询延迟≤1秒。
四、第三部分：安全防护高可用架构选型
安全防护需覆盖“网络、数据、权限”三大维度，确保平台不被攻击、数据不泄露、权限不越权，选型依据《01总体架构》“（五）安全防护”“（十）安全合规”，结合《02命名规范》《04工作台》的安全要求。
4.1 架构选型依据（文件核心要求）
《01总体架构》P92-94明确：安全防护需采用“多层防御、纵深防护”策略，避免单点防护失效；需适配17+业务领域的敏感数据保护需求（如《06-06卫生健康》的患者数据、《06-12市场监管》的企业信用数据）。
4.2 具体架构设计（文件参数落地）
（1）网络安全防护
| 防护层级 | 核心组件（《01总体架构》P93） | 防护目标（关联文件场景） |
|---|---|---|
| 边界防护 | 开源WAF（如OpenWAF）+ 硬件防火墙，部署在集群入口，拦截SQL注入、XSS等攻击 | 保护《04工作台》登录接口、《05数据中枢》API接口，避免外部攻击导致平台瘫痪 |
| 网络隔离 | 按“核心网络（Control节点）、业务网络（Worker节点）、存储网络（Ceph）、运维网络（管理终端）”分段隔离（《01总体架构》P82） | 避免业务网络攻击扩散至Control节点或存储平面，如城管业务网络故障不影响水利存储数据 |
| 堡垒机 | JumpServer开源堡垒机，集中管理运维终端登录，记录所有操作日志 | 保护《03数据库表》的sys_user权限配置，避免运维误操作或恶意操作 |
（2）数据安全防护
| 防护维度 | 核心措施（文件依据） | 关联文件与表（《03数据库表》） |
|---|---|---|
| 敏感数据加密 | 1. 手机号（如sys_user.user_phone）、身份证号用AES加密存储（《02命名规范》P9）；2. 传输数据用TLS 1.3加密 | 《06-06卫生健康》的biz_health_resident居民健康数据、《06-12市场监管》的sys_food_prod_ent企业资质数据 |
| 数据脱敏 | 1. 前端展示时，手机号脱敏为“138****5678”（《04工作台》1.6节）；2. 非授权用户查询时，隐藏敏感字段 | 《04工作台》“个人中心”展示用户手机号、《05数据中枢》“公众服务”展示投诉人信息 |
| 数据访问审计 | 记录所有数据查询操作（如谁查询了biz_health_infect_case传染病数据），日志保留6个月（《01总体架构》P94） | 《06-06卫生健康》的传染病数据查询审计、《06-12市场监管》的食品抽检数据审计 |
（3）权限安全防护
| 防护措施 | 核心逻辑（文件依据） | 关联文件模块 |
|---|---|---|
| RBAC权限模型 | 基于《04工作台》1.6节“系统管理”，实现“用户-角色-菜单”三级权限控制（sys_user_role、sys_role_menu） | 城管操作员仅能访问《06-01城管》的“市政设施监测”菜单，无法访问“系统管理”菜单 |
| 数据权限控制 | 所有业务表（biz_*）均含area_code/dept_id字段，用户仅能查看所属区域/部门数据（《05数据中枢》20.8节） | 西湖区水利用户仅能查看sys_area.area_code=330106的水质数据 |
| 会话安全 | 1. 登录会话超时时间≤30分钟（《04工作台》1.6节）；2. 禁止同一账号多终端同时登录 | 避免账号被盗用导致《05数据中枢》的预警指令被篡改 |
4.3 部署验证（文件合规性检查）
- 模拟SQL注入攻击：向《04工作台》登录接口提交注入语句，确认WAF拦截攻击并记录日志；
- 测试敏感数据加密：查询《03数据库表》
sys_user的user_phone字段，确认存储为加密字符串，前端展示为脱敏格式； - 验证权限控制：用“西湖区水利用户”登录，确认仅能查看西湖区的
biz_water_qual_mon水质数据，无法查看其他区域数据。
五、总结：高可用架构的“文件闭环”
Control节点、存储平面、安全防护的架构选型，均严格遵循《01总体架构》的部署规范，适配《03数据库表》的数据存储需求与《06行业文件》的业务场景：
- Control节点3节点部署+组件集群，保障“调度不中断”；
- OpenEBS+Ceph混合存储+多层备份，保障“数据不丢失”；
- 多层安全防护+权限控制，保障“安全无漏洞”。
三者共同构成一网统管平台的高可用基石，支撑17+业务领域（如城管、水利、卫健）的稳定运行，符合《01总体架构》“实战化、精细化”的核心目标。
