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