从双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 约 3000，8 核 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 → 成功后更新 Redis（Cache-Aside） | 业务数据不能丢，MySQL 是主，Redis 是缓存 |
为什么不建议业务数据双写（Redis + MySQL 同时写）？
双写的经典坑：
Redis 写成功、MySQL 写失败 → 数据不一致
MySQL 写成功、Redis 写失败 → 缓存脏数据
两者都成功但时序不同 → 并发下同样会脏
政务场景对数据一致性敏感，双写风险偏大。
Cache-Aside 模式以 MySQL 为准，Redis 只是缓存，数据源头唯一，不容易出问题。5.6 机器清单
| 角色 | 配置 | 数量 | 说明 |
|---|---|---|---|
| API 服务 | 8 核 16G | 12 台 | 30000 QPS / 3000 每台 = 10，冗余 2 台 |
| Redis 集群 | 8 核 16G | 4 台 | 2 主 2 从，扛 2.7 万读 + 3000 写缓冲 |
| MySQL 主库（省会） | 8 核 32G | 1 台 | 承载业务写入，约 3000 QPS |
| MySQL 从库（各地市） | 8 核 32G | N 台 | 承载本地读取，按地市数量部署 |
| MySQL 备用从库 | 8 核 32G | 2 台 | 容灾热备 |
| Nginx 网关 | 4 核 8G | 2 台 | 负载均衡 |
| 监控/配置/定时任务 | 4 核 8G | 2 台 | Prometheus + 调度 |
| 合计 | 23+N 台 |
容灾机房对等部署，翻一倍。N 按实际地市数量取值，整体通常在 50-70 台 范围。
5.7 推演结论
峰值 3 万 QPS，一拖N主从 + Redis 缓存/日志缓冲，传统架构完全能扛。50-70 台 8 核机器，覆盖容灾和冗余。
这套架构本质是分布式的------跨地市主从、Redis 集群、无状态 API 层，但不需要 K8s、服务网格那套运维体系。传统运维手段足以驾驭。
以上为个人工程推演，非实测数据。实际部署需结合真实流量验证。
六、特殊场景的边界
12306 属于全球独一档的超高峰值秒杀系统，主从 + Redis 搞不定。
但 12306 靠的是内存库存、排队、异步、隔离，不是云原生。云原生既不能解决秒杀冲突，也不是这类系统的最优解。
这是一个极端特例，不能用来论证"所有系统都需要云原生架构"。
七、宣传与神格
回过头看，架构的本质就是四件事：
- 拆分 ------ 把大问题切成小问题
- 隔离 ------ 让小问题互不影响
- 省钱 ------ 用最少资源办最多的事
- 演进 ------ 随业务增长逐步迭代
而对外宣传包装成：云原生、顶尖技术、分布式神迹、高不可攀。
长期宣传下形成的"技术神格"，来自舆论与商业包装，大于纯技术原创的客观差距。
结语
架构看场景，并发看拆分，先进看包装，门槛看业务。