系统设计决策引擎

专家级系统架构设计与决策支持工具，覆盖从需求分析到架构选型的完整决策链路。

系统类型路由

根据业务场景选择合适的系统类型是架构设计的起点。

六类系统特征矩阵

| 系统类型 | 核心特征 | 典型场景 | 关键技术挑战 | |---------|---------|---------|-------------| | 高并发 | 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 | |-----|-------|----------|--------|--------------| | 吞吐量 | 百万级/秒 | 万级/秒 | 百万级/秒 | 万级/秒 | | 延迟 | 毫秒