谈到系统的可伸缩性，Scale-up（纵向扩展）和Scale-out（横向扩展）是两个常见的术语。
其实我认为Scale-out和Scale-up的概念可以用一个简单的例子来解释。
不知您有没有养过鱼?当你只有六七条鱼的时候，一个小型鱼缸就够了;可是过一段时间新生了三十多条小鱼，这个小缸显然不够大了。
如果用Scale-up解决方案，那么你就需要去买一个大缸，把所有沙啊、水草啊、布景啊、加热棒、温度计都从小缸里拿出来，重新布置到大缸。这个工程可不简单哦，不是十分钟八分钟能搞得定的，尤其水草，纠在一起很难分开(不过这跟迁移数据的工程复杂度比起来实在是毛毛雨啦，不值一提)。
那么现在换个思路，用Scale-out方案，就相当于是你在这个小缸旁边接了一个同样的小缸，两个缸联通。鱼可以自动分散到两个缸，你也就省掉了上面提到的那一系列挪沙、水草、布景等的折腾了。
回到存储架构。用户在采购之初很难准确预测未来数据增长的速度和总量。用户往往不得不采购比自己目前实际需求容量更大的存储，这就导致两个问题，一是预算的浪费，很多存储空间都是为未来数据增长采购的，花了10TB的钱，但是可能只利用上了5TB，另5TB的资金都白白放在那里。另一个问题是，随着时间推移，数据增长，数据量超过了10TB。
按照过去Scale-up的理念，解决方案就是购买更大容量的存储，那么难免面临数据迁移的问题，用户必须停机迁移数据，意味着服务的中断。而Scale-out架构解决了这个矛盾。用户按需采购存储，一旦容量不够了，再购置一台接到原有存储上就可以了。
=========================================================
你有一台API服务器，每天几百万次请求，吃不消了。现在要提升性能：
横向扩展：多增加几台API服务器，一起服务。
纵向扩展：把API服务器换成性能更好的机器。