【课程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）核心组件高可用

Control节点的核心组件（ETCD、API Server）是高可用关键，需独立集群部署：| 组件名称 | 部署方案（《01总体架构》P83-84） | 关联业务保障 | |----------------|------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------| | ETCD集群 | 3节点ETCD集群（与Control节点同节点部署），数据副本数=3，定期快照备份（每1小时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. 模拟1个Control节点故障（关闭节点），检查剩余2节点是否正常运行，ETCD集群是否保持“2/3存活”；

2. 测试API Server负载均衡：通过《04工作台》发起1000次“待办查询”请求，确认请求均匀分配至3个API Server实例；

3. 验证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）：

1. Ceph快照备份：核心业务数据（如biz_evt_wo）每1小时生成1次快照，快照保留7天；

2. 跨节点备份：Ceph集群数据同步至异地灾备节点（距离≥10公里），同步延迟≤5分钟；

3. 历史数据归档：stat_*统计数据（如《05数据中枢》的日统计报表）按季度归档至低成本存储（如HDFS），归档数据RPO≤24小时。

（3）分表分库适配

针对大表（如biz_device_telemetry_data设备遥测数据），采用“按时间分表+按区域分库”（《01总体架构》P98）：

• 分表：按月份分表（如biz_device_telemetry_data_202501），单表数据量控制在1000万条以内；

• 分库：按行政区划分库（如杭州西湖区分库、上城区分库），通过area_code关联，避免单库压力过大。

3.3 部署验证（文件合规性检查）

1. 模拟1个Ceph节点故障，检查数据是否从其他2个副本正常读取，确认《03数据库表》的biz_evt_wo工单数据可正常查询；

2. 测试备份恢复：从1小时前的Ceph快照恢复biz_device_telemetry_data数据，确认水质传感器数据无丢失（RPO≤1小时）；

3. 验证分表效果：查询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 部署验证（文件合规性检查）

1. 模拟SQL注入攻击：向《04工作台》登录接口提交注入语句，确认WAF拦截攻击并记录日志；

2. 测试敏感数据加密：查询《03数据库表》sys_user的user_phone字段，确认存储为加密字符串，前端展示为脱敏格式；

3. 验证权限控制：用“西湖区水利用户”登录，确认仅能查看西湖区的biz_water_qual_mon水质数据，无法查看其他区域数据。

五、总结：高可用架构的“文件闭环”

Control节点、存储平面、安全防护的架构选型，均严格遵循《01总体架构》的部署规范，适配《03数据库表》的数据存储需求与《06行业文件》的业务场景：

• Control节点3节点部署+组件集群，保障“调度不中断”；

• OpenEBS+Ceph混合存储+多层备份，保障“数据不丢失”；

• 多层安全防护+权限控制，保障“安全无漏洞”。

三者共同构成一网统管平台的高可用基石，支撑17+业务领域（如城管、水利、卫健）的稳定运行，符合《01总体架构》“实战化、精细化”的核心目标。

关注我们，获取更多精彩内容。