# 系统设计决策引擎 专家级系统架构设计与决策支持工具，覆盖从需求分析到架构选型的完整决策链路。 ## 系统类型路由 根据业务场景选择合适的系统类型是架构设计的起点。 ### 六类系统特征矩阵 | 系统类型 | 核心特征 | 典型场景 | 关键技术挑战 | |---------|---------|---------|-------------| | **高并发** | QPS>10万/秒 | 电商秒杀、春晚红包 | 流量削峰、连接池管理、热点数据 | | **高可用** | SLA>99.99% | 金融支付、电信核心 | 多活容灾、故障检测、自动恢复 | | **数据密集** | PB级存储、万亿级记录 | 大数据分析、搜索引擎 | 数据分片、冷热分离、查询优化 | | **计算密集** | CPU密集、长计算 | AI推理、科学计算 | 批处理框架、异构计算、GPU调度 | | **实时系统** | 毫秒级延迟 | 物联网、游戏服 | 事件驱动、流处理、低延迟网络 | | **离线系统** | 批处理、T+1 | 数据仓库、报表 | 任务调度、资源弹性、依赖管理 | ### 路由决策树 ``` 输入需求分析 │ ▼ QPS > 10万？ ──是──▶ 高并发优先 │否 ▼ SLA要求 > 99.9%？ ──是──▶ 高可用优先 │否 ▼ 数据量 > 10TB？ ──是──▶ 数据密集优先 │否 ▼ 延迟要求 < 100ms？ ──是──▶ 实时系统优先 │否 ▼ 计算负载 > 80% CPU？ ──是──▶ 计算密集优先 │否 ▼ 离线分析/报表场景 ──▶ 离线系统优先 ``` ## 架构风格决策 ### 架构风格对比 | 风格 | 适用场景 | 优势 | 劣势 | 团队要求 | |-----|---------|-----|-----|---------| | **单体** | 初创/小规模 | 简单、部署快、调试方便 | 扩展难、技术锁定 | 低 | | **微服务** | 中大型、业务复杂 | 独立部署、技术多样 | 复杂度高、运维难 | 高 | | **事件驱动** | 异步处理、松耦合 | 解耦、扩展性好 | 一致性难、调试复杂 | 中高 | | **Serverless** | 边缘计算、间歇负载 | 成本低、免运维 | 冷启动、厂商锁定 | 中 | | **CQRS** | 读写分离、复杂查询 | 性能优化、灵活扩展 | 复杂度高 | 高 | | **六边形** | 业务核心稳定 | 可测试、易替换 | 前期设计成本高 | 中高 | ### 架构演进路径 ``` 阶段1: 单体架构 (MVP期) │ 痛点: 代码膨胀、部署冲突 ▼ 阶段2: 模块化单体 (成长期) │ 痛点: 数据库成为瓶颈 ▼ 阶段3: 应用集群 + 主从数据库 (增长期) │ 痛点: 单库性能上限 ▼ 阶段4: 业务拆分 + 读写分离 (规模化) │ 痛点: 微服务管理成本 ▼ 阶段5: 微服务 + 容器化 (成熟期) ``` ### 选择决策矩阵 ``` 维度1: 团队规模 <5人 → 单体/模块化单体 5-20人 → 渐进式微服务 >20人 → 微服务/领域驱动 维度2: 业务复杂度 简单 → 单体 中等 → 模块化/CQRS 复杂 → 微服务/事件驱动 维度3: 变更频率 高 → 微服务(独立部署) 中 → 模块化单体 低 → 单体 维度4: 性能要求 高并发 → 水平扩展优先 低延迟 → 就近计算/缓存优先 ``` ## 分布式系统设计 ### CAP 定理应用 ``` Consistency (一致性) /\ / \ / \ / P \ / ↖ \ / C \ ────────────── Partition Tolerance (分区容错) 三选二: CA → 单体/主从 CP → Zookeeper/etcd AP → Cassandra/DynamoDB ``` **实践原则**: - 网络分区不可避免，CP/AP 二选一 - 强一致性场景选 CP（金融、订单） - 高可用场景选 AP（社交、推荐） - 多数业务可接受最终一致性 ### BASE 理论 - **Basically Available**: 降级非核心功能，保证核心可用 - **Soft state**: 允许中间状态存在 - **Eventually consistent**: 追求最终一致 ### 一致性模型选择 | 模型 | 延迟 | 可用性 | 适用场景 | |-----|-----|-------|---------| | 线性一致性 | 高 | 低 | 分布式锁、唯一性约束 | | 顺序一致性 | 中 | 中 | 多副本写、消息队列 | | 因果一致性 | 低 | 高 | 社交feed、评论系统 | | 最终一致性 | 最低 | 最高 | CDN、缓存、搜索索引 | ### 数据分区策略 **哈希分区** ``` partition_key = hash(key) % node_count 优点: 均匀分布 缺点: 扩容需重分配 适用: user_id、order_id ``` **范围分区** ``` partition_key = [start, end] range 优点: 范围查询高效 缺点: 可能热点 适用: 时间序列、地理位置 ``` **一致性哈希** ``` ┌─────┐ ┌───▶│Node1│◀───┐ │ └─────┘ │ ┌─────┐ │ │ ┌─────┐ ───▶│哈希环│──┼──────────────┼─▶│Node3│ └─────┘ │ │ └─────┘ │ ┌─────┐ │ └───▶│Node2│◀───┘ └─────┘ 优点: 扩容影响小 ``` ### 数据复制策略 | 策略 | 延迟 | 一致性 | 容灾 | |-----|-----|-------|-----| | 主从同步 | 低 | 强一致 | 单点 | | 主从异步 | 最低 | 最终一致 | 弱 | | 半同步 | 中 | 强一致+容灾 | 中 | | Raft | 中高 | 强一致 | 强 | | Multi-Paxos | 高 | 强一致 | 强 | ### 共识算法选型 ``` 场景: 配置管理/服务发现 └─→ ZooKeeper / etcd (Raft) 场景: 分布式锁 └─→ etcd (Lease + TTL) 场景: 全球部署/强一致 └─→ CockroachDB / TiKV (Multi-Raft) 场景: 区块链/多方信任 └─→ PBFT / PoS ``` ## 缓存策略 ### 缓存架构模式 **旁路缓存 (Cache-Aside)** ``` 读: Cache → Hit → 返回 Cache → Miss → DB读取 → 写入Cache → 返回 写: 更新DB → 删除Cache (不是更新Cache) ``` **读写穿透 (Read/Write Through)** ``` 应用只操作Cache，Cache内部处理DB同步 优点: 应用层简单 缺点: Cache压力大 ``` **异步写入 (Write Behind)** ``` 写 → Cache → 异步批量写DB 优点: 写入性能高 缺点: 可能丢数据 ``` ### 缓存问题诊断与应对 **缓存穿透**: 查询不存在的数据 ``` 症状: DB压力异常增大 原因: 恶意请求/数据不存在 方案: 1. 布隆过滤器 (存在性判断) 2. 空值缓存 (短TTL) 3. 请求合法性校验 ``` **缓存击穿**: 热点key过期瞬间大量请求 ``` 症状: DB瞬间压力飙升 原因: 热点key过期 + 并发访问 方案: 1. 互斥锁 (setnx) 2. 永不过期 + 异步更新 3. 热点数据永不过期 ``` **缓存雪崩**: 大量key同时过期 ``` 症状: DB压力持续增加 原因: 批量过期/Redis宕机 方案: 1. TTL随机化 (±10%) 2. 多级缓存 (L1本地+L2分布式) 3. Redis高可用集群 4. 熔断降级预案 ``` ### 多级缓存架构 ``` ┌─────────┐ ┌─────────┐ ┌─────────┐ │ 浏览器 │ │ CDN │ │ L1缓存 │ │ LocalStorage│ │ 边缘节点 │ │ (本地) │ │ TTL:分钟 │ │ TTL:小时 │ │ TTL:秒 │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────────┐ │ L2缓存 (分布式) │ │ Redis Cluster │ │ TTL: 可配置 │ └────────────────────┬────────────────┘ │ ▼ ┌─────────────────────────────────────┐ │ 数据库层 │ │ MySQL / PostgreSQL │ └─────────────────────────────────────┘ ``` ### 缓存容量规划 ``` 热点数据估算: - 热点商品: 5% SKU 占 80% 访问 - 用户数据: 登录用户 20% 占 90% 访问 容量计算: 单key大小: 1KB - 100KB QPS: 10万 缓存命中率: 95% 所需容量 = 单key大小 × 热点key数 × 副本系数 Redis集群规划: - 单节点内存: 64GB - 副本数: 1主1从 或 1主2从 - 分片数: 3-6 (根据容量需求) ``` ## 消息队列选型 ### 主流MQ对比 | 特性 | Kafka | RabbitMQ | Pulsar | Redis Stream | |-----|-------|----------|--------|--------------| | 吞吐量 | 百万级/秒 | 万级/秒 | 百万级/秒 | 万级/秒 | | 延迟 | 毫秒