从0到1: 如何让system自己design

楼主在各个网站各个帖子里学了不少system design的套路，但不管是用来mock还是真正面试的时候总是感觉在生搬硬套，每次都要在脑子里疯狂recall“下一步是什么来着”，跟面试官对话的时候也不免带出“Let‘s list out the non-functional requirements”这种尴尬的台词。

虽然“熟读唐诗三百首，不会作诗也会吟”，但是“知其然更要知其所以然”。我还是相信通过（阅读-模仿-总结）加不断重复来达到内化是必经之路，可问题是这些套路也不是什么公理。网上很多教程之所以看过又忘，就在于大多直接给个template就jump right in了。可是他们的套路和框架是怎么来的？如何在不记忆Step123的时候也能推动system一步一步自己design或者说develop？

我不是diss现有的这些框架和模版，只是不想让自己对SD的理解起始于别人给的一系列条条框框。
我想知道：如果是我，从0开始，不靠记那些steps，如何靠自己对SD本身这个概念的理解，让system自己被design出来。

让我从系统是什么开始。
1. 什么是system
wikipedia：系统（英语：system）泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体
—> 这里的重点是“有关联的个体”和“某种规则”，也就是说，一旦确定了objects和interaction rules，系统也就形成了。
2. 什么是计算机系统
《计算机体系结构基础》中给出的冯·诺依曼结构：计算机由存储器、运算器、控制器、输入设备和输出设备五部分组成
—> 用更SD的话来说，前三个就是DB，compute service和coordinator，后两个就是API
—> 进一步简化，计算机系统就是一个用来跟环境交互，然后compute和store data的黑箱

因此，面对一个SD问题，宏观层面上定义一个system，我们需要给出以下信息：
- out of the system：输入什么？输出什么？怎么输入输出？（system <--- data ---> env）
- inside the system：谁来计算？谁来储存？要计算什么？要存储什么？怎么计算？算好了怎么存？（system component <--- data ---> system component）

但是在最一开始，我们都不用想那么细。只需要想两句话：
- it computes data
- it stores data

现实世界的系统也都是这样A does B的模式，其中A是上面提到的system里面的objects，而B是看不见摸不着的transact的对象（信息，数据，能量etc）。随便举个其他系统的例子，我们人吃了东西进去，转化（compute）为可利用形式的能量（data），要么就新陈代谢用掉了（进一步compute），要么就拿来长身体了（store）。
SD的系统也一样。网上的套路里的Functional Requirements，其实就是套了个壳，问你上面这两句话。

举例，设计一个web crawler，Alex Xu书里给的Functional Requirements：
1. Given a set of URLs, download all the web pages addressed by the URLs.
2. Extract URLs from these web pages
3. Add new URLs to the list of URLs to be downloaded

但是当我们就把它当作一个可以compute和store data的black box，我们可以从更简单的角度切入：进盒子的data我们compute和store，然后让它出盒子。
1. compute input URL into (output URLs + output webpages)
2. store (output URLs) + (output webpages)

compute，store，data，这就是一切的起点。

如果有帮助请加大米，后续还有关于nonfunctional requirments如何组织，以及high level和deep dive时如何三维思考的想法想分享出来。欢迎大家反馈。

补充内容 (2025-05-22 03:42 +08:00):

第二篇已发：https://www.1point3acres.com/bbs/thread-1129845-1-1.html

很有想法但不多，用抽象的概念模型可以描述任何一个系统，都可以统称 data in vs data out. 但具体到每一个例子应用场景是没什么可以生搬硬套的。
parking lot vs opentable vs ticket master，你当然可以说本质都是reservation system，但是用户体量，实际应用场景，真的是大同小异吗？
好比让你设计一个交通路段，你说这里可以做高架桥，高速路，红绿灯ai优化，hov车道等。
实际上一个yield sign或者4面停牌就解决的事情。

违规用户-58E9 发表于 2025-05-20 09:52:00
很有想法但不多，用抽象的概念模型可以描述任何一个系统，都可以统称 data in vs data out. 但具体到每一个例子应用场景是没什么可以生搬硬套的。

“没有什么可以生搬硬套的” 非常对！ 现实生活中的系统设计跟SD答题是不一样的。
像你说的很多事情其实从更高层次，或者说从“第一性原理”来思考，会有更简单直观的解决方法，甚至用不到什么复杂系统。但是如果在计算机系统这个层面， black box+data io就是最基础的模型。

另外你说的“是否真的大同小异”的例子，也已经落在系统的具象实现了。

我这第一篇是最普适的抽象层面，还没有进入具体分析的阶段。脱实向虚才能由虚入实。归纳出一般规律，有助于后续思路的展开。

讲的对！
我是最近才开始面SD的，和公司里写design doc不一样、感觉就是套路满满的背component然后组装到一起。

其实大家也知道工作里写arch 或者rfc就像楼主说的，应该是什么data in 什么data out，而不是以来就functional non-functional。 可是现在面试sd都这样了，好几个面试官都直接上来说按这个格式来答题，也不知道什么时候新成这样的套路了，反正一小时面试，估计大家也不在乎你真的具体多懂。

就按应用kafka这个，我当时在做新的service，光设计topic，partition和msg key 还有register都用了好几个sprint更不用说后面的impl和测试了，但是sd面试里也不怎么太问这些，因为也不可能人人都有机会接触到每一个module。

实皮果 发表于 2025-05-20 10:52:49
讲的对！
我是最近才开始面SD的，和公司里写design doc不一样、感觉就是套路满满的背component然后组装到一起。
其实大家也知道工作里写arch

哈哈SD确实是八股。否则状元文章早进语文课本了。

我还有些关于怎么组织components的想法，无关套路，也是类似这一篇里的原则性的思路。 如果有用的话我就写出来。

cruxylem 发表于 2025-05-20 11:19:30
哈哈SD确实是八股。否则状元文章早进语文课本了。
我还有些关于怎么组织components的想法，无关套路，也是类似这一篇里的原则性的思路。 如果有用的话我就写

好呀！ 求分享

违规用户-58E9 发表于 2025-5-20 09:52
很有想法但不多，用抽象的概念模型可以描述任何一个系统，都可以统称 data in vs data out. 但具体到每一个 ...

有道理，但不多。

你这其实就是把‘具体差异’无限放大，好像只要换个场景就能彻底否定抽象。问题在于，如果没有抽象层次的统一，parking lot / OpenTable / Ticketmaster 就只能是三个孤立的案例故事，而不是放在同一套方法论框架里去思考。

你举的交通例子正好说明问题：你当然可以反复强调‘这个路口只要一个 yield sign 就够了’，但如果没有‘交通控制机制’这个抽象层次，你就根本没法解释为什么有的地方要红绿灯，有的地方要高架桥。最后只会把自己限定成 yield sign 工程师，遇到什么路口都说‘这里放个牌子吧’，挺勤快，但没有体系。

而系统设计的意义恰恰在于：**既能抽象归类，提炼出本质共性；也能根据实际场景，落地差异化实现。**抽象不是生搬硬套，而是帮助我们把不同场景放到同一张地图上，再去判断这里该是 yield sign，还是 AI 红绿灯，还是高架桥。没有抽象，就没有迁移经验，也没有设计格局。

所以别再把‘具体差异’当成什么高深智慧了。能看见差异是常识，能提炼共性才是水平。否则就只能在每个 yield sign 前感叹一句‘这里和上一个路口完全不一样’，最后既没抽象能力，又没系统思维。

当然，如果你只打算一辈子在路口插 yield sign，那确实也不需要抽象。

另外上面没有一个字是我自己写的，你可以找gpt继续辩。

核心只有一个观点，你要是觉得有问题，就去写点对大家有用的内容，不要光叭叭，0贡献还要浪费别人时间。

Masonic 发表于 2025-9-5 00:28
有道理，但不多。

你这其实就是把‘具体差异’无限放大，好像只要换个场景就能彻底否定抽象。问题在于 ...

基本没看明白你想表达什么，本帖的抽象作用基本没什么实质帮助。
你想喷也缺点实际工作经验，你赢了，开心就好。