談到系統的可伸縮性，Scale-up（縱向擴展）和Scale-out（橫向擴展）是兩個常見的術語。
其實我認為Scale-out和Scale-up的概念可以用一個簡單的例子來解釋。
不知您有沒有養過魚?當你只有六七條魚的時候，一個小型魚缸就夠了;可是過一段時間新生了三十多條小魚，這個小缸顯然不夠大了。
如果用Scale-up解決方案，那么你就需要去買一個大缸，把所有沙啊、水草啊、布景啊、加熱棒、溫度計都從小缸里拿出來，重新布置到大缸。這個工程可不簡單哦，不是十分鍾八分鍾能搞得定的，尤其水草，糾在一起很難分開(不過這跟遷移數據的工程復雜度比起來實在是毛毛雨啦，不值一提)。
那么現在換個思路，用Scale-out方案，就相當於是你在這個小缸旁邊接了一個同樣的小缸，兩個缸聯通。魚可以自動分散到兩個缸，你也就省掉了上面提到的那一系列挪沙、水草、布景等的折騰了。
回到存儲架構。用戶在采購之初很難准確預測未來數據增長的速度和總量。用戶往往不得不采購比自己目前實際需求容量更大的存儲，這就導致兩個問題，一是預算的浪費，很多存儲空間都是為未來數據增長采購的，花了10TB的錢，但是可能只利用上了5TB，另5TB的資金都白白放在那里。另一個問題是，隨着時間推移，數據增長，數據量超過了10TB。
按照過去Scale-up的理念，解決方案就是購買更大容量的存儲，那么難免面臨數據遷移的問題，用戶必須停機遷移數據，意味着服務的中斷。而Scale-out架構解決了這個矛盾。用戶按需采購存儲，一旦容量不夠了，再購置一台接到原有存儲上就可以了。
=========================================================
你有一台API服務器，每天幾百萬次請求，吃不消了。現在要提升性能：
橫向擴展：多增加幾台API服務器，一起服務。
縱向擴展：把API服務器換成性能更好的機器。