程序员笔记（104）系统设计

外向笑小鸭子 2024-01-12 14:36:30  51508 赞同 0 反对 0

分类：资源标签：运维

程序员笔记（104）系统设计

（一）系统设计中的33个黄金法则

系统设计很复杂，它需要设计者有深厚的计算机知识和专业知识，没有一种通用的设计可以适应所有业务场景。尽管如此，还是有一些比较通用的规则可以供你设计系统时参考，也能帮助你在面试中摆脱困境。

1. 对于数据密集型系统 — 考虑使用缓存。

2. 对于写入量大的系统 — 使用消息队列进行异步处理

3. 对于低延迟要求 — 考虑使用缓存和 CDN。

4. 需要原子性、一致性、隔离性、耐用性兼容数据库 — 选择 RDBMS/SQL 数据库。

5.对于非结构化数据——可以选择NoSQL数据库。

6. 拥有复杂的数据（视频、图像、文件）——选择 Blob/对象存储。

7. 复杂的计算——使用消息队列和缓存。

8. 海量数据搜索——考虑搜索索引、尝试搜索引擎。

9. 扩展 SQL 数据库 — 实施数据库分片。

10. 高可用性、性能和吞吐量 — 使用负载均衡器。

11. 全球数据交付——考虑使用 CDN。

12.图形数据（具有节点、边和关系的数据）——利用图形数据库。

13. 扩展各种组件——实现水平扩展。

14. 高性能数据库查询——使用数据库索引。

15.批量作业处理——考虑批处理和消息队列。

16.服务器负载管理和防止 DOS 攻击 - 使用速率限制器。

17. 微服务架构——使用 API 网关。

18. 针对单点故障——实施冗余。

19.为了容错性和持久性——实施数据复制。

20. 对于用户到用户的快速通信 — 使用 Websockets。

21.分布式系统中的故障检测——实现心跳。

22. 数据完整性——使用校验和算法。

23. 高效的服务器扩展——一致性哈希。

24. 去中心化数据传输——考虑 Gossip 协议。

25. 基于位置的功能 — 使用四叉树、Geohash 等。

26. 避免特定的技术名称 — 使用通用术语。

27. 高可用性和一致性的权衡——最终一致性。

28. 对于IP解析和域名查询——DNS。

29. 处理网络请求中的大数据——实施分页。

30. 缓存删除策略 — 首选 LRU（最近最少使用）缓存。

31. 处理流量高峰：实现自动扩展以动态管理资源

32. 审计跟踪 — 考虑使用数据湖

33. 处理高并发连接 — 使用连接池并考虑使用 Protobuf 来最小化数据

（二）系统设计的十大原则

原则一：关注于真正的收益而不是技术本身

系统架构最重要的是「总体收益」。如果不说收益，只是为了技术而技术，就没有任何意义。

就收益而言，我觉得下面这几点是非常重要的：

是否可以降低技术门槛，加快整个团队的开发和发布速度。

是否可以让整个系统运行得更为稳定。

是否可以通过简化、自动化，降低成本。

原则二：以对外服务的水平为视角，而不是以资源和技术为视角

随着今天各种系统的日益复杂，整个组织、架构的优化，已经不能通过调整单个人员、团队的分工，或者修改单个组成部分，就能够有很大提升的了。其需要有一种自顶向下的，整体规划，统一设计的方式，才能做到整体的提升。

原则三：选择最主流和成熟的技术

尽可能使用更为成熟、更为工业化的技术栈，而不是自己熟悉的技术栈。所谓工业化的技术栈，你可以看看大多数公司使用的技术栈，比如：互联网、金融、电信等等。大公司会有更多的技术投入，也需要更大规模的生产，所以，他们使用的技术通常来说都是比较工业化的。

原则四：完备性比性能更重要

我发现有些公司设计架构的时候，首要考虑的是性能是否能够撑得住多大的流量，而不是考虑系统的完备性和扩展性。

应当使用最科学严谨的技术模型为主，并以不严谨的模型作为补充。这里的原则就是所谓的“先紧后松”，一开始紧了，你可以慢慢松，但是开始松了，以后你想紧再也紧不过来了。

原则五：制定并遵循服从标准、规范和最佳实践

只有服从标准，才能有更好的扩展性。比如：我经常见到很多公司的系统，既没有服从业界标准，也没有形成自己公司的标准，感觉就像一群乌合之众。

原则六：重视架构的可扩展性和可运维性

很多技术人员只考虑当下，从来不考虑系统未来的扩展性和可运维性，这就是所谓的“管生不管养”。

架构、软件并不是写好就完，而是需要不断的修改、升级、维护。事实上，80%的软件成本都是用在维护上。所以，如何提高系统的可扩展性，使其便于运维，非常重要。

原则七：不要迁就老系统的「技术债」

有一家公司，架构和技术选型基本都搞错了，使用错误的模型构建系统，导致整个系统的性能非常之差，也才几千万条数据，系统就慢到不可忍受。

但他们想的不是“还债”，即解决这些问题，而是要把楼修的更高，上更多的系统——他们觉得现有的系统挺好，性能问题的原因是他们没一个大数据平台，所以要建大数据平台。

与其花大力气迁就技术债务，不如直接还技术债，即“长疼不如短痛”。

建设没有技术债的“新城区”，并通过“防腐层 ”的架构模型，不让技术债侵入“新城区”。

崔博注释：在发展增量的同时，维护好存量，甚至更加重要。对于社会来说，存量就是医疗（建设更多的医院、护理场所和机构）、社会保障（建设更好的安全网）和养老设施等等。

同样，在技术领域，在发展增量（不断推出各种新功能、新模式）的同时，我们也要注意维护存量，即加强网络服务的稳定性和安全性。否则，功能越强大、服务越广泛，受到攻击之后反而损失也会越大。还是那句老话，我们应该在晴天修屋顶，而不是等到台风来了再修。

原则八：不要依赖自己的经验，要依赖于数据和学习

所有的技术手段都有其适用的场景，不是放之四海而皆准的，因此，针对每一个问题，都需要在调研之后，才能做出决定。这跟医生看病是一样的，确诊病因不能靠经验，还是要靠诊断数据。在科学面前，所有的经验都是靠不住的。

原则九：千万要小心 X – Y 问题，要追问原始需求

对于 X-Y 问题，也就是说，用户为了解决 X问题，他觉得用 Y 可以解，于是问我 Y 怎么解决。

结果分析到最后，发现原来要解决的是 X 问题，这个时候最好的解决方案不是 Y，而是 Z。这种 X-Y 问题太多太多了。

原则十：激进胜于保守，创新与实用并不冲突

我对技术的态度是比较激进的，但是，所谓的激进并不是盲目尝试，也不是见新技术就上，而是积极拥抱会改变未来的新技术。

另外，我也尊重保守的决定，这里面没有对和错。

如果您发现该资源为电子书等存在侵权的资源或对该资源描述不正确等，可点击“私信”按钮向作者进行反馈；如作者无回复可进行平台仲裁，我们会在第一时间进行处理！

评价 0 条

程序员笔记 （104）系统设计

相关资源

关注我们

程序员笔记（104）系统设计