“攀登”是一个神奇的词。每个人都想打造下一个 Facebook 或 WhatsApp。但当流量真正增加时，大多数系统就会崩溃。
构建可扩展的软件并不是使用最新的工具，而是使用最新的工具。它是关于设计一个可以增长的系统，而无需为用户数量每增加 10 倍而从头开始重写。
在本指南中，我们将探索需要遭受打击的系统的架构最佳实践。
1. 松耦合
想象一下所有车厢都焊接在一起的火车。如果其中一节车厢脱轨，整列火车都会倒塌。 这是一个耦合系统（刚性整体）。
为了扩展，您需要解耦。
- 异步通信：它不是“服务A”调用“服务B”并等待响应（锁定线程），而是向队列（RabbitMQ、Kafka）发送消息。 “服务 B”会尽可能处理它。
- 优点：如果服务 B 出现故障或速度变慢，服务 A 会继续工作并对消息进行排队。系统不级联。
2. 数据库：大瓶颈
在 90% 的情况下，系统无法扩展，因为[数据库0崩溃。
- 分片：将数据划分到多个服务器上。用户 A-M 在服务器 1 上，N-Z 在服务器 2 上。Instagram 就是这样做的。
- CQRS（命令查询职责分离）：将读模型与写模型分离。
- 要写入（INSERT），请使用健壮的关系数据库（PostgreSQL）。
- 要读取 (SELECT)，请使用非规范化且快速的版本（Elasticsearch 或 Mongo）。
3.无国籍
如果您有 100 台服务器，其中任何一台都应该能够为任何用户提供服务。
- 规则：切勿将“会话”存储在服务器的 RAM 内存中。
- 解决方案：将状态存储在客户端（JWT 令牌）或外部缓存库（Redis）中。
- 结果：您可以关闭 50 台服务器并打开 50 台新服务器，而无需断开任何用户的连接。这将启用自动缩放（在云中自动缩放）。
4.分层缓存
最快的请求甚至无法到达[数据库1。
- 浏览器缓存：用户的浏览器存储图像和CSS。
- CDN (Cloudflare)：在边缘存储静态内容。
- 应用程序缓存（Redis）：存储频繁查询的结果。
积极的缓存策略是 Reddit 和 Twitter 等网站的秘密。
5. 优雅降级
当规模扩大时，事情将会崩溃。硬盘被烧毁，电缆被切断。 您的系统必须做好部分失败的准备。
- Netflix 示例：如果“个性化推荐”服务出现故障，Netflix 不会出现故障。它显示“热门电影”的静态列表。用户甚至没有意识到后端出现了严重故障。
结论
可扩展性不是您按下的“按钮”。这是一门设计学科。它需要从第一天开始就考虑队列、缓存、故障和分区。如果您在构建软件时假设它会崩溃，那么它的扩展性可能会比您假设一切都会完美运行时要好得多。
另请阅读
- [可扩展的软件架构 - 初创公司的最佳实践2
- [可扩展的软件架构 - 小团队的最佳实践3
- [可扩展的软件架构：如何构建可增长的系统4
- [应用中的微服务：移动分布式架构5
- [单体 vs 微服务：选择哪种架构6
- 【应用架构-企业最佳实践7