網站開發初期，我們習慣性把所有代碼都寫到一個項目中。
前臺、後臺、緩存、數據庫、靜態資源... 等等。
網站系統物理分離
慢慢的系統會原來越大，很顯然需要面對大量用戶的高併發訪問和存儲海量數據。
很多用戶的請求，不可能在一臺服務器上完成。
很多緩存數據，數據庫數據，也不可能在一臺服務器上完成。
這是，網站的伸縮性架構就變得尤爲重要。
如下圖。
原理
我們通過多臺服務器組裝一個整體共同提供服務，通過不斷地向集羣中加入服務器，來緩解不斷上升的
用戶併發訪問壓力和不斷增長的數據存儲需求。
衡量架構伸縮性的主要標準：
-
是否容易向集羣中添加新的服務器。
-
當加入新的服務器，是否可以提供和原來的服務器無差別的服務。
-
集羣中可容納的總的服務器數量是否有限制。
應用服務器集羣
只要服務器上不保存數據，所有的服務器都是對等的，通過負載均衡設備就可以向集羣中增加服務器。
關係型數據庫集羣（MYSQL）
關係型數據庫的集羣伸縮性方案必須在數據庫之外實現，通過路由分區等手段將部署有多個數據的服務器組成一個集羣。
例如：Mysql 等。
非關係型數據庫集羣（NOSQL）
非關係型數據庫先天就是爲海量數據庫準備的，因此對伸縮性的支持非常好。
例如：Redis、Memcache 等等。
緩存服務器集羣
加入新的服務器可能會導致緩存路由失效，進而導致集羣中大部分緩存數據都無法訪問。
部署前需要改進緩存路由算法保證緩存數據的可訪問性。
靜態資源服務器集羣
比如 CSS，JS，Img 等資源進行部署到服務器集羣，降低流量並提高頁面呈現速度。
網站的縱向分離
將業務處理流程上的不同部分進行分離部署，實現系統伸縮性。
如下圖。
網站的橫向分離
將不同業務模塊進行分離部署，實現系統伸縮性。
如下圖。
單一功能通過集羣規模進行伸縮。
將不同功能分離部署可以實現一定程度的伸縮性，但是隨着網站訪問量的逐步增加，即使分離到最新粒度的獨立部署
單一服務器也不能滿足業務規模的要求。
因此，必須使用服務器集羣，即將相同服務部署在多臺服務器上構成一個集羣整體對外服務。
比如：搜索功能。
如果一臺服務器可以提供每秒1000次的請求服務，如果網站高峯期，每秒搜索訪問量爲10000次。
那麼，就需要你部署10臺服務器構成一個集羣。
同理，緩存服務器也會出現這種情況。
事實上，計算一個服務的集羣規模，需要同時考慮其對可用性、性能的影響及關聯服務集羣的影響。
總結
集羣伸縮性，可以分爲應用服務器集羣伸縮性和數據服務器集羣伸縮性。
這兩種集羣由於對數據狀態管理的不同，技術實現也有很大的區別。
大家，可以根據每一種具體的架構設計進行深究。
文章借鑑於書籍《大型網站技術架構》。
