译 | 入🕳️大容量单机

---

纯翻译

• 原文：Use One Big Server
• 讨论区：Hacker news

关于“单体与微服务”已经有过太多争论，但隐藏在争论背后的真正问题是【为分布式系统架构所付出的研发人员时间和相关成本是否值得】。通过考量系统里真正的操作事项，能对大部分情况下是否需要分布式系统形成一些洞见。

对于软件与（运行软件的）服务器之间的虚拟化与抽象化，我们已相当熟悉。近来，无服务计算风头正劲，甚至“裸机”都成了一类虚拟机的代称。但是软件的每一部分都是跑在服务器上的。我们生活在一个充满了虚拟化的世界，因此大部分的服务器其实比我们设想的容量要大得多、便宜得多。

看看你的服务器

上图是微软 Azure 搭载了 AMD 芯片的服务器。从左边开始，（带铜管的）大金属夹子是散热器，铜管连接到的每个 CPU 上的金属盒子是热交换器。CPU 是 AMD 第三代服务器 CPU，每一个 CPU 都符合以下规格：

• 64 核
• 128 线程
• 大约 2-2.5 GHz 时钟频率
• 核心支持 4-6 指令/时钟周期
• 256 MB 三级缓存

所以这台服务器合计有 128 核，支持 256 线程并行。所有核心一起工作时，峰值数据是每秒 4 万亿次双精度浮点运算。在 2000 年刚开头，这台计算机能排进超算前 500，要到 2007 年才会跌出前 500 名单。每个 CPU 核都比 10 年前的单个核强大得多，也拥有更宽的计算管道。

每一个 CPU 的前后是内存：有16个插槽，每个槽位可以支持 DDR4-3200 RAM 内存条。今天低功耗 DIMM 内存条的最大容量为 64 GB。采用低功耗方案，这台服务器可以拥有 1 TB 内存。采用高容量的 DIMM（通常比小一些的 DIMM 慢），这台服务器支持的内存容量能提高到 8 TB。16 个内存通道全使用 DDR4-3200 的内存条，服务器所有内核的内存吞吐量可以达到约 200 Gbps 。

就 I/O 来说，每个 CPU 可以提供 64 个 PCIe 4.0 通道。在总共支持 128 个 PCIe 通道的同时，服务器支持 30 个 NVMe SSD 和一张网卡。你能买到的典型配置是 16 个 SSD 或者硬盘。最后这张图右上角是一张网卡。这台服务器可能配置了 50-100 Gbps 的网络连接。

一台服务器的能力

今天，一台服务器能提供：

• 以 400 Gbps 的速度处理视频文件
• 支持 NoSQL 数据库百万级 IOPS
• 支持 PostgreSQL 7w 级 IPOS
• 支持 Nginx 50w 请求/s
• 20 s 内编译完 linux 内核
• 支持 x264 编码器以 75 fps 的刷新率渲染 4k 视频

以及其他能力。最近有很多公开的基准测试，如果你了解自己的服务的工作模式，很可能找到相似的基准测试。

一台服务器的成本

在大型的主机提供商 OVHCloud 那里，可以租到一台 HGR-HCI-6 服务器——配置类似我们上文的描述，有 128 个物理核（256 线程），512 GB 内存，50 Gbps 带宽，月租 1318 刀（约 8887 RMB ）。

再移步看看最流行的预算选项，Hetzner，可以租一台小一点的服务器，带 32 物理核，128 GB 内存，月租 140 欧（约 970 RMB）。这台是比 OVHCloud 提供的要小的服务器（配置只有 1/4），但不同价位的供应商给了你价格上的弹性空间。

在 AWS，可以租到的最大服务器之一为 m6a.metal。它提供了 50 Gbps 带宽，192 vCPU（96个物理核），768 GB 内存，在美国东部地区每小时价格为 8.2944 刀。月租差不多 6055 刀。云溢价是真的。

可以从戴尔网站购买到一台类似的服务器，带 128 物理核和 512 GB内存（以及合适的 NIC、SSD，和支持合同），价格约 4w 刀。但是，如果你准备把这些钱花在服务器上，应该和销售员好好聊聊，以保证你拿到了最好的购买条款。你还需要花钱托管这台服务器，并接入网络。

相比于购买服务器，（这笔钱）使用云服务器能撑 8 个月，租用服务器能撑 30 个月。当然，购买服务器有一大堆缺点，租用也不例外，所以接下来我们将思考一下云溢价，看看你是否真的想要为其买单（警报：答案是 yes，但并不需要支付云供应商要求的那么多）。

思考一下云

云时代始于 2010 年早期。当时最先进的 CPU 是 8 核的 Intel Nehalem CPU。超线程刚刚起步，所以 8 核的 CPU 能提供惊人的 16 线程。AES 加密的硬件加速时代即将到来，向量为 128 位。最大的 CPU 有 24 MB 缓存，服务器能支持 256 GB DDR3-1066 的内存。如果你想存储数据，希捷刚推出 3 TB 的硬盘。每一个核在一个时钟周期内提供每秒 4 亿次浮点运算，意味着你以 2.5 GHz 运行的 8 核服务器能提供每秒 800 亿次浮点运算。

分布式计算的爆发就是源于这个趋势：如果你想要做的事包含了获取数据，你就需要很多的磁盘来达到预期的存储吞吐量。如果你想要做大型计算，你通常需要很多 CPU。这就意味着需要通过大量 CPU 之间的协作来完成任务。

从那时起，服务器的容量就增长了很多，SSD 的 IOPS 以至少 100 的速度增长，但主流虚拟机、容器的大小却没有增长多少，我们仍然在使用行为方式更类似硬盘驱动器而不是 SSD 的虚拟驱动器（尽管两者的差距正在缩小）。

一台服务器（加备机）通常就富余了

如果你的 Web 服务压力在 10k QPS 以下，并且没有视频流，通常一台服务器就够用了。在服务确实很简单的情况下，一台服务器甚至能达到 100w QPS。如果你做过就会知道，很少有 Web 服务能获取这么多流量。即使你提供视频服务，仅用一台服务器运行控制台也是合理的。一个基准测试能帮助你判断你在哪个位置。同样的，你也可以使用相似应用的通用基准测试，或者根据通用性能指标表格来估算需要多大的服务器。

纵向比横向更好

当一台服务器不够用，需要一个集群时，使用少量大容量服务器通常比使用大量小容量服务器更好。集群内部的协作消耗并不是 0，每台服务器的协作消耗通常是 O(n)。为了减少这个消耗，应该优先选择少量大容量服务器。像无服务计算这样的场景里，调起小型的、存活时间较短的容器，需要消耗大量成本。而另一个极端，只有一台计算机的集群，协调成本可以忽略不计。

大容量服务器及其可用性

使用单个大容量服务器的最大缺点是可用性。服务器总需要停机维护，或者也可能崩了。一主一备，并让主备运行在不同的数据中心通常就够了。2×2 的配置能够满足任何偏执狂：2 台在主数据中心（或者云供应商处），2 台在备用数据中心，能提供很大的冗余度。如果还想部署第三个备份，通常可以比第一和第二份部署更小。

但是，你仍然必须关注关联型硬件故障。硬盘驱动器（现在是 SSD）偶尔的关联型故障是众所周知的：如果你的磁盘属于同一制造批次，当发现一块磁盘有故障，在切换到备份前，很可能发现第二块有故障的磁盘。像 Backblaze 这样的服务，通过使用不同制造商的不同类型磁盘来克服这个问题。Hacker news 经过主备同时挂掉这样的坑爹时刻才学到了这个教训。

如果正在使用提供预制服务器的主机供应商，谨慎的做法是租用两种不同类型的服务器放在主备数据中心。这种方案几乎能避免现代系统的所有故障。

使用云，但别太云化

同时兼顾可用性和易用性是我（以及大多数工程师）选择云主机的最主要因素之一。是的，你租用机器花了额外的巨大溢价，但云供应商对规避大多数你没见过的故障并构建稳定的服务器有丰富的经验，对于剩下的故障类型，你可以通过快速拉起一台备机来解决—快速从他们近乎无限的计算资源池里租用一台新机器。他们的工作就是保障你不停机，即使他们没能做到完美，但也做到了足够好。

相比云供应商，主机供应商是一个更经济的选择，但这些供应商良莠不齐，有部分不理解网络供应和关联型硬件故障。而且，相比迁移云主机，从一台租用服务器迁移到另一台更大的租用服务器要麻烦得多。所以云供应商有合理的溢价理由。

但是，当你使用云时，销售人员通常会向你大力营销云原生架构——带有像微服务一样有大量负载均衡器、自动伸缩虚拟机组的东西，带厂商锁定增强特性的产品，如无服务计算，托管的高可用数据库。销售人员有足够的动机去营销云原生架构——这对他们更有利。

惯用套路认为使用云架构是好的，因为可以支持你无痛扩容。有很多理由支持使用云原生架构，但能服务很多人这个理由不在其中：大部分的服务跑在一台服务器上就可以支持数百万人同时使用，而不需要你支付 5 位数的账单。

为什么我应该基于峰值负载付费？

对大容量单机方案的一个普遍批评是你是在为峰值负载付费，而不是实际用量。因此，无服务计算或大量微服务虚拟机才是保持成本与收益一致的方案。

不幸的是，因为你的所有服务都跑在服务器上（不管你是否乐意），供应链上的某位会根据他们的峰值负载收费。针对负载均衡器、无服务计算、小型虚拟机的这部分云溢价，是基于云供应商要提供多少额外容量来支持峰值负载。无论如何，你就是在为某人的峰值负载付费。

这就是说，如果你的负载是突发型的—就像只运行一次就永久关闭的模拟过程—你就优先选择云方案，但如果你的负载不具有这样的突发性，你可以选择由少量大容量服务器组成的更便宜的系统（也更容易构建）。如果你的云供应商的使用方式比你的更具有突发性，那你就要为这部分溢价买单而没有任何收益。

这部分溢价不限于云服务，同样适用于虚拟机。但是如果你以 7×24 小时方式运行云虚机，你就可以通过购买 1 年的合同或者在你的体量足够大的情况下和销售人员协商后能避免为这部分溢价买单。

一般来讲，你的负载越具有突发性，你的架构就应该越云化。

云化的成本是多少？

云化是昂贵的。一般我预计会有 5-30 倍的溢价。不是 5% – 30%，而是 5 倍 – 30 倍。

看看 AWS lambda 计算的价格：0.2 刀/M 请求 + 0.0000166667 刀/GB-second RAM。接下来我比照刚才说的 m6a.metal 实例的价格来看看 x86 CPU。高配 ARM 服务器和 ARM 无服务计算同样更便宜。

假设你的服务器成本是 8.2944 刀/h，带 768 GB 内存，能支撑 1k QPS 负载。

• 1k QPS 就是每分钟 6w 请求，或者说每小时 360w 请求
• 每个请求消耗 0.768 GB-秒 内存（均摊下来）
• 使用无服务计算替换的成本大约是 46 刀/h

看下来，无服务计算的溢价因子为 5.5。如果你能保障服务器的利用率在 20% 以上，使用服务器就比无服务计算更经济。这还是在没有为服务器方案考虑任何省钱手段的基础上，如果从现货市场租用这些服务器或者以 1 年期合同来使用，得到的溢价因子还会更高。

比较从 OVHCloud 租用同样配置服务器的价格和购买 AWS lambda 的价格，溢价因子达到 25。

如果能保持以 5% 的容量运行，在低成本租用服务器和使用 AWS lambda 之间，就优先选择服务器。

而且，注意，真实的 QPS 数字没关系：如果 8.2944 刀/h 的服务器能支撑 100k QPS，请求将使用少于 100 倍的内存时间，意味着你将抵达 5.5倍（或 25倍）的溢价。当然，你可以纵向扩容来适配应用。

大容量单机的反对意见

如果你计划使用单机方案，通常会被一些人劝退，他们更适应云、喜欢跟风、或者有合理的担忧。当你思考单机方案的时候，请忠于自己的判断，但是大部分人极大低估了相比于直接计算，云架构所需要的成本。下面是一些常见的反对意见。

采用云架构，我就不用雇佣管理员了

你说得对。不过他们现在叫云操作员，并且隶属于不同的管理者。他们能阅读云厂商提供的天书文档、跟上更新和废弃操作的洪流的能力，使得他们比系统管理员至少贵 5 倍。

采用云架构，我就不用做安全更新了

你说得对。你可能只需要做其中很小的一部分，但是你不用做的那些都是简单得可以自动化的。你仍然需要挣扎于审计用到的库、保证所有的配置文件都是安全的。

采用云架构，我就不用担心它宕机了

你通过使用云产品和微服务所获得的高可用架构，仅仅是为了弥补因他们自身的复杂性而带来的脆弱性。从这点上说，你使用两个不同的云区域或者云厂商，通常就可以认为服务不会宕机了。但是，过去云厂商经常发生全球性的中断事故，没有理由假设云厂商的宕机频率会比你的单机低。

还记得我们努力避免关联型故障。云数据中心有很多部分会以关联的方式发生故障。主机托管商则要少得多。类似的，复杂云服务，如托管数据库，比单机（虚拟机）有更多故障场景。

采用云架构，我能更快速地进行开发

做吧，看看账单，想想是否值得切换。这项可能是支持采用云架构的最有力证据。但是，如果在成长过程中不考虑，可能以在云架构上烧掉大量金钱收场，时间长了又换个更无聊的东西。

我的工作负载真的是突发型

云让开。这是一个使用无服务计算之类的很好理由。云架构提供的好处之一就是很好缩容。如果你的负载在相当长的一段时间都是空闲的，并且会有无法预测的突然爆发，云架构可能就非常适合你。

CDN 怎么办？

在采用单机的情况下，想达到 CDN 一样改善延迟和节省带宽的效果，是不可能的。这同样适用于需要分布式部署的其他系统，如备份。幸好 CDN 和 备份是充分竞争的市场，价格相对便宜。有很多类型可供购买，而不用自己构建。

关于微服务和单体的提示

思考大容量单机很自然地会联想到单体架构。但是，采用单机时不一定要采用单体架构。可以在单机上运行若干容器，每个容器里跑一个微服务。但是在单机上采用微服务架构时，增加了很多开销，收益却存疑。

结论

当你正经历着业务成长的痛苦，接近现有服务器的极限，目前的套路是分片和水平扩容，或者采用云架构“无痛地”水平扩容。但垂直扩容通常更简单和高效。使用单机相对便宜、管理成本降至最低，并且在你小心处理了关联型硬件故障的情况下有更好的可用性。它并不光芒四射，也无法丰富你的简历，但它能很好地满足你的实际需要。

ps：一个想法和它隐含的约束假设是各自随时间变化的，所以接受任何一个想法不能脱离它的隐含前提，一定程度上过去也具有现实意义，可以简化理解为同一个问题在不同约束条件下的控制实验，只是简化的尺度不容易把握