现代应用程序不断变化，随着新要求的发展而发展，并且存在于对资源的不同需求的环境中。扩展应用程序可以根据资源需求适当调整其大小，以确保客户满意并降低基础设施成本。

如果您不知道如何有效地扩展，您不仅会损害您的应用程序，还会给您的运营团队带来不必要的压力。手动尝试确定何时扩大或扩大规模非常困难。如果您购买更多基础设施来适应高峰流量，那么当负载不是高峰时，您可能会超支。如果您以平均负载为目标，流量高峰将影响您的应用程序性能，并且当流量下降时，这些资源将被闲置。

什么是纵向扩展与横向扩展

横向扩展(「Scale-out」)或水平缩放与纵向扩展(「Scale-up」)或垂直缩放形成对比。

扩展云资源的想法可能很直观。随着您的云工作负载发生变化，可能需要增加基础架构以支持增加的负载，或者在需求低时减少基础架构可能是有意义的。“向上或向外”部分可能不太直观。横向扩展是并行添加更多等效功能组件以分散负载。这将从两个负载平衡的 Web 服务器实例变为三个实例。相比之下，扩大规模是使组件更大或更快以处理更大的负载。这会将您的应用程序移动到具有 2 个 CPU 的虚拟服务器 (VM) 到具有 3 个 CPU 的虚拟服务器。缩减则相反。

两个比喻

火车动力

传统火车和动车。传统的存储Scale-up架构的存储就好像传统的火车一样，当后面的磁盘越挂越多的时候，控制器性能以及背板带宽却不能相应提升，因此传统存储在磁盘容量扩容到一定程度时候，往往性能下降。

集群存储就好像新一代的动车组火车一样，当火车车厢增加的时候，前面的火车头动力也随之增加，因此不会发生性能瓶颈。

所谓动车组的设计理念和传统火车设计理念的最大区别在于传统火车主要动力来自于火车头(就像传统模块化阵列的两个控制器)，而动车组则不一样，除了车头配有动力装置外，每一节车厢都配有动力推动装置。集群存储大多都是由一个个节点(X86 服务器)组成，每一个节点添加进去后，不仅能够添加容量，还能够添加整个存储器的整体处理能力。

鱼缸启示

其实我认为Scale-out和Scale-up的概念可以用一个简单的例子来解释。

不知您有没有养过鱼? 当你只有六七条鱼的时候，一个小型鱼缸就够了;可是过一段时间新生了三十多条小鱼，这个小缸显然不够大了。

如果用Scale-up解决方案，那么你就需要去买一个大缸，把所有沙啊、水草啊、布景啊、加热棒、温度计都从小缸里拿出来，重新布置到大缸。这个工程可不简单哦，不是十分钟八分钟能搞得定的，尤其水草，纠在一起很难分开(不过这跟迁移数据的工程复杂度比起来实在是毛毛雨啦，不值一提)。

那么现在换个思路，用Scale-out方案，就相当于是你在这个小缸旁边接了一个同样的小缸，两个缸联通。鱼可以自动分散到两个缸，你也就省掉了上面提到的那一系列挪沙、水草、布景等的折腾了。

回到存储架构。用户在采购之初很难准确预测未来数据增长的速度和总量。用户往往不得不采购比自己目前实际需求容量更大的存储，这就导致两个问题，一是预算的浪费，很多存储空间都是为未来数据增长采购的，花了10TB的钱，但是可能只利用上了5TB，另5TB的资金都白白放在那里。另一个问题是，随着时间推移，数据增长，数据量超过了10TB。

按照过去Scale-up的理念，解决方案就是购买更大容量的存储，那么难免面临数据迁移的问题，用户必须停机迁移数据，意味着服务的中断。而Scale-out架构解决了这个矛盾。用户按需采购存储，一旦容量不够了，再购置一台接到原有存储上就可以了。

举个例子

常见的存储设备扩展案例，下图展示了scale-out存储方案的架构。在图中，系统只能通过增加具有完整功能的节点进行扩展，但一个scale-out系统可以有很多节点，而且节点之间的内部物理互联距离也可以很远。

Scale-up，即纵向扩展架构。从下面的拓扑图我们可见，纵向扩展是利用现有的存储系统，通过不断增加存储容量来满足数据增长的需求。

究竟选择scale-up还是scale-out架构,主要考虑以下因素：

在选择scale-up还是scale-out的时候，我们要考虑大量的因素。而结果往往取决于哪个厂商有比其他人更好的整体方案、实施能力和技术优势。但我们最好从了解最基本的信息起步，了解这两种技术及其之间的差别。