scaling-a-system-from-0-to-10-million-users

https://blog.algomaster.io/p/scaling-a-system-from-0-to-10-million-users

全文总结
本文深入探讨系统从初始到大规模用户量的扩展历程。开篇点明系统扩展应循序渐进，忌初始过度设计。随后详述系统从 0 到 100 万 + 用户的 7 个扩展阶段：初始阶段，单服务器承载所有应用、数据库及后台任务，虽简单却高效，适合起步，当出现数据库查询慢、服务器资源紧张等情况时需升级；接着将数据库与应用服务器分离，实现资源隔离与独立扩展，此时连接池可优化数据库连接；随着流量增长，单应用服务器成瓶颈，通过负载均衡器实现多应用服务器扩展，同时要解决会话状态问题；用户达 1 万 +，数据库负担加重，借助缓存、读副本和 CDN 降低数据库负载；用户达 10 万 +，流量波动大，需实现自动缩放和确保应用无状态；用户达 50 万 +，传统优化手段失效，需引入数据库分片、微服务和异步处理；用户达数百万，面临跨区域延迟、数据中心单点故障等问题，可通过多区域部署、高级缓存和 CQRS 解决。最后指出，达 1000 万用户以上，需定制基础设施，且应按需扩展，理解各阶段问题并适时采取正确措施，选择契合当前需求且易于演进的最简架构。
重要亮点
初始阶段的架构选择：起步阶段，将所有功能置于单服务器是明智之选，如 Instagram 初始便是如此。这种方式部署快捷、成本低廉、迭代迅速、调试轻松且具有全栈可见性。但随着业务发展，当数据库查询在高峰时段变慢、服务器资源持续紧张、部署导致停机或后台任务影响用户体验时，就需考虑架构升级。
数据库与应用服务器分离：流量增大，单服务器不堪重负，将数据库与应用服务器分离可带来诸多好处，如资源隔离、独立扩展、安全性提升、优化更具针对性以及备份更便捷。多数团队会选择使用托管数据库服务，同时连接池技术可优化数据库连接资源的使用，提升效率。
多应用服务器与负载均衡：单一应用服务器成为单点故障且难以应对增长的流量时，在负载均衡器后运行多个应用服务器是必然选择。负载均衡器能分发请求，保障系统在部分服务器故障时仍正常运行。常见分配算法多样，应按需选择。同时，要解决好状态服务器问题，可采用负载均衡器绑定用户请求或使用共享存储管理会话数据的方式。
应对数据库瓶颈的策略：用户数量破万，数据库易成瓶颈。缓存、读副本和 CDN 是缓解数据库压力的有效手段。缓存可存储频繁访问数据提升读取速度，但需注意缓存更新策略；读副本分担读流量，但要关注复制延迟；CDN 则通过缓存静态资源，降低应用服务器带宽和计算成本。
自动缩放与无状态应用：用户达 10 万 +，流量模式复杂，手动调整服务器已不可行。实现自动缩放并确保应用真正无状态是关键。自动缩放基于指标调整服务器数量，配置时要注意最小实例数、冷却时间、实例预热等参数，同时许多团队会在此阶段从会话式认证转向基于令牌的认证。
高级扩展技术：用户达 50 万 +，数据库写入、单体应用更新以及同步操作等问题凸显，需引入数据库分片、微服务和异步处理。数据库分片可解决写入瓶颈，但操作复杂；微服务将应用拆分为独立服务，提升灵活性与扩展性；异步处理通过消息队列解耦生产者与消费者，提高系统的弹性与可扩展性。
全球规模的架构优化：拥有全球用户时，面临延迟、数据中心单点故障等挑战。多区域部署可降低延迟、实现灾难恢复；CQRS 分离读写操作优化架构；高级缓存策略如缓存预热和复制可提升性能。但在全球规模下，需在一致性、可用性和分区容忍性间权衡，多数系统选择最终一致性。