从双11到某省政务平台：信息系统架构的本质思考

从双11到某省政务平台信息系统架构的本质思考一、架构不是设计出来的是长出来的某电商巨头今天的架构是业务增长、填坑、拆分、迭代的结果不是一开始就神设计。核心技术底座大量依赖开源产品K8s 等不存在从零到一的原创壁垒。架构的本质是随业务规模逐步演进业务不到那个量级架构再先进也是空转。二、高并发的真相拆分不是神迹双11 这类高并发本质是按商家/用户/区域做彻底拆分。对外宣传的全国总 QPS是无数分片、分库、分布式单元的流量总和。总 QPS 不代表单点数据库或单机的抗压能力。一台 MySQL 扛不住百万 QPS但一百台各扛一万加起来就是一百万。高并发不是神秘技术是拆分与隔离。三、云原生与 Pod 的真实目的给每个商家分配 Pod核心价值不是让用户更稳定而是细粒度资源控制超卖与混部提升硬件利用率最终结果大幅降低成本。云原生的本质是省钱工具不是高并发的前提条件。四、技术门槛的真相能做大规模落地门槛来自业务量级、投入、时间、团队迭代。门槛不是独家神秘技术而是业务需要推着你走到那一步。别人做不到大多是没业务量、没投入不是学不会技术。五、政务系统到底需要什么以某省政务平台为例做一次工程推演假设该省人口上亿。5.1 用户量估算指标估算依据常住人口1 亿上亿人口大省注册转化率~60%政务服务刚需但非人人活跃注册用户~6000 万1 亿 × 60%5.2 日活与峰值MAU月活注册用户的 20-30%即 1200 万-1800 万DAU日活政务类应用粘性低DAU/MAU 取 12-15%即 150 万-270 万用户行为每次打开查 1-2 项社保/公积金/违章停留 3-5 分钟请求 5-15 次5.3 峰值 QPS参考同类省级政务平台的实际流量特征工作日上午 9-11 点集中办理高峰月头/季头集中查询社保、公积金政策发布后的突发查询潮峰值 QPS 按 3 万估算其中读写比 9:1 读 QPS ≈ 27000 写 QPS ≈ 3000 含表单提交、审批、状态流转以及读请求附带的日志记录 3 万 QPS 直接打 MySQL单机扛不住。 必须用 Redis 做前置缓冲层让 MySQL 尽量轻载。5.4 架构方案一拖N Redis 集群整个架构核心就三层没有微服务没有 K8s没有服务网格用户请求 │ ▼ API 无状态层Nginx 负载均衡 │ ├── 读请求 ──► Redis 集群命中直接返回 │ 未命中 ──► 地市从库回填缓存 │ ├── 业务写请求 ──► MySQL 主库省会──► 成功后更新 Redis 缓存 │ │ │ 主从复制1 拖 N │ │ │ ┌──────┬──────┬──────┬──────┬──────┬── │ ▼ ▼ ▼ ▼ ▼ ▼ │ 地市-1 地市-2 地市-3 地市-4 ... 地市-N │ └── 日志/流水 ──► Redis缓冲──► 定时批量落库 各地市读请求走本地从库业务写请求回省会主库数据库一拖N省会部署 MySQL 主库承载所有业务写入各地市各部署一个从库承载本地读请求业务写 QPS 约 30008 核 MySQL 主库可承载读压力被 Redis 和从库分摊主库故障时任一从库可手动提升为主具备基本容灾能力Redis 集群热数据缓存 日志缓冲Redis 在这套架构里承担两个职责1. 热数据缓存峰值 27000 QPS 读请求 → Redis 集群 2 主分片每片扛 ~13500 QPS → 单台 Redis 扛 10 万 QPS仍有 7 倍余量 → 未命中 Redis 的请求回落从库回填缓存 2. 日志缓冲峰值 3000 QPS 写入 → 日志/操作流水先写 Redis后台定时批量落库 → 批量合并后 MySQL 实际写入压力降到每秒 300-1000 次 → 日志数据容忍少量丢失Redis 缓冲风险可控5.5 关于双写的坑日志和业务数据的写入策略要分开不能一视同仁数据类型写入策略原因日志/流水单写 Redis → 定时批量落库日志容忍丢失优先性能业务数据先写 MySQL → 成功后更新 RedisCache-Aside业务数据不能丢MySQL 是主Redis 是缓存为什么不建议业务数据双写Redis MySQL 同时写双写的经典坑 Redis 写成功、MySQL 写失败 → 数据不一致 MySQL 写成功、Redis 写失败 → 缓存脏数据 两者都成功但时序不同 → 并发下同样会脏 政务场景对数据一致性敏感双写风险偏大。 Cache-Aside 模式以 MySQL 为准Redis 只是缓存数据源头唯一不容易出问题。5.6 机器清单角色配置数量说明API 服务8 核 16G12 台30000 QPS / 3000 每台 10冗余 2 台Redis 集群8 核 16G4 台2 主 2 从扛 2.7 万读 3000 写缓冲MySQL 主库省会8 核 32G1 台承载业务写入约 3000 QPSMySQL 从库各地市8 核 32GN 台承载本地读取按地市数量部署MySQL 备用从库8 核 32G2 台容灾热备Nginx 网关4 核 8G2 台负载均衡监控/配置/定时任务4 核 8G2 台Prometheus 调度合计23N 台容灾机房对等部署翻一倍。N 按实际地市数量取值整体通常在50-70 台范围。5.7 推演结论峰值 3 万 QPS一拖N主从 Redis 缓存/日志缓冲传统架构完全能扛。50-70 台 8 核机器覆盖容灾和冗余。这套架构本质是分布式的——跨地市主从、Redis 集群、无状态 API 层但不需要 K8s、服务网格那套运维体系。传统运维手段足以驾驭。以上为个人工程推演非实测数据。实际部署需结合真实流量验证。六、特殊场景的边界12306 属于全球独一档的超高峰值秒杀系统主从 Redis 搞不定。但 12306 靠的是内存库存、排队、异步、隔离不是云原生。云原生既不能解决秒杀冲突也不是这类系统的最优解。这是一个极端特例不能用来论证所有系统都需要云原生架构。七、宣传与神格回过头看架构的本质就是四件事拆分—— 把大问题切成小问题隔离—— 让小问题互不影响省钱—— 用最少资源办最多的事演进—— 随业务增长逐步迭代而对外宣传包装成云原生、顶尖技术、分布式神迹、高不可攀。长期宣传下形成的技术神格来自舆论与商业包装大于纯技术原创的客观差距。结语架构看场景并发看拆分先进看包装门槛看业务。