Lesson 4 分布式系统架构 心得笔记

大型互联网应用系统重点要考虑高性能、高可用、可伸缩、可扩展以及安全。



本章的目标：

1. 理解高并发系统的历史演化过程

2. 理解高并发系统的架构模式

3. 理解高并发系统架构的常用技术解决方案

架构工作中的痛点：

1. 对大规模高并发系统的整体架构缺乏宏观的认知

2. 对大规模高并发系统的技术挑战缺乏直观认知和知识背景

通过学习掌握的核心能力：

1. 使高并发系统架构知识成为自己的常识，并本能地应用到自己的架构实践中。

2. 训练系统架构设计时平衡选择技术方案的能力。

这次详细内容如下：

1. 系统架构概述：高并发系统架构面临怎样的挑战？

2. 高并发挑战

3. 高可用挑战

4. 安全性挑战

5. 快速迭代的挑战

6. 垂直伸缩与水平伸缩的策略选择

7. 系统架构体系：高并发系统经历了怎样的演化历程？

8. 早期互联网系统架构

9. 高并发系统架构的演化历程

10. 互联网企业的技术思想是如何形成的

11. 系统架构模式概述：系统架构设计需要关注哪些方面？

12. 高性能架构模式

13. 高可用架构模式

14. 可伸缩架构模式

15. 可扩展架构模式

16. 安全架构模式

17. 分布式技术体系：一个大规模分布式系统架构包含了哪些技术？

18. 前端架构技术体系

19. 服务端架构技术体系

20. 存储架构技术体系

21. 监控与运维技术体系

22. 大数据技术体系

23. 案例：维基百科架构设计案例分析：20人团队如何开发、运维全球第六大互联网站？

24. 维基百科业务背景与技术特点分析

25. 维基百科的整体系统架构分析

26. 维基百科的高性能架构分析

27. 案例：淘宝架构演化案例分析：为什么说淘宝最初也很low？

28. 淘宝业务变迁历史分析

29. 淘宝早期的几次重要技术架构重构分析



架构不是一成不变的。架构师根据业务规模的发展而进行演进的。并不是所有的系统都需要进行微服务拆分的。微服务拆分会增加了系统的复杂性。如果是一个简单的系统，用户量很少，没有高并发，小型公司内部使用系统，好比公司内部生产事故报告系统，单体架构就可以搞定，没必要去拆分成微服务架构。如果说运维是地基，那么框架就是承重墙。盖房子是先打地基，再建承重墙，最后才垒砖，所以中间件的搭建和引进是建设高可用、高性能、易扩展、可伸缩的大中型系统的前提 。先总结到这里吧 到时候在慢慢补充