系统与基础设施highscalability.com
在 AWS 上将用户扩展到 1100 万的入门指南
A Beginner's Guide to Scaling to 11M+ Users on Amazon's AWS
2016 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
High Scalability 上的一篇经典长文，以 AWS 为例手把手讲解一个应用从零扩展到 1100 万以上用户的路径：从单机起步，逐步引入负载均衡、自动伸缩、RDS/数据库读写分离、缓存、多可用区部署等。文章按用户量级分阶段展开，是理解 Web 应用水平扩展各环节的入门读物。
为什么经久不衰：它把“如何扩展到千万级用户”这个复杂问题拆成了循序渐进、可操作的阶段，多年后仍是学习云上架构演进的最佳入门路径之一。
HN 评论精选
ELB 并非真正自动扩容，突发流量前必须联系 AWS 预热，否则会被打挂。
我在娱乐/票务行业工作，曾因依赖 AWS 的弹性负载均衡器（ELB）在突发流量高峰时吃过大亏。文章说 ELB 会自动横向和纵向扩容、无需管理，但 Amazon 官方文档明确指出：在预期出现瞬时大流量的场景下，需要联系 AWS 提前“预热”负载均衡器，并告知流量起止时间、每秒请求速率和请求/响应大小，由他们配置相应容量。
napkindrawing查看英文原文
I work in the entertainment / ticketing industry and we've been burned badly before by relying on AWS' Elastic Load Balancer due to sudden & unexpected traffic spikes. From the article: "Elastic Load Balancer (ELB): [...] It scales without your doing anything. If it sees additional traffic it scales behind the scenes both horizontally and vertically. You don’t have to manage it. As your applications scales so is the ELB." From Amazon's ELB documentation: "Pre-Warming the Load Balancer: [...] In certain scenarios, such as when flash traffic is expected [...] we recommend that you contact us to have your load balancer "pre-warmed". We will then configure the load balancer to have the appropriate level of capacity based on the traffic that you expect. We will need to know the start and end dates of your tests or expected flash traffic, the expected request rate per second and the total size of the typical request/response that you will be testing."
文章过于乐观：RDS 有上限、ELB/自动伸缩不可靠、过早微服务化增加成本，AWS 还有厂商锁定风险。
AWS 的销售总把一切说得完美无缺。RDS 不错但容量有限，远早于文中 1000 万用户的节点你就得迁出；他们力推的 Aurora 高可用有诸多未明说的取舍。不要依赖弹性伸缩做高可用——当某个可用区出问题时 AWS API 本身也会挂掉或拥堵，想保高可用就得常备至少 50% 的冗余容量。按文中的扩展方式，成本在 10 个用户时就开始飙升；实际上配合智能缓存（哪怕只是 Nginx 缓存），一台 t2 小型实例就能轻松支撑几千用户。过早拆分服务既增加成本又增加故障面。另外，别等到上千用户才做多可用区容灾，跨可用区复制一台 t2.small 的成本远低于流失用户。用 AWS 的专有服务要做好被厂商锁定的准备。
falcolas查看英文原文
Hoo boy. Here we go. The problem with AWS reps is that they only see everything as working perfectly, with no possibility for downtime of their services. RDS is great, but only to a certain level. You'll still need to pull it off RDS once you reach that service's capacity (much sooner than their 10m user mark). They also keep pushing Aurora, but without telling us what the tradeoffs are for the high availability. Based on the responses so far (MySQL backed by InnoDB), it appears to be based on a technology similar to Galara, which has a lot of caveats for its use, especially with multiple writers. Don't depend on Elastic Scaling for high availability - when an AZ is having issues, the AWS API will either be down or swamped, so you want to have at least 50% extra capacity at all times, if you want high availability. Using their scaling numbers, your costs start spiking at 10 users. Realistically, with intelligent caching (even something as simple as Nginx caching), you can easily support several thousand users just fine with a t2 style instance, either a small or micro. Splitting services onto different hosts not only increases your hosting costs, it increases the workload on your developers/admins and likeliness of failure. DR: Don't wait until you have over a thousand users to have multiple instances in different AZs. The cost of duplicating a t2.small across an AZ is small compared to lost users or sales. Automation: Be prepared for vendor lockin if you use Amazon's solutions. Also be prepared for their APIs being unavailable during times of high load or during AZ failures. > Lambda [...] We’ve done away with EC2. It scales out for you and there’s no OS to manage. The biggest problem with Lambda right now are the huge latency costs with cold lambda instances. You'll get a pretty good 95% percentile response times, but that other 5% will be off-the-chart bad. In summary, AWS has a lot of great toys, and can absolutely be used for scaling up to silly levels. However, most who have done this degree of scaling do not do so using AWS tools.
实际经验表明用便宜的 VPS 加良好架构，千万级用户每月成本可低至几百美元，远低于 AWS 方案。
分享一个服务 150 万月活用户的实时 Web 应用的实际数据：前端跑在一台每月 30 美元的 VPS 上，CPU 和内存都有富余；两台每月 5 美元的数据库服务器做冗余。理论上扩展近乎线性，到 1000 万用户加约 4 台服务器即可，也就是每月约 200 美元。或者，写烂软件然后每月扔 5 万美元给 AWS。
chmod775查看英文原文
Here's some anecdata from someone serving 1.5 million monthly users with a realtime (chat etc.) web app. Disregarding the file serving functionality, this is the entire infrastructure: - The frontend is running on a 30 bucks/mo VPS with cycles and RAM to spare. - There's 2 DB servers for 5 bucks / mo for redundancy. This thing would scale pretty linearly in theory, so for 10 million users just add like 4 servers. So about 200 bucks / mo to run your average startup's web app at 10 mil users. Alternatively write bad software and throw 50k/mo at AWS I guess.
质疑 S3 的“11 个 9”宣传，并批评 AWS 状态页在严重故障时 reporting 不透明。
读到“S3 高度持久、11 个 9 的可靠性”时我眼睛抽搐了——我记得不止一次 AWS 故障影响了 S3 的可用性。AWS 自己的页面说的是持久性 10 个 9，但我怀疑这个数字，这种水平几乎没有任何终端客户产品能实现，可能是某种巧妙的统计口径？更让我失望的是 AWS 的服务状态页：服务严重中断到无法响应任何请求时，状态页要么毫无提示，要么只报“错误率升高”。
altmind查看英文原文
> Amazon S3 is an object base store. > Highly durable, 11 9’s of reliability. My eye twitched when I read this, considering that I remember more than one aws outage that affected s3 availability/reliability. AWS own pages mention 10 nines for /durability/, however, I doubt this durability number, this level is almost unachievable by any end customer product. Could it be some clever durability accounting? I'm quite disappointed on AWS service status reporting when the service may be disrupted so so badly, to the point of not being serve a single request, however status pages not mentioning problems at all, or just reporting "increased error rates".
历次讨论
同类还值得读
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编辑精选