把每个模块用 3-4 张图提炼精髓，配以少量的文字描述和个人体会。

一、模块一（架构定义）

1.1 4R 架构

1.2 架构设计环

备选方案做 360 度环评：

例如：消息队列的方案

1.3 微信业务架构图

参考答案：

我的作业：

付款码和收款码不是业务，改成付款和收款更合适。

二、模块二（架构设计关键点）

2.1 架构设计复杂度模型

2.2 可扩展复杂度模型

主要手段是拆分和封装。

鸡蛋篮子第一法则（拆分法则）：如果一个篮子数不清，拆分到多个篮子再数！

2.3 高性能复杂度模型

单机高性能应对办法：

单机高性能复杂度应对之道：各种编程技巧，上面列出的只是常见的，不是只能用这些！

集群高性能设计：

鸡蛋篮子理论第二法则（叠加法则）：如果一个篮子装不下你的鸡蛋，用多个篮子！

2.4 高可用复杂度模型

鸡蛋篮子理论第三法则（冗余法则）：不要把所有鸡蛋装在一个篮子，放到多个篮子！

2.5 如何设计更好的架构

2.6 复杂度总体分析（微信红包）

应用案例（调查问卷）：

三、模块三（如何保证设计出合理的架构）

架构师的核心职责是消除不确定性和降低复杂性。

3.1 机构设计环

3.2 架构设计前期

干系人分析很重要，要排优先级。

3.3 架构设计中期

备选方案是重点，360 度环评。

3.4 架构设计后期

输出架构设计文档

3.5 架构设计模板

参考地址：https://xie.infoq.cn/article/a1c01e8f55c81b36a787f9f5b

四、模块四（如何设计业务高性能可存储架构？）

4.1 常见存储系统分类

4.2 存储架构选择逻辑

4.3 常见存储架构分析

四个步骤：

1、理解技术本质

2、明确部署架构

3、研究数据模型

4、模拟业务场景

五、模块五（如何设计业务高性能可用计算架构）

5.1 缓存设计框架

最佳实践：缓存一定要设置过期时间。可采用过期更新、定期更新、主动更新策略。

5.2 多级缓存架构

• 是否所有的应用都要按照这个多级缓存架构设计？根据性能需求和架构的复杂度去决定。

• 先删除缓存再写存储系统（推荐）。

5.3 缓存架构三类问题

1. 缓存穿透

• 空值缓存

• 缓存当前数据

• 缓存预热

• 随机失效

2.缓存雪崩

• 更新锁

• 后台更新

3.缓存热点

• 多副本缓存

六、模块六（如何设计业务的微服务架构）

6.1 SOA 与微服务

6.2 微服务基础设施优先级

6.3 微服务架构模式对比

6.4 如何选择微服务架构

java 统一技术栈下推荐使用 Spring Cloud。

6.5 微服务拆分技巧

单体架构微服务化，需要逐步落地。

七、模块七（如何设计业务异地多活架构）

7.1 FEMA 的维度

7.2 业务灾备架构对别

7.3 异地多活架构对比模式

异地多活三个原则：

1. 只保证核心业务

2. 只能做到最终一致

3. 只能保证绝大部分用户

7.4 异地多活设计步骤

数据同步技巧

八、模块八（如何设计贴合业务的高性能中间件系统）

8.1 三类网络模型对比

8.2 zk 集群模式对比

8.3 各个架构的分析对比

九、模块九（十万级到亿级用户 IM 架构设计）

8.1、代码重构 US 架构重构

架构重构手段:增、删、改、拆、合。

8.2 架构重构 US 架构演进

8.3 十万到亿级的 IM 架构设计技巧

十万：

1. 存储：mysql 主备；redis 主备。

2. 性能估算：聊天的 TPS1000 左右，不高。

3. 负载均衡：nginx + 多个业务服务器部署。

4. 缓存：容器内缓存+分布式缓存。

5. 其它：同城灾备。

百万：

1. 存储：主备。缓存：分片集群。

2. 性能估算:消息读取量：1600 万 * 5（每个群最多 5 人） = 8000 万

QPS。

3.负载均衡：nginx + 多个业务服务器部署（增加服务器数量）。

4.缓存：容器内缓存+分布式缓存

6.其它：微服务架构（5 个服务），增加微服务的基础设施。同城灾备。

千万（面向技术）：

1. 总体思路变化，划分业务域。

2. 负载均衡：（DNS + F5 + Nginx）

3. 缓存：分布式缓存+应用容易缓存。

4. 其它：同城双活。

5. 
   

亿

1. 总体架构设计思路

2. 

3. 其它：

降低成本设计；定制化；自建。

十、模块十（架构师如何快速成长）

架构=取舍+判断+创新

10.1 常用学习方法

海绵学习法：充分利用自己的碎片化的学习时间。

链式学习法：先深入学一个，然后横向扩展。

比较学习法：相似技术比较学习。

Play 学习法：搭建学习环境。

环式学习法：按照技术或者业务的维度，构建一个完整的闭环过程，将多个领域的

“鱼”一网打尽。

5W1H8C1D 方法：

【作用】

1. 按照 5W 去分析，能够有效避免需求本身是错误的情况；

2. 5W1H8C 是重要的设计输入信息，会影响设计。

【适用范围】

1. P5/P6/P7 技术人员开发的时候理解业务需求；

2. 架构设计的时候理解核心需求。