ThinkerQAQ

NOTE

1.1 业务系统设计分析思路

1. 需求是什么 - 需求单 - 原型图 2. 为什么要做这个需求 - 用于解决什么问题 - 需求是不是可以不做 - 能不能简化下需求 3. 需求分析 理解概念需要结合系统举例子 3.1. 原有流程是怎样的 找运营或者产品演示流程 读写流程、B端C端流程 3.2. 新流程是怎样的 1. 系统中的角色

系统设计创建于 更新于 historical

这是历史学习笔记，可能存在过时或不完整的理解。

1. 需求是什么

  • 需求单
  • 原型图

2. 为什么要做这个需求

  • 用于解决什么问题
  • 需求是不是可以不做
  • 能不能简化下需求

3. 需求分析

理解概念需要结合系统举例子

3.1. 原有流程是怎样的

找运营或者产品演示流程 读写流程、B端C端流程

3.2. 新流程是怎样的

  1. 系统中的角色以及每个角色可以做什么
    • 用例图.md（关联笔记尚未公开）
  2. 每个角色做一个事情的流程是怎样的
    • 流程图.md（关联笔记尚未公开）
    • 时序图.md（关联笔记尚未公开）

3.3. QPS估算

  1. 假设DAU（日活跃用户数）为1000W，每个用户操作10次，操作时间分散在24h
  2. 那么PV（日访问量）=DAU*10=1000W*10=1亿
  3. 那么平均QPS（每秒请求量）=访问量/时长=PV/24h=1亿/(24*60*60)=1160
  4. 那么峰值QPS（每秒请求量）=平均QPS*10=1160*10=11600

3.4. 带宽估算

优化方式：压缩、分页

4. 方案设计

  • 暴露给客户端的是API接口
  • 内部通过组合各种数据组件实现
    • 数据库
    • 缓存
    • 搜索引擎
    • 消息队列

4.1. 存储设计

  • 根据功能要求、请求量、数据量、稳定性、扩展性、成本、存储模型等决定使用那种存储

  • 功能

    • Elasticsearch：复杂检索
    • MySQL：ACID事务+持久化
    • MongoDB：JSON+持久化
    • Redis：内存
    • Kafka：削峰异步解耦

  • 请求量

    • B端 or C端
    Component Reads per second Writes per second
    MySQL 10000 5000
    Redis 100000 100000
    Kafka 100000 100000
    MongoDB 20000-50000 10000-25000

  • 数据量

    Component Max effective capacity
    MySQL 3TB
    Redis 16GB-128GB
    MongoDB

  • 稳定性

    • 读写成功率，可参考服务等级协议的可用性
    • 故障切换是手动还是自动，需要多长时间，对业务的影响

  • 扩展性

    • 是否能支持快速扩容，扩容速度

  • 数据模型设计

    • 有哪些实体以及实体之间的关系
    • 数据模型.md
    • ER图.md（关联笔记尚未公开）

4.2. 接口设计

  1. 有几个操作就有几个接口
  2. 定义接口协议

4.3. 架构设计

综合考虑安全性（关联笔记尚未公开）、高并发、高可用、可维护（关联笔记尚未公开）

  1. 拆分微服务.md（关联笔记尚未公开）
  2. 画出应用架构图（关联笔记尚未公开）
  3. 画出时序图（关联笔记尚未公开）

4.4. 代码设计

类图.md（关联笔记尚未公开） 组件图.md（关联笔记尚未公开）

4.5. 核心读写链路

5. 工作量评估

  • 一个接口评估0.5-2天

6. 开发

7. 测试

功能测试、单元测试、接口测试、压力测试等 测试.md（关联笔记尚未公开）

8. 发布

  1. 服务发布Checklist
  2. 上线部署
    • 部署图.md（关联笔记尚未公开）
    • 机器数目=系统预计QPS/每台机器QPS。每台机器的QPS可参考压力测试.md（关联笔记尚未公开）

9. 运维

  1. 梳理核心链路日志和监控
  2. 常见问题定位

10. 优化

11. 总结

  1. 方案对比
  2. 遇到的问题以及怎么解决的
  3. 设计中的亮点
    • 为什么引入XXX组件
  4. 痛点梳理与改进措施
    • 请求量、数据量扩大N倍怎么处理
    • 重构.md

12. 参考