本文永久链接 – https://tonybai.com/2025/08/26/good-system-design 大家好，我是Tony Bai。 在技术圈，我们常常被各种“炫技式”的系统设计建议所包围。从入门级的“你一定没听说过队列吧？”到专家级的“在数据库里存布尔值简直是灾难”，这些建议要么过于肤浅，要么过于精巧，往往脱离了大多数工程实践的真实上下文。就连《设计数据密集型应用》这样的经典之作，虽然深刻，却也可能与我们日常面对的大多数问题有些距离。 那么，究竟什么是好的系统设计？如果说软件设计是如何组织代码，那么系统设计就是如何组织服务。其基本元素不再是变量和函数，而是应用服务器、数据库、缓存、队列、事件总线和代理。 近日，一篇名为《我所知道的关于优秀系统设计的一切》的文章在工程师社群中引发了广泛共鸣。其核心观点让人耳目一新：优秀的系统设计，往往看起来平平无奇，甚至有些“无聊”。这种“无聊”，恰恰是系统长期稳定、易于维护的标志。 在本文中，我就和大家一起深入这篇文章的核心思想，看看这位作者所说的“无聊即可靠”的系统设计法则究竟都是哪些！ 识别优秀设计：于无声处听惊雷 优秀的设计是什么样的？它往往是“无感的”。当你发现一个功能实现起来比预想的要简单，或者你几乎从不需要去关心系统的某个部分，因为它总是在默默地、可靠地工作时，你就身处一个优秀的设计之中。 这引出了一个悖论：优秀的设计是自我掩饰的，而糟糕的设计往往看起来更令人印象深刻。一个充斥着分布式共识、多种事件驱动模式、CQRS 等“高级”概念的系统，常常让我们心生警惕。这背后，要么是为了弥补某个根本性的错误决策，要么就是赤裸裸的过度设计。 许多工程师看到复杂的系统，会惊叹：“这里发生了好多系统设计！” 但事实恰恰相反，复杂通常是优秀设计缺位的体现。当然，有些系统的复杂性是业务本身带来的，它们不可避免。但一个能正常工作的复杂系统，永远是从一个能正常工作的简单系统演化而来的。从零开始构建一个复杂系统，几乎注定会走向失败。 这与 Go 语言的哲学高度契合。Go 本身就是一门“无聊”的语言，它刻意回避了许多其他语言中的复杂特性，以换取无与伦比的简洁性、可靠性和工程效率。同样，优秀的 Go 系统设计，也应该追求这种“无聊”的可靠性。 状态与无状态：系统设计的核心难题 软件工程中最困难的部分，永远是状态管理。只要你需要在任何时间段内存储任何信息，一系列棘手的决策就会接踵而至。相反，不存储任何信息的应用被称为“无状态”的。 法则一：最大限度地减少有状态组件。 虽然我们应该最小化所有组件，但有状态的组件尤其危险，因为它们会进入“坏的状态”。一个无状态的服务（比如 PDF 转 HTML 服务）可以被容器编排系统（如 Kubernetes）轻易地杀死和重启，从而实现故障自愈。但一个有状态的服务（如数据库）却不能。如果数据库中出现一条格式错误的“脏数据”导致应用崩溃，你就必须手动介入修复。 在实践中，这意味着我们应该努力将系统划分成两种角色： 1. 少数的有状态服务：它们负责与数据库等持久化存储打交道，是状态的“守护者”。 2. 大量的无状态服务：它们负责处理业务逻辑、计算等任务，本身不存储任何持久化状态。 要严格避免让五个不同的服务去写同一张数据库表。更好的模式是，让其中四个服务通过 API 请求或发布事件的方式，与那个唯一的“状态守护者”服务通信，将所有写逻辑都封装在守护者服务内部。对于读逻辑，虽然可以稍微放宽，但将读操作也收敛到一个服务中，依然是更优的选择，只是有时为了性能，我们会容忍一些服务直接读取数据库副本。 数据库：状态的心脏 既然状态管理是核心，那么承载状态的数据库自然就是系统的心脏。以下是围绕关系型数据库（如 PostgreSQL）的一些关键实践。 法则二：精心设计“刚刚好”的 Schema 和索引。 Schema 设计：Schema 设计需要在灵活性和规范性之间找到平衡。一旦数据量达到百万级别，修改 Schema 将会是一场噩梦。但如果过度追求灵活性，例如将所有数据都塞进一个 JSON 字段，或者使用 EAV（实体-属性-值）模型，虽然初期开发快，但会将巨大的复杂性和潜在的性能问题转移到应用层代码中。一个好的标准是：你的表结构应该能让一个新人大致读懂应用的业务模型。 索引：索引是数据库性能的命脉。要根据最常见的查询模式来创建索引。例如，如果你经常按 WHERE user_id [...]