System Design Engine

系统设计决策引擎

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

系统类型路由

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

六类系统特征矩阵

路由决策树

输入需求分析
    │
    ▼
QPS > 10万？ ──是──▶ 高并发优先
    │否
    ▼
SLA要求 > 99.9%？ ──是──▶ 高可用优先
    │否
    ▼
数据量 > 10TB？ ──是──▶ 数据密集优先
    │否
    ▼
延迟要求 < 100ms？ ──是──▶ 实时系统优先
    │否
    ▼
计算负载 > 80% CPU？ ──是──▶ 计算密集优先
    │否
    ▼
离线分析/报表场景 ──▶ 离线系统优先

架构风格决策

架构风格对比

架构演进路径

阶段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: 追求最终一致

一致性模型选择

数据分区策略

哈希分区

partition_key = hash(key) % node_count
优点: 均匀分布
缺点: 扩容需重分配
适用: user_id、order_id

范围分区

partition_key = [start, end] range
优点: 范围查询高效
缺点: 可能热点
适用: 时间序列、地理位置

一致性哈希

                  ┌─────┐
             ┌───▶│Node1│◀───┐
             │    └─────┘    │
    ┌─────┐  │              │  ┌─────┐
───▶│哈希环│──┼──────────────┼─▶│Node3│
    └─────┘  │              │  └─────┘
             │    ┌─────┐    │
             └───▶│Node2│◀───┘
                  └─────┘
优点: 扩容影响小

数据复制策略

共识算法选型

场景: 配置管理/服务发现
  └─→ 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对比