每个初创公司和每个技术经理都有一个危险的梦想：产品“病毒式传播”并立即吸引数百万用户的那一天。这个梦想通常会变成一场噩梦，因为支撑一千人的系统在十万人之下就崩溃了，而就在每个用户都值钱的时候。
可扩展性是指系统满足需求增长而不会出现故障且成本不会不可持续地爆炸的能力。显然每个人都应该得到它。但事实更为微妙：在错误的时间攀登与根本不攀登一样有害。
本文提供了通过真实案例说明的可扩展性策略，最重要的是，有助于回答重要的业务问题：何时值得投资扩展以及投资多少。因为可扩展性不是技术目标，而是资源分配决策。
可扩展性的真正含义是什么
规模化不仅仅是“容忍更多的人”。这意味着支持更多的人，同时保持可接受的绩效，并且成本与收入成比例增长或更好。一个用户数量翻倍、成本翻两番的系统不能很好地扩展，它正在流血。
有两种经典的成长方式。 垂直规模是为了放入更强大的机器：简单，但有屋顶和脸。 水平规模是在多台机器之间分配负载：设计更复杂，但范围更大。云使水平访问变得容易，但它需要从早期阶段就为其设计应用程序。
底线是，可扩展性首先是早期做出的架构决策，以及在正确的时间做出的投资决策。
真实案例说明策略
数据库瓶颈的情况
增长的产品中最常见的模式：应用程序可以处理它，但[数据库0成为瓶颈。一切都经过它，当交通量增加时，它就会堵塞。
解决这个问题的策略通常是一个组合：添加一个缓存层来服务频繁的数据，而不用每次请求都占用存储空间，并优化较重的查询。在许多情况下，仅仅放置一个位置良好的缓存就需要花费数年的时间。学习内容：在重写所有内容之前，找到真正的瓶颈。它几乎总是特定的和本地化的，而不是整个系统。
可预测峰值的情况
想一想季节性活动、项目注册、申报截止日期、学校招生的政府系统。它全年有效，并在截止日期当天崩溃，当时每个人都在同一时间访问它。
这里的策略是弹性扩展：在高峰时自动增加容量并在以后减少容量，仅在需要时支付额外的基础设施费用。处理队列也有帮助，可以吸收大量的请求并以可持续的速度进行处理。经验教训：对于可预测的峰值，提前计划弹性并在前一天而不是当天测试负载。
停止增长的架构案例
许多产品作为单个代码块（整体）增长，并且在某个时刻，任何更改都会变得危险且缓慢，因为一切都是耦合的。团队无法再快速交付。
经常讨论的策略是将关键部分分解为独立的服务（[微服务1]），这些服务分别扩展和发展。但是，这是最重要的学习，微服务带来了巨大的操作复杂性。太多的团队过早地打破了整体，并造成了比最初问题更严重的分布式混乱。正确的决定取决于团队的规模和真正的痛苦，而不是建筑时尚。
成本随用户增加的情况
一种较少评论但常见的模式：应用程序在技术上可以很好地扩展，可以在不崩溃的情况下处理增长，但即使如此，它也成为一个问题，因为云账单的增长速度快于收入的增长速度。系统有效；财务模型则不然。
当团队只专注于“承担重担”而忽视效率时，就会发生这种情况。超大资源一直在运行，被遗忘的测试环境已打开，数据被不必要地移动。纠正策略涉及云中的成本治理：监控每个组件的费用，关闭未使用的组件，弹性扩展并根据成本（而不仅仅是性能）审查架构。教训：忽视单位成本的可扩展性是一个只出现在发票上的陷阱，当它出现时，它已经蚕食了利润。
业务问题：何时扩展？
这是决定的核心，也是大多数人都错误的地方。
过早扩展会消耗现金和时间。该初创公司花费数月时间构建复杂的分布式架构，以支持尚不存在或可能永远不存在的数百万用户。最好把精力花在弄清楚该产品是否对任何人都很重要。过早的优化是摧毁一家公司最优雅的方式之一。
扩展得太晚会在最大机会的时刻导致系统瘫痪。产品流行起来，需求到来，但基础设施却无法应对。获取成本高昂的用户第一次遇到错误屏幕后就消失了。增长窗口关闭。
成熟的平衡是：设计时既不阻碍未来的增长，又不提前构建增长。在实践中，这意味着选择不会让你陷入困境的基础、使用云、解耦那些便宜的解耦、监控以发现瓶颈的到来，但推迟昂贵的复杂性，直到数字证明它是合理的。
没有人把风险放在幻灯片上
第一个风险是成本。在没有治理的情况下在云中进行扩展在月底将成为一项可怕的账单。配置不当的弹性可能会悄然增加费用。没有成本控制的可扩展性正在将一个问题换成另一个问题。
二是操作复杂性。每添加一层、缓存、队列、多个服务，都是一件可能失败的事情，需要有人理解、监控和维护。架构过于复杂的小团队花在救火上的时间比交付价值的时间还要多。
三是相信计划而不进行测试。认为系统可以扩展是因为图表所示是一种错觉。只有在峰值发生之前模拟峰值的负载测试才能揭示实际断裂的位置。未经测试的可扩展性是希望，而不是工程。
攀登得好意味着在正确的时间攀登
良好的可扩展性并不是最复杂的。这是最适合产品的时刻和团队规模的。当你有数百万人时，为数百万人建造建筑是浪费；当数百万人到来时只为数百人建造建筑是一种疏忽。
真实的案例教导了一种模式：找到具体的瓶颈，解决现在存在的问题，为未来的增长奠定基础，而无需预先付出代价。可持续增长是一系列适时的决策，而不是一次巨大的投机性飞跃。
对于那些做出决定的人来说，最好的问题不是“我的系统会扩展吗？”，而是“下一个让我崩溃的瓶颈是什么，它什么时候到来？”。回答这个问题可以将可扩展性从抽象的恐惧转变为具体的投资计划。
如果您的应用程序正在增长，并且您感觉某些东西将会出现问题，那么在开始重大重新设计之前，有必要先找出瓶颈和成本。这里还有其他关于云架构和基础设施的文章，深入探讨了这些策略，我可以讨论他们的应用程序案例。
另请阅读
- [应用程序可扩展性：发展前的策略和清单2
- [应用程序可扩展性：完整的技术指南3
- [应用程序架构：可扩展系统完整指南4
- [应用程序可扩展性：策略和快速指南5
- [应用程序的云计算：当您的产品驻留在云端时会发生什么变化6?
- [电子商务可扩展性：策略和基础知识7