網站系統的伸縮性架構最重要的技術手段就是使用服務器集羣功能，通過不斷地向集羣中添加服務器來增強整個集羣的處理能力。“伸”即網站的規模和服務器的規模總是在不斷擴大。
1、網站架構的伸縮性設計
網站的伸縮性設計可以分成兩類，一類是根據功能進行物理分離實現伸縮，一類是單一功能通過集羣實現伸縮。前者是不同的服務器部署不同的服務，提供不同的 功能；後者是集羣內的多臺服務器部署相同的服務，提供相關的功能。
1.1 不同功能進行物理分離實現伸縮
縱向分離：即分層後分離，將業務處理流程上的不同部分分離部署，實現系統伸縮性。
橫向分離：即分割業務後分離，將不同的業務模塊分離部署，實現系統伸縮性。
1.2 單一功能通過你集羣規模實現伸縮
當一頭牛拉不動車的時候，不要去尋找一頭更強壯的牛，而是用兩頭牛來拉車。
集羣伸縮性又分爲應用服務器集羣伸縮性和數據服務器集羣伸縮性。數據服務器集羣也可分爲緩存數據服務器集羣和存儲數據服務器集羣。
2、 應用服務器集羣的伸縮性設計
所謂應用服務器的伸縮性即：HTTP請求分發裝置可以感知或者可以配置集羣的服務器數量，可以及時發現集羣中新上線或下線的服務器，並能向新上線的服務器分發請求 ，停止向已下線的服務器分發請求。這個HTTP請求分發裝置被稱爲負載均衡服務器。
負載均衡是網站必不可少的基礎技術手段，不但可以實現網站的伸縮性，同時還改善網站的可用性，可謂網站的殺手鐗之一。具體的技術實現也多種多樣，從硬件實現到軟件實現， 從商業產品到開源，應有盡有，但實現負載均衡的基礎技術不外以下幾種。
2.1 HTTP重定向負載均衡
HTTP重定向服務器是一臺普通的應用服務器，其唯一的功能就是根據用戶的HTTP請求計算一臺真實的服務器地址，並將真實的服務器地址寫入HTTP重定向響應中（響應狀態嗎302）返回給瀏覽器，然後瀏覽器再自動請求真實的服務器。
這種負載均衡方案的優點是比較簡單，缺點是瀏覽器需要每次請求兩次服務器才能拿完成一次訪問，性能較差；使用HTTP302響應嗎重定向，可能是搜索引擎判斷爲SEO作弊，降低搜索排名。重定向服務器自身的處理能力有可能成爲瓶頸。因此這種方案在實際使用中並不見多。
2.2 DNS域名解析負載均衡
利用DNS處理域名解析請求的同時進行負載均衡是另一種常用的方案。在DNS服務器中配置多個A記錄，如：www.mysite.com IN A 114.100.80.1、www.mysite.com IN A 114.100.80.2、www.mysite.com IN A 114.100.80.3.
每次域名解析請求都會根據負載均衡算法計算一個不同的IP地址返回，這樣A記錄中配置的多個服務器就構成一個集羣，並可以實現負載均衡。
DNS域名解析負載均衡的優點是將負載均衡工作交給DNS，省略掉了網絡管理的麻煩，缺點就是DNS可能緩存A記錄，不受網站控制。
事實上，大型網站總是部分使用DNS域名解析，作爲第一級負載均衡手段，然後再在內部做第二級負載均衡。
2.3 反向代理負載均衡
前面我們已經講過，反向代理可以緩存資源，改善網站性能，事實上，反向代理業可以做負載均衡，如圖所示。
由於反向代理服務器轉發請求在HTTP協議層面，因此也叫應用層負載均衡。優點是部署簡單，缺點是可能成功系統的瓶頸。
2.4 IP負載均衡
IP負載均衡：即在網絡層通過修改請求目標地址進行負載均衡。
用戶請求數據包到達負載均衡服務器後，負載均衡服務器在操作系統內核進行獲取網絡數據包，根據負載均衡算法計算得到一臺真實的WEB服務器地址，然後將數據包的IP地址修改爲真實的WEB服務器地址，不需要通過用戶進程處理。真實的WEB服務器處理完畢後，相應數據包回到負載均衡服務器，負載均衡服務器再將數據包源地址修改爲自身的IP地址發送給用戶瀏覽器。
這裏的關鍵在於真實WEB服務器相應數據包如何返回給負載均衡服務器，一種是負載均衡服務器在修改目的IP地址的同時修改源地址，將數據包源地址改爲自身的IP，即源地址轉換（SNAT），另一種方案是將負載均衡服務器同時作爲真實物理服務器的網關服務器，這樣所有的數據都會到達負載均衡服務器。
IP負載均衡在內核進程完成數據分發，較反向代理均衡有更好的處理性能。但由於所有請求響應的數據包都需要經過負載均衡服務器，因此負載均衡的網卡帶寬成爲系統的瓶頸。
2.5 數據鏈路層負載均衡
顧名思義：數據鏈路層負載均衡是指在通信協議的數據鏈路層修改mac地址進行負載均衡，如下圖：
這種數據傳輸方式又稱作三角傳輸模式，負載均衡數據分發過程中不修改IP地址，只修改目的的mac地址，通過配置真實物理服務器集羣所有機器虛擬IP和負載均衡服務器IP地址一樣，從而達到負載均衡，這種負載均衡方式又稱爲直接路由方式（DR）.
在上圖中，用戶請求到達負載均衡服務器後，負載均衡服務器將請求數據的目的mac地址修改爲真是WEB服務器的mac地址，並不修改數據包目標IP地址，因此數據可以正常到達目標WEB服務器，該服務器在處理完數據後可以經過網管服務器而不是負載均衡服務器直接到達用戶瀏覽器。
使用三角傳輸模式的鏈路層負載均衡是目前大型網站所使用的最廣的一種負載均衡手段。在linux平臺上最好的鏈路層負載均衡開源產品是LVS(linux virtual server)。
2.6 負載均衡算法
負載均衡服務器的實現可以分成兩個部分：
1、根據負載均衡算法和WEB服務器列表計算得到集羣中一臺WEB服務器的地址；
2、將請求數據發送到改地址對應的WEB服務器上。
常用的負載均衡算法如下幾種：
1、輪詢：即將請求依次分發到每臺應用服務器上。
2、加權輪詢：根據應用服務器硬件性能情況，在輪詢的基礎上，安裝配置的權重將請求分發到每個服務器。
3、隨機：將請求隨機分配到各個應用服務器。
4、最少連接：記錄每個服務器正在處理的連接數，將新到的請求分發到最少連接的服務器上。
5、原地址散列：根據請求來源的IP地址進行Hash計算，得到應用服務器，這樣來自同一個IP地址請求總在同一個服務器上處理。
3、分佈式緩存集羣的伸縮性設計
分佈式緩存服務器集羣中不同服務器中緩存的數據不相同，緩存訪問請求不可用在緩存服務器集羣中的任意一臺處理，必須先找到緩存有需要數據的服務器，然後才能訪問。 這個特點會嚴重製約分佈式緩存集羣的伸縮性設計，因爲新上線的緩存服務器沒有緩存數據，而已下線的緩存服務器還緩存着網站的許多熱點數據。
分佈式緩存集羣伸縮性設計的最主要目標即：必須讓新上線的緩存服務器對整個分佈式緩存集羣影響最小，也就是說新加入緩存服務器後應使整個緩存服務器集羣中已經緩存的數據 儘可能還被訪問到。
3.1 memcached分佈式緩存集羣訪問模型
3.2 分佈式緩存的一致性Hash算法
一致性hash算法通過一個叫做一致性hash環的數據結構實現KEY到緩存服務器的Hash映射，如下圖：
如果使用上面數據結構的話，那麼當新添加一臺緩存服務器時，只是影響到了其中一臺緩存服務器，其他兩頭緩存服務器的壓力並沒有得到緩解，因此此方案還是存在問題。 一種替代的方案就是增加一個虛擬層，即把每臺緩存服務器虛擬爲一組服務器（比如3個虛擬網元）平均放到上面的環裏面。這樣當新增加緩存服務器時，把新增加的虛擬網元平均分配 到環中，這樣就能緩解每臺緩存服務器，達到分佈式緩存集羣高伸縮性。
4、數據存儲服務器集羣的伸縮性設計
和緩存服務器集羣的伸縮性設計不同，數據存儲服務器集羣的伸縮性對數據的持久性和可用性提出了更高的要求。具體來說，又可分爲關係數據庫集羣的伸縮性設計和NoSql數據庫的伸縮性設計。
4.1 關係數據庫集羣的伸縮性設計
主要的關係數據庫都支持數據複製功能，使用這個功能可以對數據庫進行簡單伸縮。
另外除了利用數據庫主從讀寫分離外，也可以利用業務分隔模式使不同業務的數據表部署在不同的數據庫集羣上，即俗稱的數據分庫。但是這種方式的制約條件時跨庫不能進行join操作。
在大型網站的實際應用中，即使使用了分庫和主從複製，對一些單表數據任然很大的表還需要進行分片，將一張表拆開分別存儲在多個數據庫中。
目前支持分佈式數據分片的關係數據庫產品主要有開源的Amoeba和Cobar（阿里巴巴），下圖爲Cobar部署模型。
Cobar是一個分佈式關係數據庫訪問代理，介於應用服務器和數據庫服務器之間。應用程序通過JDBC驅動訪問Cobar集羣，Cobar服務器根據SQL和分庫規則分解SQL，分發到MySQL集羣不同 的數據庫實例上執行（每個MySQL實例都部署爲主/從結構，保證數據高可用）。
Cobar系統組件模型如下圖：
前端通信模塊負責和應用程序通信，接搜到SQL請求（select * from users where userid in (12,22,23)）後轉交給SQL解析模塊，SQL解析模塊解析獲得SQL中的路由規則查詢條件（userid in （12,22,23））再轉交給 SQL路由模塊，SQL路由模塊根據路由規則配置（userid爲偶數路由至數據庫A，奇數則路由至數據庫B）將應用程序提交的SQL分解成兩條SQL(select * from users where userid in (12,22)；select * from users where userid in (23))轉交給SQL執行代理模塊，發送至數據庫A和數據庫B分別執行。 數據庫A和數據庫B的執行結果返回至SQL執行模塊，通過結果合併模塊將兩個返回結果集合併成一個結果集，最終返回該應用程序，完成在分佈式關係數據庫中的一次訪問請求。
Cobar的伸縮有兩點：Cobar服務器集羣的伸縮和MySQL服務器集羣的伸縮。
Cobar服務器可以看做是無狀態的應用服務器，因此其集羣伸縮可以簡單實用負載均衡的手段實現。而MySQL中存儲着數據，要保證集羣擴容後數據一致負載均衡，必須要做數據遷移，如下圖（利用數據同步功能進行數據遷移）。
4.2 NoSQL數據庫的伸縮設計
NoSQL主要是指非關係的、分佈式的數據庫設計模式。一般而言，NoSQL數據庫產品都放棄了關係數據庫的兩大重要基礎：以關係代數爲基礎的結構化查詢語言（SQL）和事物一致性保證（ACID），而強化了高可用性和可伸縮性。目前應用最廣泛的是Apache HBase。