前言
在單機應用時代，換句話說，如果你的應用就部署一個實例，並沒有伸縮性的概念。伸縮性是針對分佈式系統的場景下，在有意義。而且現在的大型分佈式系統，對於伸縮性是非常重視的，因爲現在的系統運維都希望機器或容器能夠動態擴容。比如，淘寶的雙11、京東的618等大型促銷活動，其流量和壓力都是平時的很多倍，但是總不能要求平時就用這麼多的部署資源，這會很浪費，所以動態擴容就顯得很有必要了。老規矩，先來定義一下伸縮性。
定義
系統的性能能夠隨着應用實例數的加減獲得相匹配的加減的能力。
性能
伸縮性重點描述的是系統性能的彈性，不是其他的特性，比如系統功能的彈性，比如說很方便增加一個新功能。實際上從功能角度描述系統彈性是架構決策中的另外一個特性 - 擴展性，我們博文會討論到。
應用實例數
注：這個地方的應用實例不僅僅是表示業務應用的實例，也表示數據庫實例，是一個比較寬泛的叫法。
當我們要增加一個大型分佈式系統的整體性能的時候，我們一般是通過增加一臺物理機、虛擬機或者容器（Docker），然後在其上部署一個或多個應用實例。所以伸縮性實際上從上層來看，說的是應用實例的增減；從下層來看，說的是部署資源的增減。
可能有些同學會有點疑問，難道增加一個實例不就自然會增加系統的性能嗎？好像有點道理，但是不盡然。我們來看一個具體的實例，假設我們選擇需要增加一個應用實例，首先我們需要確確認的是，分佈式應用集羣可以隨便的增加實例數，如果這個業務應用無狀態，那麼這很容易，不會影響路由策略；如果這個業務有狀態，那麼就不能很容易的增減了，這個時候可能會影響路由策略，甚至會導致數據遷移。
我們在上例中說的無狀態和有狀態，實際上簡單來說就是一個應用實例是否能夠被另一個應用實例隨意替換，而不影響業務邏輯並且無須額外付代價。如果可以，那我們稱之爲無狀態；反之，稱爲有狀態。比如一個路由代理就是無狀態的，再比如一個自身管理Session的Web應用就是有狀態的。所以，一般情況下，我們設計應用的目標就是使其無狀態，這樣能增強其伸縮性。
相匹配的
如果集羣中又N個應用實例，當增加一個應用實例時，理想情況下，其性能應該是要增加1/N的，但有些時候不一定是一個線性的關係。
實例一：自管理Session的Web應用
一個Web應用如果自己管理Session，那麼意味着他是有狀態的，這個時候要提升集羣性能，不能簡單的增加一個實例了事。比如：
- 一個用戶登錄到A實例，這個時候其Session保存在A機器；
- 後續又增加了一個H實例；
- 這個用戶短期內再次登錄時，必須路由到A實例，不能路由到其他機器去，否則用戶體驗不好；
- 一般這個時候，我們通過特殊的路由策略來解決；或者通過集中化Session服務來處理。
因此，這樣的自管理Session的Web應用其伸縮性是不好的。那麼我們一般就是將有狀態的部分分離出去，比如上邊提到的集中化Session服務。但是，其實這樣只是把伸縮性的難度從Web應用轉移到了集中化Session服務，因爲該服務本身爲了滿足高可用，也是分佈式部署，也能可能會存在性能的伸縮要求。但這樣的轉移是有意義的，因爲我們的業務應用數量遠遠大於這種專業服務（Session服務），其對伸縮性的要求更加強烈。
對於這種專業服務，像集中Session服務、數據層存儲（MySQL）、服務總線等等這種，其存在的一個重要理由就是專業的事由專業的人來做，這樣最大程度降低了業務應用的複雜性，提升了業務應用的某些特性，比如集中Session服務提升業務應用的伸縮性。至於其自身的伸縮性，一般是通過複雜的內部通信、路由策略以及數據冗餘等等技術來實現的。在此，不詳細展開，後續博文以後可能會有所涉及。