大多数应用程序不会因缺乏技术而崩溃。它之所以会崩溃，是因为没有人提前决定当使用量在一周内增加两倍时会发生什么。
可扩展性通常被视为基础设施问题，“只需添加更多机器”。实际上，这是在峰值之前很久就做出的架构、成本和风险决策。当高峰到来时，选择已经给出。你只执行你设计的东西，或者在压力下即兴发挥。
我想捍卫一个简单的想法：良好的扩展不是为了支持负载，而是为了在还有时间的情况下做出可逆的决策。本文末尾的清单可以在市场迫使您做出这些决定之前强制您做出这些决定。
扩展是一项业务决策，然后才是技术决策
在讨论[数据库0或消息队列之前，最不舒服的问题值得问：你真的需要扩展，还是你正在优化一个尚不存在的问题？
工程学天生偏向于解决优雅的挑战。为一千个用户构建分布式架构几乎总是浪费资金和时间。成本不仅仅出现在云账单中，还出现在团队将持续多年的复杂性中。
重要的可扩展性是基于诚实的增长预测。如果企业预计在十二个月内将基数翻倍，就会改变架构。如果期望每年增长 10%，也许更大的服务器可以在很长一段时间内实现这一目标，这没关系。
最常见的战略错误不是规模过小。它的扩展太快了，在没有人要求的稳健性上投入了精力，而该产品还没有证明它值得存在。
真正的瓶颈几乎不在你所看到的地方
当应用程序在负载下崩溃时，本能地会查看应用程序服务器。在实践中，瓶颈通常出现在[数据库1]、写得不好的查询中，或者应该是异步的同步操作中。
一个经典案例：系统在测试中响应良好，但在生产中性能下降，因为每个请求都会触发对数据库的三个冗余查询。没有额外的服务器可以解决这个问题，它只是将问题隐藏了几个月，而且成本不断增加。
因此，缩放从测量开始。如果没有[可观察性2]、指标、结构化日志、请求跟踪，你只能猜测。生产中的猜测成本高昂。
垂直和水平缩放：顺序很重要
垂直扩展（更大的机器）很简单，并且在一开始就解决了很多问题。它有上限和成本，但它避免了过早的复杂性。水平扩展（更多实例）更强大，但需要为此设计应用程序：本地内存中不存储任何状态，具有外部化会话和幂等进程。
健康的顺序往往是：优化现有内容，在有意义的情况下垂直扩展，然后再进行分发。跳过步骤就像在不知道是否有人会去看演出之前就雇用了一个管弦乐队。
状态、缓存和数据库是单一痛点
最难扩展的组件几乎总是[数据库3，因为它存储状态并且状态不能免费复制。
只读副本、内存缓存以及读写操作分离等策略可以缓解压力。每个都会带来一个权衡：过时的缓存、最终一致性、操作复杂性。没有权衡就没有规模。在最糟糕的时刻有意识地选择或发现一些权衡。
尤其是缓存，它是最常见的双刃剑。应用得当，可以减轻负载并改善体验。如果应用不当，它会以非常高的效率提供错误的数据。正确的问题从来不是“我们缓存了吗？”，而是“这些数据可以过期多长时间而不造成损坏？”。
成本、安全性和连续性发挥作用
扩展有一个很少出现在技术讨论中的方面：财务方面。弹性云架构可以无限增长，包括发票。我见过不止一个运营部门后来发现系统扩展得很好，但预算却没有。
还有安全性和合规性维度。分发应用程序会增加攻击面并将数据传播到更多地方。在巴西的背景下，这直接涉及到[LGPD4]：更多的副本和更多的缓存意味着更多的个人数据存在和需要保护的点。没有数据治理的规模是一种随着流量而增长的风险。
并且有连续性。一个可扩展但没有灾难恢复计划的系统只会在更大范围内发生故障。弹性和可扩展性是近亲，而不是同义词。
攀登前的检查清单
使用此清单作为决策过滤器。如果你不能回答大部分问题，那么问题就不是能力问题，而是清晰度问题。
- 增长预测： 未来 6 至 12 个月是否有合理的需求预测？
- **可观察性：**你能通过数据而不是猜测来确定瓶颈在哪里吗？
- 已知瓶颈： 是否映射了当前饱和点（bank、CPU、I/O、外部集成）？
- **外部化状态：**会话、文件和缓存是否位于应用程序的本地内存之外？
- **基础准备：**是否有读/写策略、修订的索引和数据增长计划？
- **异步操作：**繁重的任务离开了请求的同步路径？
- 负载测试： 在实际活动之前是否测量了压力行为？
- 建模成本： 您知道扩展成本是多少以及是否配置了支出限制/警报？
- 安全性和 [LGPD5 : 是否针对攻击面和个人数据保护对扩展进行了评估？
- **恢复计划：**如果扩展策略失败，是否有返回路线？
可扩展性的文化陷阱
最被低估的风险不是技术风险，而是文化风险。团队爱上了“为数百万人”构建的想法，并花费数月时间为可能永远不会到来的规模做准备。这是由自豪感而非必要性驱动的工程。
相反的情况也会发生：组织忽视这个问题，直到系统在关键时刻、活动、发布、季节性高峰崩溃。然后，决策是在黑暗中、在压力下、以尽可能最坏的代价做出的。
成熟是找到中间点：规划合理的增长，保持进化路径开放，而不是为明天的规模付出今天的代价。从本质上讲，良好的可扩展性是推迟不可逆转决策的艺术，直到您拥有足够的信息来做出正确的决策。
还值得记住的是，可扩展性不仅仅是一个软件问题；它也是一个问题。这是一个组织问题。一个可扩展的系统需要一个知道如何在压力下运行的团队、事件响应流程以及了解月底成本报表的人员。如果在高峰时刻没有人知道谁激活什么，那么拥有弹性架构就没有意义。规模的技术部分通常是最容易解决的；人性和操作部分是将那些安全成长的人和那些在恐惧中成长的人区分开来的。
如果您的组织即将发展，但没有人能够自信地说负载加倍时会发生什么，那么现在是时候讨论了，在高峰之前，而不是高峰期间。博客上还有其他有关架构、性能和产品决策的文本，有助于分解此清单上的每个项目。
另请阅读
- [应用架构：可扩展系统完整指南6
- 【应用扩展：成长者的策略与真实案例7
- [应用程序可扩展性：完整的技术指南8
- [负载测试：它们是什么以及为什么您的系统应该在客户之前执行这些测试9
- [可扩展的软件架构：如何构建可扩展的系统10
- [如何扩展应用程序 - 与扩展的比较11