系统与基础设施danluu.com编辑精选
为简单架构辩护（2022）
In Defense of Simple Architectures (2022)
2022 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章为“简单架构”辩护：Dan Luu 指出，大多数公司并不需要微服务、容器编排和复杂的高可用设计，单体应用加上一台性能不错的机器往往就够用，运维成本也远低于人们想象。他用实例说明，业界对规模和可靠性的焦虑常常远超业务实际需要。
为什么经久不衰：它戳破了“最佳实践”带来的架构焦虑，用朴素的事实提醒读者：先弄清一台机器能做什么、业务真正需要什么，再做技术选型。
HN 评论精选
极简单进程应用在小业务场景下维护成本极低、完全够用。
我近十年前用 Node+Express 写的一些最简单的 Web 应用至今还在生产环境跑。依赖只有 Express 和几个第三方 API 连接器，数据库就是按行分隔 JSON 对象的追加文件，重启时读入文件重建内存镜像，所有数据都在 RAM 里。本以为这些玩具很快会被替换，结果它们对几家小企业完全够用、几乎不需要维护；换服务器只要拷脚本和数据文件，一年几分钟停机没人介意。容器和编排自有其道理，但对真正简单的应用，这种单进程的笨办法效果好得出奇。
pavlov查看英文原文
There are some web apps still in production that I wrote almost a decade ago in Node+Express in the simplest, dumbest style imaginable. The only dependencies are Express and some third-party API connectors. The database is an append-only file of JSON objects separated by newlines. When the app restarts, it reads the file and rebuilds its memory image. All data is in RAM. I figured these toys would be replaced pretty quickly, but turns out they do the job for these small businesses and need very little maintenance. Moving the app to a new server instance is dead simple because there's basically just the script and the data file to copy over, so you can do OS updates and RAM increases that way. Nobody cares about a few minutes of downtime once a year when that happens. There are good reasons why we have containers and orchestration and stuff, but it's interesting to see how well this dumb single-process style works for apps that are genuinely simple.
面试式的复杂系统设计未必必要，业界巨头早年也靠简单技术栈起家。
我最近面试时准备系统设计环节，反复想到的正是 Dan Luu 在这里写的东西。面试里我努力画出一堆带缓存、故障转移和调优数据库的“正规”架构图，心里却想：Facebook 不就是用 PHP、MySQL 和 Memcache 撑到十亿用户的吗？这也让我想起那篇《命令行工具可以比你的 Hadoop 集群快 235 倍》，以及 Rachel by the Bay 那些用极基础工具和大量经验搭出又快又好的机器的文章。
lifefeed查看英文原文
I was interviewing for software jobs recently, and while I was studying up on the "system design" portion I kept circling around the same insight that Dan Luu writes about so well here. I would sit down at an interview and try to create these "proper" system designs with boxes and arrows and failovers and caches and well tuned databases. But in the back of my mind I kept thinking, "didn't Facebook scale to a billion users with PHP, MySQL, and Memcache?" It reminds me of "Command-line Tools can be 235x Faster than your Hadoop Cluster" at https://adamdrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html , and the occasional post by https://rachelbythebay.com/w/ where she builds a box that's just fast and with very basic tooling (and a lot of know-how).
多数业务对短暂停机高度容忍，过度追求确定性可用性是浪费。
我觉得多数开发者最大的问题是不知道一台计算机实际能做什么、现实中又有多可靠。另外，理解 99% 的企业对现实中可能出现的问题有多能容忍，能让你不必为极端的边缘情况抓狂——总有人琢磨着如何提供连宇宙射线或区域核战争都打不断的确定性可用性保证。我真希望云和 SaaS 厂商近来的可靠性事故能让人们明白：短暂停机对业务几乎从不是致命问题。“故障转移需要人工介入”是特性，不是缺陷。
bob1029查看英文原文
I think the biggest problem for most developers is not understanding what one computer can actually do and how reliable they are in practice. Additionally, understanding of how tolerant 99% of businesses are to real-world problems that could hypothetically arise can help one not frustrate over insane edge case circumstances. I suspect a non-zero number of us have spent time thinking about how we could provide deterministic guarantees of uptime that even unstoppable cosmic radiation or regional nuclear war couldnt interrupt. I genuinely hope that the recent reliability issues with cloud & SAAS providers has really driven home the point that a little bit of downtime is almost never a fatal issue for a business. "Failover requires manual intervention" is a feature, not a caveat.
微服务只适合超大规模公司，普通公司应先做好高内聚低耦合的单体。
绝大多数组织不需要微服务，也不需要它们买来又不得不集成进技术栈的那一半产品，它们只是在削自己的牦牛，好凑齐 202X 年的“最佳实践”清单。面向服务的架构和微服务解决的是一小撮超大规模公司的特有问题，那些公司还能花钱养专职做工具链的团队。大多数公司该做的是先做出能赚钱的单体，同时招能写出高内聚、低耦合模块的好工程师，这样将来真成了下一个 Google，拆分也没那么痛苦。反正就算痛苦也无所谓，到时候有钱雇一支大军来干，而最初的工程师早已套现退休。
ilovecaching查看英文原文
The vast, vast, vast majority of organizations don't need micro services, don't need half of the products they bought and now have to integrate into their stack, and are simply looking to shave their yak to meet the bullet list of "best practices" for year 202X. Service oriented architectures and micro services solve a particular problem for companies that are operating on a massive scale and can invest (read waste money) on teams devoted to tooling. What most companies should do is build a monolith that makes money, but hire good software engineers that can write packages/modules whatever with high levels of cohesion and loose coupling, so that one day when you become the next Google, it will be less of a pain to break it into services. But in the end it really doesn't matter if it's painful anyway, because you'll have the money to hire an army of people to do it while the original engineers take their stock and head off to early retirement.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选