系统与基础设施specbranch.com
用一台大服务器就够了
Use one big server
2022 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章主张在许多场景下，与其采用复杂的分布式/微服务架构，不如直接使用一台配置强大的大型服务器：现代硬件性能极高、云服务成本高昂且引入了大量不必要的复杂度。文章认为单体服务器在性能、可靠性和运维成本上往往优于云方案，数据库尤其应该尽量保持在一台机器上。
为什么经久不衰：它挑战了“上云和微服务是默认选择”的行业惯性，用具体的价格和性能数据提醒人们：简单架构往往更快、更便宜、更可靠，因此多年后仍被反复讨论。
HN 评论精选
真正该“一台大机器”的是数据库：拆散数据服务代价极高，单库 join 远优于 RPC 扇出。
把架构做得更“云化”确实有溢价，但“用一台大服务器”最好的应用场景其实不是单体 API 服务，而是数据库。对后端工程师来说，最糟的莫过于把数据拆散到各个服务的独立数据库里，一切都靠 REST/RPC 传递。产品需求总是想把不同数据源联在一起查询，而在单个数据库里高效做 join，远比向多个数据库发起 RPC 调用容易，还要应付数据不一致、缺乏原子性等问题。无状态微服务可以拆，但数据是软件世界里最稳定不变的东西，尽量把 OLTP 数据留在单个数据库里，能让你在新功能上保持敏捷。
cfors查看英文原文
Yep, there's a premium on making your architecture more cloudy. However, the best point for Use One Big Server is not necessarily running your big monolithic API server, but your database. Use One Big Database. Seriously. If you are a backend engineer, nothing is worse than breaking up your data into self contained service databases, where everything is passed over Rest/RPC. Your product asks will consistently want to combine these data sources (they don't know how your distributed databases look, and oftentimes they really do not care). It is so much easier to do these joins efficiently in a single database than fanning out RPC calls to multiple different databases, not to mention dealing with inconsistencies, lack of atomicity, etc. etc. Spin up a specific reader of that database if there needs to be OLAP queries, or use a message bus. But keep your OLTP data within one database for as long as possible. You can break apart a stateless microservice, but there are few things as stagnant in the world of software than data. It will keep you nimble for new product features. The boxes that they offer on cloud vendors today for managed databases are giant!
讽刺软件行业用糟糕的架构和抽象浪费了硬件工程师的巨大成就。
我们行业可以这么总结：硬件工程师在把存储尽可能靠近计算的物理极限上不断突破，成就堪比农业和工业革命；而软件工程师却把一切拆得越远越好，还嫌不够慢，再加上虚拟化和抽象糟糕的软件层。浏览器够快了，却无视二十年的性能工程重新发明渲染，然后又加回服务端渲染，结果渲染两次，还称之为“最佳实践”。我手上这只昂贵的鼠标，居然配着一个 2GB 的 Electron 应用每周更新两次。我们产出的垃圾和为它辩护的方式，就像一种思想病毒。
fleddr查看英文原文
Our industry summarized: Hardware engineers are pushing the absolute physical limits of getting state (memory/storage) as close as possible to compute. A monumental accomplishment as impactful as the invention of agriculture and the industrial revolution. Software engineers: let's completely undo all that engineering by moving everything apart as far as possible. Hmmm, still too fast. Let's next add virtualization and software stacks with shitty abstractions. Fast and powerful browser? Let's completely ignore 20 years of performance engineering and reinvent...rendering. Hmm, sucks a bit. Let's add back server rendering. Wait, now we have to render twice. Ah well, let's just call it a "best practice". The mouse that I'm using right now (an expensive one) has a 2GB desktop Electron app that seems to want to update itself twice a week. The state of us, the absolute garbage that we put out, and the creative ways in which we try to justify it. It's like a mind virus. I want my downvotes now.
用大云厂商宕机时“法不责众”，用户反而更宽容。
在大厂商那里有个好处：当他们宕机时，互联网的一大片都会跟着挂掉并登上新闻头条。当用户看到你只是被波及了那场影响其他十个他们常用服务的全球性故障时，就不太会抱怨你的服务宕机了。
gregmac查看英文原文
> However, cloud providers have often had global outages in the past, and there is no reason to assume that cloud datacenters will be down any less often than your individual servers. A nice thing about being in a big provider is when they go down a massive portion of the internet goes down, and it makes news headlines. Users are much less likely to complain about your service being down when it's clear you're just caught up in the global outage that's affecting 10 other things they use.
用 NUC 阵列等低端硬件替代云，加上公用事业注册等技巧，成本远低于云。
如果每月 1318 美元买来的 128 核、512GB 内存、50Gbps 带宽你连 50% 都用不满，我更喜欢用多台低端可消耗的电脑当服务器。我在一些客户站点用 Intel NUC 阵列多年，比云方案省了不少钱，另备一台冗余机随时替换故障。另一个常被忽视的选择：在美国几个中部州，注册为公共电信公用事业很容易也很便宜，可以把带电设备箱放在公共道路旁、紧邻光缆汇聚点，大幅节省光纤接入安装成本，甚至可以顺带向附近公寓提供住宅宽带服务来抵消开支。
stevenjgarner查看英文原文
If you are not maxing out or even getting above 50% utilization of 128 physical cores (256 threads), 512 GB of memory, and 50 Gbps of bandwidth for $1,318/month, I really like the approach of multiple low-end consumable computers as servers. I have been using arrays of Intel NUCs at some customer sites for years with considerable cost savings over cloud offerings. Keep an extra redundant one in the array ready to swap out a failure. Another often overlooked option is that in several fly-over states it is quite easy and cheap to register as a public telecommunication utility. This allows you to place a powered pedestal in the public right-of-way, where you can get situated adjacent to an optical meet point and get considerable savings on installation costs of optical Internet, even from a tier 1 provider. If your server bandwidth is peak utilized during business hours and there is an apartment complex nearby you can use that utility designation and competitively provide residential Internet service to offset costs.
历次讨论
同类还值得读
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编辑精选