这是我参与「第五届青训营 」伴学笔记创作活动的第 10 天
体统设计方法论
-
如何做系统设计
-
4S分析法
- 场景分析：什么系统，需要哪些功能，多大的并发量。
- 存储设计：数据如何组织，sql存储，nosql存储。
- 服务设计：业务功能实现和逻辑整合。
- 可拓展性：解决设计缺陷，提高鲁棒性、拓展性。
-
系统设计的定义
| 系统 | 设计 |
|---|---|
| 关联的个体 | 设想和计划 |
| 规则运作 | 目的 |
| 组成工作的整体 | 过程安排 |
系统设计流程
- 场景分析
- 储存数据
- 服务设计
- 可扩展性
发现瓶颈
- 火焰图分析（代码）
- 链路追踪（服务耗时时间大）
- 性能测试（系统性能不足）
如何保证可用性和稳定性
| 链路梳理 | 可观测性 | 全链路测试 | 稳定性控制 | 容灾演练 |
|---|---|---|---|---|
| 核心链路 | 链路追踪 | 压力测试 | 系统限流 | 混沌工程 |
| 流量漏斗 | 核心监控 | 负载测试 | 业务兜底 | 应急手册 |
| 强弱依赖 | 业务报警 | 容量测试 | 熔断降级 | 容灾预案 |
秒杀的挑战性
- 资源有限性
- 反欺诈
- 高性能
- 防止超卖
- 流量管控
- 扩展性
- 鲁棒性
电商秒杀业务
4S分析
-
场景
-
功能
- 秒杀活动发布
- 秒杀商品详情
- 秒杀下单
-
并发
- 万人参与秒杀
- QPS 1W+
- TPS 1K+
-
子服务：
- 用户
- 风控
- 活动
- 订单
基础组件：
- ID生成器
- 缓存组件
- MQ组件
- 限流组件
2.后编译
后编译指的是应用依赖的NPM包，不需要在发布前编译，而是随着应用编译打包的时候一块编译。
背景
使用webpack+babel开发应用越来越多，而且一般都是通过NPM进行包管理的，这样依赖包越来越多，这些依赖包也是使用ES6+开发的，所以每个包都需要编译才能发布，这样编译后代码中往往包含很多编译代码，为了消除这部分冗余，推荐大家使用后编译。
后编译优点：
（1）公共的依赖可以实现共用，只此一份，重要的是只编译一次
（2）babel转换API部分的代码只有一份
（3）不用每个编译包都需要配置打包环节，甚至可以直接源码级别发布
后编译缺点：
（1）主应用地babel配置需要能兼容依赖包的babel配置
（2）依赖包不能使用alias、不能方便地使用DefinePlugin（可以经过一次简单编译，但是不做babel处理）
（3）应用编译时间变长
如果应用使用的是 webpack 2+，则默认走后编译，而如果使用的 webpack 1.x 则默认使用的是编译后内容
