網站開發初期，我們習慣性把所有代碼都寫到一個項目中。

前臺、后臺、緩存、數據庫、靜態資源... 等等。

網站系統物理分離

慢慢的系統會原來越大，很顯然需要面對大量用戶的高并發訪問和存儲海量數據。

很多用戶的請求，不可能在一臺服務器上完成。

很多緩存數據，數據庫數據，也不可能在一臺服務器上完成。

這是，網站的伸縮性架構就變得尤為重要。

如下圖。

原理

我們通過多臺服務器組裝一個整體共同提供服務，通過不斷地向集群中加入服務器，來緩解不斷上升的用戶并發訪問壓力和不斷增長的數據存儲需求。

衡量架構伸縮性的主要標準：

• 是否容易向集群中添加新的服務器。
• 當加入新的服務器，是否可以提供和原來的服務器無差別的服務。
• 集群中可容納的總的服務器數量是否有限制。

應用服務器集群

只要服務器上不保存數據，所有的服務器都是對等的，通過負載均衡設備就可以向集群中增加服務器。

關系型數據庫集群(MYSQL)

關系型數據庫的集群伸縮性方案必須在數據庫之外實現，通過路由分區等手段將部署有多個數據的服務器組成一個集群。

例如：Mysql 等。

非關系型數據庫集群(NOSQL)

非關系型數據庫先天就是為海量數據庫準備的，因此對伸縮性的支持非常好。

例如：Redis、Memcache 等等。

緩存服務器集群

加入新的服務器可能會導致緩存路由失效，進而導致集群中大部分緩存數據都無法訪問。

部署前需要改進緩存路由算法保證緩存數據的可訪問性。

靜態資源服務器集群

比如 CSS，JS，Img 等資源進行部署到服務器集群，降低流量并提高頁面呈現速度。

網站的縱向分離

將業務處理流程上的不同部分進行分離部署，實現系統伸縮性。

如下圖。

網站的橫向分離

將不同業務模塊進行分離部署，實現系統伸縮性。

如下圖。

單一功能通過集群規模進行伸縮。

將不同功能分離部署可以實現一定程度的伸縮性，但是隨著網站訪問量的逐步增加，即使分離到***粒度的獨立部署單一服務器也不能滿足業務規模的要求。

因此，必須使用服務器集群，即將相同服務部署在多臺服務器上構成一個集群整體對外服務。

比如：搜索功能。

如果一臺服務器可以提供每秒1000次的請求服務，如果網站高峰期，每秒搜索訪問量為10000次。

那么，就需要你部署10臺服務器構成一個集群。

同理，緩存服務器也會出現這種情況。

事實上，計算一個服務的集群規模，需要同時考慮其對可用性、性能的影響及關聯服務集群的影響。

總結

集群伸縮性，可以分為應用服務器集群伸縮性和數據服務器集群伸縮性。

這兩種集群由于對數據狀態管理的不同，技術實現也有很大的區別。

大家，可以根據每一種具體的架構設計進行深究。

文章借鑒于書籍《大型網站技術架構》。