前言
在單機應用時代汽久，換句話說鹤竭，如果你的應用就部署一個實例，并沒有伸縮性的概念景醇。伸縮性是針對分布式系統(tǒng)的場景下臀稚，才有意義。而且現(xiàn)在的大型分布式系統(tǒng)三痰，對于伸縮性是非常重視的吧寺，因為現(xiàn)在的系統(tǒng)運維都希望機器或容器能夠動態(tài)擴容窜管。比如，淘寶的雙11稚机、京東的618等大型促銷活動幕帆，其流量和壓力都是平時的很多倍，但是總不能要求平時就用這么多的部署資源抒钱，這會很浪費蜓肆，所以動態(tài)擴容就顯得很有必要了。老規(guī)矩谋币，先來定義一下伸縮性仗扬。
定義
系統(tǒng)的性能能夠隨著應用實例數(shù)的加減獲得相匹配的加減的能力。
性能
伸縮性重點描述的是系統(tǒng)性能的彈性蕾额，不是其他的特性早芭，比如系統(tǒng)功能的彈性，比如說很方便增加一個新功能诅蝶。實際上從功能角度描述系統(tǒng)彈性是架構(gòu)決策中的另外一個特性 - 擴展性退个，我們博文會討論到。
應用實例數(shù)
注：這個地方的應用實例不僅僅是表示業(yè)務應用的實例调炬，也表示數(shù)據(jù)庫實例语盈，是一個比較寬泛的叫法。
當我們要增加一個大型分布式系統(tǒng)的整體性能的時候缰泡，我們一般是通過增加一臺物理機刀荒、虛擬機或者容器（Docker），然后在其上部署一個或多個應用實例棘钞。所以伸縮性實際上從上層來看缠借，說的是應用實例的增減；從下層來看宜猜，說的是部署資源的增減泼返。
可能有些同學會有點疑問，難道增加一個實例不就自然會增加系統(tǒng)的性能嗎姨拥？好像有點道理绅喉，但是不盡然。我們來看一個具體的實例垫毙，假設我們選擇需要增加一個應用實例霹疫，首先我們需要確確認的是，分布式應用集群可以隨便的增加實例數(shù)综芥，如果這個業(yè)務應用無狀態(tài)丽蝎，那么這很容易，不會影響路由策略；如果這個業(yè)務有狀態(tài)屠阻，那么就不能很容易的增減了红省，這個時候可能會影響路由策略，甚至會導致數(shù)據(jù)遷移国觉。
我們在上例中說的無狀態(tài)和有狀態(tài)吧恃，實際上簡單來說就是一個應用實例是否能夠被另一個應用實例隨意替換，而不影響業(yè)務邏輯并且無須額外付代價麻诀。如果可以痕寓，那我們稱之為無狀態(tài)；反之蝇闭，稱為有狀態(tài)呻率。比如一個路由代理就是無狀態(tài)的，再比如一個自身管理Session的Web應用就是有狀態(tài)的呻引。所以礼仗，一般情況下，我們設計應用的目標就是使其無狀態(tài)逻悠，這樣能增強其伸縮性元践。
相匹配的
如果集群中有N個應用實例，當增加一個應用實例時童谒，理想情況下单旁，其性能應該是要增加1/N的，但有些時候不一定是一個線性的關(guān)系饥伊。
實例一：自管理Session的Web應用
一個Web應用如果自己管理Session慎恒，那么意味著他是有狀態(tài)的，這個時候要提升集群性能撵渡，不能簡單的增加一個實例了事。比如：
一個用戶登錄到A實例死嗦，這個時候其Session保存在A機器趋距；
后續(xù)又增加了一個H實例；
這個用戶短期內(nèi)再次登錄時越除，必須路由到A實例节腐，不能路由到其他機器去，否則用戶體驗不好摘盆；
一般這個時候翼雀，我們通過特殊的路由策略來解決；或者通過集中化Session服務來處理孩擂。
因此狼渊，這樣的自管理Session的Web應用其伸縮性是不好的。那么我們一般就是將有狀態(tài)的部分分離出去，比如上邊提到的集中化Session服務狈邑。但是城须，其實這樣只是把伸縮性的難度從Web應用轉(zhuǎn)移到了集中化Session服務，因為該服務本身為了滿足高可用米苹，也是分布式部署糕伐，也能可能會存在性能的伸縮要求。但這樣的轉(zhuǎn)移是有意義的蘸嘶，因為我們的業(yè)務應用數(shù)量遠遠大于這種專業(yè)服務（Session服務）良瞧，其對伸縮性的要求更加強烈。
對于這種專業(yè)服務训唱，像集中Session服務褥蚯、數(shù)據(jù)層存儲（MySQL）、服務總線等等這種雪情，其存在的一個重要理由就是專業(yè)的事由專業(yè)的人來做遵岩，這樣最大程度降低了業(yè)務應用的復雜性，提升了業(yè)務應用的某些特性巡通，比如集中Session服務提升業(yè)務應用的伸縮性尘执。至于其自身的伸縮性，一般是通過復雜的內(nèi)部通信宴凉、路由策略以及數(shù)據(jù)冗余等等技術(shù)來實現(xiàn)的誊锭。在此，不詳細展開弥锄，后續(xù)博文以后可能會有所涉及丧靡。
