所謂網(wǎng)站的伸縮性是指不需要改變網(wǎng)站的軟硬件設(shè)計， 僅僅通過改變部署的服務器數(shù)量就可以擴大或者縮小網(wǎng)站的服務處理能力。

一般說來，網(wǎng)站的伸縮性設(shè)計可分成兩類

一類是根據(jù)功能進行物理分離實現(xiàn)伸縮，一類是單一功能通過集群實現(xiàn)伸縮。前者是不同的服務器部署不同的服務，提供不同的功能；后者是集群內(nèi)的多臺服務器部署相同的服務，提供相同的功能。

網(wǎng)站架構(gòu)的伸縮性設(shè)計

第一種：不同功能根據(jù)物理分離實現(xiàn)伸縮

一般在網(wǎng)站發(fā)展的早期，新增的服務器總是會從現(xiàn)有的服務器中分離出部分功能和服務。

每次分離都會有更多的服務器加入網(wǎng)站，使用新增的服務器處理某種特定服務。

具體又可分成如下兩種情況。

橫向分離

橫向分離的粒度可以非常小，甚至可以一個關(guān)鍵網(wǎng)頁部署一 個獨立服務，比如對于電商網(wǎng)站非常重要的產(chǎn)品詳情頁面，商鋪頁面，搜索列表頁面，每個頁面都可以獨立部署，專門維護。

第二種：單一功能通過集群規(guī)模實現(xiàn)伸縮

將不同功能分離部署可以實現(xiàn)一 定程度的伸縮性，但是隨著網(wǎng)站訪問量的逐步增加，即使分離到最小粒度的獨立部署，單一的服務器也不能滿足業(yè)務規(guī)模的要求。因此必須使用服務器集群，即將相同服務部署在多臺服務器上構(gòu)成一個集群整體對外提供服務。

應用服務器集群的伸縮性設(shè)計

應用服務器如果是無狀態(tài)的話，也就是說不具備上下文信息存儲，每次請求轉(zhuǎn)發(fā)到任意一臺機器處理的結(jié)果都是一樣的。我們只需要通過請求轉(zhuǎn)發(fā)器按照負載均衡策略進行請求轉(zhuǎn)發(fā)的話，每個請求就可以落在不同服務器上。如果HTTP請求分發(fā)裝置可以感知或者可以配置集群的服務器數(shù)量，可以及時發(fā)現(xiàn)集群中新上線或下線的服務器，并能向新上線的服務器分發(fā)請求，停止向巳下線的服務器分發(fā)請求，那么就實現(xiàn)了應用服務器集群的伸縮性。

這個HTTP請求分發(fā)裝置被稱作負載均衡服務器。我們可以根據(jù)負載均衡去實現(xiàn)網(wǎng)站的伸縮性，也能改善網(wǎng)站的整體可用性。

具體實現(xiàn)的技術(shù)有很多種，但基本都包括以下幾個方面:

1.HTTP重定向負載均衡

利用 HTTP 重定向協(xié)議實現(xiàn)負載均衡。

HTTP 重定向服務器是一臺普通的應用服務器，其唯一 的功能就是根據(jù)用戶的HTTP請求計算一臺真實的 W eb 服務器地址，并將該W eb 服務器地址寫入H TTP 重定向響應中（響應狀態(tài)碼 302 ) 返回給用戶瀏覽器。

在圖 6.5 中 ，瀏覽器請求訪間域 名www.mysite.com, DNS服務器解析得到 IP 地址是 114.100.80.10, 即HTTP 重定向服務器的 IP 地址。然后瀏覽器通過 IP 地址 114.100.80.10 訪間HTTP 重定向負載均衡服務器后，服務器根據(jù)某種負載均衡算法計算獲得一 臺實際物理服務器的地址 (114.100.80.3),構(gòu)造一個包含該實際物理服務器地址的重定向響應返回給瀏覽器，瀏覽器自動重新請求實際物理服務器的IP地址114.100.80.3, 完成訪問。

優(yōu)缺點:

這種負載均衡方案的優(yōu)點是比較簡單。

缺點:

瀏覽器需要兩次請求服務器才能完成一次訪問，性能較差；

重定向服務器自身的處理能力有可能成為瓶頸，

整個集群的伸縮性規(guī)模有限；

使用HTTP302響應碼重定向，有可能使搜索引擎判斷為SEO作弊，降低搜索排名。

很少使用。。。

2 DNS域名解析負載均衡

利用DNS處理域名解析請求的同時進行負載均衡處理的一種方案。

每次域名解析請求都會根據(jù)負載均衡算法計算一個不同的1P地址返回 ，這樣 A 記錄中配置的多個服務器就構(gòu)成一 個集群，并可以實現(xiàn)負載均衡。

優(yōu)點:

DNS域名解析負載均衡的優(yōu)點是將負載均衡的工作轉(zhuǎn)交給DNS,省掉了網(wǎng)站管理維護負載均衡服務器的麻煩，

同時許多DNS還支持基于地理位置的域名解析，即會將域名解析成距離用戶地理最近的一個服務器地址，這樣可加快用戶訪間速度，改善性能。

缺點:

目前的DNS是多級解析，每一級DNS都可能緩存A記錄，當下線某臺服務器后，即使修改了DNS的A記錄，要使其生效也需要較長時間，這段時間，DNS依然會將域名解析到巳經(jīng)下線的服務器，導致用戶訪間失??；而且DNS負載均衡的控制權(quán)在域名服務商那里，網(wǎng)站無法對其做更多改善和更強大的管理。

事實上，大型網(wǎng)站總是部分使用DNS域名解析，利用域名解析作為第一級負載均衡手段，即域名解析得到的一組服務器并不是實際提供Web服務的物理服務器，而是同樣提供負載均衡服務的內(nèi)部服務器，這組內(nèi)部負載均衡服務器再進行負載均衡，將請求分發(fā)到真實的Web服務器上。

3.反向代理負載均衡

利用反向代理服務器進行負載均衡.

利用反向代理緩存資源，以改善網(wǎng)站性能。實際上，在部署位置上，反向代理服務器處于 W eb 服務器前面 （這樣才可能緩存 W eb 響應，加速訪問），這個位置也正好是負載均衡服務器的位置，所以大多數(shù)反向代理服務器同時提供負載均衡的功能，管理一 組W eb 服務器，將請求根據(jù)負載均衡算法轉(zhuǎn)發(fā)到不同Web服務器上。Web服務器處理完成的響應也需要通過反向代理服務器返回給用戶。由于 Web 服務器不直接對外提供訪間，因此Web服務器不需要使用外部IP地址，而反向代理服務器則需要配置雙網(wǎng)卡和內(nèi)部外部兩套 IP地址。

圖6.7中，瀏覽器訪問請求的地址是反向代理服務器的地址114.100.80.10,反向代理服務器收到請求后，根據(jù)負載均衡算法計算得到一臺真實物理服務器的地址 10.0.0.3,并將請求轉(zhuǎn)發(fā)給服務器。10.0.0.3處理完請求后將響應返回給反向代理服務器，反向代理服務器再將該響應返回給用戶。

優(yōu)點是和反向代理服務器功能集成在一起，部署簡單。

缺點是反向代理服務器是所有請求和響應的中轉(zhuǎn)站，其性能可能會成為瓶頸。

類似的還有IP負載均衡、數(shù)據(jù)鏈路負載均衡我就一一概述了。

我們接下來繼續(xù)介紹其他方面的伸縮性架構(gòu)設(shè)計

分布式緩存集群的伸縮性架構(gòu)設(shè)計

關(guān)于分布式緩存，相信大家都有接觸過，當然基本是互聯(lián)網(wǎng)型的公司，不同于我們的服務器集群的伸縮性設(shè)計，分布式緩存集群的伸縮性不能僅僅使用簡單的負載均衡來實現(xiàn)。

我們還需要考慮數(shù)據(jù)一致性和數(shù)據(jù)同步數(shù)據(jù)可用性等問題。

分布式緩存服務器集群中不同服務器中緩存的數(shù)據(jù)各不相同，緩存訪問請求不可以在緩存服務器集群中的任意一臺處理，必須先找到緩存有需要數(shù)據(jù)的服務器，然后才能訪問。這個特點會嚴重制約分布式緩存集群的伸縮性設(shè)計，因為新上線的緩存服務器沒有緩存任何數(shù)據(jù)，而巳下線的緩存服務器還緩存著網(wǎng)站的許多熱點數(shù)據(jù)。

必須讓新上線的緩存服務器對整個分布式緩存集群影響最小，也就是說新加入緩存服務器后應使整個緩存服務器集群中已經(jīng)緩存的數(shù)據(jù)盡可能還被訪問到，這是分布式緩存集群伸縮性設(shè)計的最主要目標。

我們以memcached分布式緩存集群的設(shè)計為例:

應用程序通過Memcached客戶端訪問Memcached服務器集群，Memcached客戶端主要由一組API、Memcached服務器集群路由算法、Memcached服務器集群列表及通信模塊構(gòu)成。

其中路由算法負責根據(jù)應用程序輸入的緩存數(shù)據(jù)KEY計算得到應該將數(shù)據(jù)寫入到Memcached的哪臺服務器（寫緩存）或者應該從哪臺服務器讀數(shù)據(jù)（讀緩存）。

一個典的型緩存寫操作如圖6.10中箭頭所示路徑。應用程序輸入需要寫緩存的數(shù)據(jù)<'BEIJING',DATA>, API將KEY('BEIJING')輸入路由算法模塊，路由算法根據(jù)KEY和Memcached集群服務器列表計算得到一臺服務編號(NODEl),進而得到該機器的IP地址和端口(10.0.0.0:91000)。API調(diào)用通信模塊和編號為NODEl的服務器通信，將數(shù)據(jù)<'BEIJING',DATA>寫入該服務器。完成一次分布式緩存的寫操作。

讀緩存的過程和寫緩存一樣，由于使用同樣的路由算法和服務器列表，只要應用程序提供相同的KEY('BElnNG'),

Memcached客戶端總是訪問相同的服務器(NODEl)去讀取數(shù)據(jù)。只要服務器還緩存著該數(shù)據(jù)，就能保證緩存命中。

memcached分布式緩存集群的伸縮性挑戰(zhàn)

正常的路由算法使用余數(shù)hash，使用服務器下標作為編號，由于hashCode具備隨機性，這時候key的存儲，在整個集群中是比較均衡分布的，當布式緩存集群需要擴容的時候，就比較麻煩了。

簡單來說，就是比如原來有三臺服務器，由于業(yè)務需要，新增加一臺，更改服務器列表，仍舊使用余數(shù)Hash,用4除以key為'BEIJING'的Hash值49080643,余數(shù)為2,對應服務器NODE2。由于數(shù)據(jù)<'BEIJING'J)ATA>緩存在NODEl, 對NODE2的讀緩存操作失敗，緩存沒有命中。

我們可以得出新加入一臺，會導致大概百分之75的緩存不能命中。這時候回去數(shù)據(jù)庫中讀取，如果大量緩存都沒有命中，這時候會發(fā)生緩存穿透，導致大量讀請求去數(shù)據(jù)庫讀，嚴重的會導致數(shù)據(jù)庫宕機。

分布式緩存伸縮性設(shè)計解決的方法

一致性hash算法

具體算法過程為：先構(gòu)造一個長度為0-2的32次方的整數(shù)環(huán)（這個環(huán)被稱作一致性 Hash 環(huán) ），根據(jù)節(jié)點名稱的Hash值（其分布范圍同樣為0-2的32次方 )將緩存服務器節(jié)點放置在這個 Hash環(huán)上。然后根據(jù)需要緩存的數(shù)據(jù)的KEY值計算得到其Hash值（其分布范圍也同樣為0-2的32次方 ), 然后在Hash環(huán)上順時針查找距離這個KEY的Hash值最近的緩存服務器節(jié)點，完成KEY到服務器的Hash映射查找。

假設(shè)NODEI的Hash值為3,594,963,423,NODE2的Hash值為

加入新節(jié)點NODE3后，原來的KEY大部分還能繼續(xù)計算到原來的節(jié)點，只有KEY3、KEYO從原來的NODEl重新計算到NODE3。這樣就能保證大部分被緩存的數(shù)據(jù)還可以繼續(xù)命中。3臺服務器擴容至4臺服務器，可以繼續(xù)命中原有緩存數(shù)據(jù)的概率是75%, 遠高于余數(shù)Hash的25%, 而且隨著集群規(guī)模越大，繼續(xù)命中原有緩存數(shù)據(jù)的概率也逐漸增大，100臺服務器擴容增加1臺服務器，繼續(xù)命中的概率是99%。雖然仍有小部分數(shù)據(jù)緩存在服務器中不能被讀到，但是這個比例足夠小，通過訪問數(shù)據(jù)庫獲取也不會對數(shù)據(jù)庫造成致命的負載壓力。

實現(xiàn)

具體應用中，這個長度為2的32次方的一致性Hash環(huán)通常使用二叉查找樹實現(xiàn)，Hash查找過程實際上是在二叉查找樹中查找不小于查找數(shù)的最小數(shù)值。當然這個二叉樹的最右邊葉子節(jié)點和最左邊的葉子節(jié)點相連接，構(gòu)成環(huán)。

但是，上面描述的算法過程還存在一 個小小的問題？

新加入的節(jié)點NODE3只影響了原來的節(jié)點NODEl, 也就是說一 部分原來需要訪間NODEl的緩存數(shù)據(jù)現(xiàn)在需要訪間NODE3 (概率上是50%)。但是原來的節(jié)點NODEO和NODE2不受影響，這就意味著NODEO和NODE2緩存數(shù)據(jù)量和負載壓力是NODEl與NODE3的兩倍。如果4臺機器的性能是一 樣的，那么這種結(jié)果顯然不是我們需要的。

計算機領(lǐng)域有句話：計算機的任何問題都可以通過增加— 個虛擬層來解決。計算機硬件、計算機網(wǎng)絡(luò)、計算機軟件都莫不如此。計算機網(wǎng)絡(luò)的7層協(xié)議，每一層都可以看作是下一 層的虛擬層；計算機操作系統(tǒng)可以看作是計算機硬件的虛擬層；Java虛擬機可以看作是操作系統(tǒng)的虛擬層；分層的計算機軟件架構(gòu)事實上也是利用虛擬層的概念。

解決上述一 致性Hash 算法帶來的負載不均衡問題，也可以通過使用虛擬層的手段：將每臺物理緩存服務器虛擬為一 組虛擬緩存服務器，將虛擬服務器的Hash值放置在Hash環(huán)上，KEY在環(huán)上先找到虛擬服務器節(jié)點，再得到物理服務器的信息。

這樣新加入物理服務器節(jié)點時，是將一 組虛擬節(jié)點加入環(huán)中，如果虛擬節(jié)點的數(shù)目足夠多，這組虛擬節(jié)點將會影響同樣多數(shù)目的已經(jīng)在環(huán)上存在的虛擬節(jié)點，這些已經(jīng)存在的虛擬節(jié)點又對應不同的物理節(jié)點。最終的結(jié)果是：新加入一 臺緩存服務器，將會較為均勻地影響原來集群中已經(jīng)存在的所有服務器，也就是說分攤原有緩存服務器集群中所有服務器的一 小部分負載，其總的影響范圍和上面討論過的相同。

可以得出結(jié)論哈，每個物理節(jié)點對應的虛擬節(jié)點越多，各個物理節(jié)點之間的負載越均衡，新加入物理服務器對原有的物理服務器的影響保持一致（這就是一致性hash這個名稱的由來）

在實踐中，一般部署一臺物理服務器對應150臺左右的虛擬服務器節(jié)點比較合適。

數(shù)據(jù)庫存儲服務器集群的伸縮性設(shè)計

和緩存服務器集群的伸縮性不同的是，數(shù)據(jù)存儲服務器的集群的伸縮性對數(shù)據(jù)的持久性和可用性會有更高的要求。

緩存的目的是加速數(shù)據(jù)讀取并減輕數(shù)據(jù)存儲服務的負載壓力。因此部分緩存數(shù)據(jù)的丟失不影響業(yè)務的正常處理，因為數(shù)據(jù)還可以從數(shù)據(jù)庫等存儲服務器上處理。

而數(shù)據(jù)存儲服務器則必須保證數(shù)據(jù)的可靠存儲。任何情況下都必須保證數(shù)據(jù)的可用性和正確性。具體又可以分為關(guān)系型數(shù)據(jù)庫集群的伸縮性設(shè)計和NoSQL數(shù)據(jù)庫的伸縮性設(shè)計。

關(guān)系型數(shù)據(jù)庫集群伸縮性設(shè)計

市場上主要的關(guān)系數(shù)據(jù)都支持數(shù)據(jù)復制功能，使用這個功能可以對數(shù)據(jù)庫進行簡伸縮。

讀寫分離

在這種架構(gòu)中 ，雖然多臺服務器部署MySQL實例，但是它們的角色有主從之分，數(shù)據(jù)寫操作都在主服務器上，由主服務器將數(shù)據(jù)同步到集群中其他從服務器，數(shù)據(jù)讀操作及數(shù)據(jù)分析等離線操作在從服務器上進行。

分庫分表

不同業(yè)務數(shù)據(jù)表部署在不同的數(shù)據(jù)庫集群上，即俗稱的數(shù)據(jù)分庫。這種方式的制約條件是跨庫的表不能進行 Join 操作。
分片，將一張表拆開分別存儲在多個數(shù)據(jù)庫中。

目前網(wǎng)站在線業(yè)務應用中比較成熟的支持數(shù)據(jù)分片的分布式關(guān)系數(shù)據(jù)庫產(chǎn)品主要有開源的 Amoeba 和Cobar(http://code.alibabatech.com/wiki/display/cobar/Home) 。這兩個產(chǎn)品有相似的架構(gòu)設(shè)計，以Cobar為例，部署模型如圖 xQ

Cobar是一個分布式關(guān)系型數(shù)據(jù)訪問代理，介于應用服務器和數(shù)據(jù)庫服務器之間，也支持非獨立部署，以lib的方式和應用程序部署在一起。

應用程序通過JDKC驅(qū)動訪問集群，Cobar服務器根據(jù)sql和sql分庫規(guī)則分解sql，然后分發(fā)到MySQL集群上不同的數(shù)據(jù)庫實例上進行（每個Mysql實例都部署為主/從結(jié)構(gòu)，保證數(shù)據(jù)高可用）

如何執(zhí)行？？

前端通信模塊負責和應用程序通信，接收到SQL請求

(select * from users where userid in (12,22,23))

后轉(zhuǎn)交給SQL解析模塊，SQL解析模塊解析獲得SQL中的路由規(guī)則查詢條件(useridin(12,22,23) 轉(zhuǎn)交給SQL路由模塊，SQL路由模塊根據(jù)路由規(guī)則配置(userid為偶數(shù)路由至數(shù)據(jù)庫A, userid為奇數(shù)路由至數(shù)據(jù)庫B)將應用程序提交的SQL分解成兩條

select* from users where userid in (12,22); 

select* from users where userid in (23);

轉(zhuǎn)交給SQL執(zhí)行代理模塊，發(fā)送至數(shù)據(jù)庫A和數(shù)據(jù)庫B分別執(zhí)行。

數(shù)據(jù)庫A和數(shù)據(jù)庫B的執(zhí)行結(jié)果返回至SQL執(zhí)行模塊，通過結(jié)果合并模塊將兩個返回結(jié)果集合并成一個結(jié)果集，最終返回給應用程序，完成在分布式數(shù)據(jù)庫中的一次訪間請求。

那么Cobar如何做集群的伸縮呢？

Cobar的伸縮有兩種： Cobar服務器集群的伸縮和MySQL服務器集群的伸縮。

同步完成時，即新機器中Schem a數(shù)據(jù)和原機器中Schem a數(shù)據(jù)一 致的時候，修改Cobar服務器的路由配置，將這些 Schem a 的 IP 修改為新機器的 IP, 然后刪除原機器中的相關(guān)Schema, 完成 MySQL 集群擴容。

在整個分布式關(guān)系數(shù)據(jù)庫的訪問請求過程中，Cobar服務器處理消耗的時間是很少的，時間花費主要還是在MySQL數(shù)據(jù)庫端，因此應用程序通過Cobar訪間分布式關(guān)系數(shù)據(jù)庫，性能基本和直接訪問關(guān)系數(shù)據(jù)庫相當，可以滿足網(wǎng)站在線業(yè)務的實時處理需求。事實上由于Cobar代替應用程序連接數(shù)據(jù)庫，數(shù)據(jù)庫只需要維護更少的連接，減少不必要的資源消耗，改善性能。

缺點:但由于 Cobar 路由后只能在單一 數(shù)據(jù)庫實例上處理查詢請求，因此無法執(zhí)行跨庫的JOIN操作，當然更不能執(zhí)行跨庫的事務處理。

目前各類分布式關(guān)系數(shù)據(jù)庫解決方案都顯得非常簡陋，限制了關(guān)系數(shù)據(jù)庫某些功能的使用。但是當網(wǎng)站業(yè)務面臨不停增長的海量業(yè)務數(shù)據(jù)存儲壓力時， 又不得不利用分布式關(guān)系數(shù)據(jù)庫的集群伸縮能力，這時就必須從業(yè)務上回避分布式關(guān)系數(shù)據(jù)庫的各種缺點：避免事務或利用事務補償機制代替數(shù)據(jù)庫事務；分解數(shù)據(jù)訪問邏輯避免 JO IN 操作等。

NoSQL數(shù)據(jù)庫的伸縮性設(shè)計

NoSQL, 主要指非關(guān)系型的 、分布式的數(shù)據(jù)庫設(shè)計模式。也有許多專家將NoSQL解讀為NotOnlySQL,表示NoSQL只是關(guān)系數(shù)據(jù)庫的補充，而不是替代方案。一般而言，NoSQL數(shù)據(jù)庫產(chǎn)品都放棄了關(guān)系數(shù)據(jù)庫的兩大重要基礎(chǔ)：以關(guān)系代數(shù)為基礎(chǔ)的結(jié)構(gòu)化查詢語言(SQL)和事務一致性保證 (A CID )。而強化其他一 些大型網(wǎng)站更關(guān)注的特性：高可用性和可伸縮性。

開源社區(qū)有各種 NoSQ L 產(chǎn)品，其支持的數(shù)據(jù)結(jié)構(gòu)和伸縮特性也各不相同，目前看來，應用最廣泛的是 Apache HBase 。

HBase為例

HBase 為可伸縮海量數(shù)據(jù)儲存而設(shè)計，實現(xiàn)面向在線業(yè)務的實時數(shù)據(jù)訪問延遲。HBase的伸縮性主要依賴其可分裂的 HRegion 及可伸縮的分布式文件系統(tǒng)HDFS 實現(xiàn)。

HBase 的整體架構(gòu)如圖

HBase 中， 數(shù)據(jù)以 HRegion 為單位進行管理，也就是說應用程序如果想要訪問一個數(shù)據(jù)，必須先找到HRegion,然后將數(shù)據(jù)讀寫操作提交給 HRegion, 由HRegion完成存儲層面的數(shù)據(jù)操作。每個HRegion中存儲一段Key值區(qū)間[key1_,key2)的數(shù)據(jù).

HRegionServer 是物理服務器，每個HRegionServer上可以啟動多個HRegion實例。當一個HRegion中寫入的數(shù)據(jù)太多，達到配置的闌值時，HRegion 會分裂成兩個 HRegion, 并將 HRegion 在整個集群中進行遷移，以使 HregionServer的負載均衡。

數(shù)據(jù)的寫入如下:

數(shù)據(jù)寫入過程也是一樣，需要先得到HRegion才能繼續(xù)操作，HRegion會把數(shù)據(jù)存儲在若干個叫作HFile格式的文件中，這些文件使用HDFS分布式文件系統(tǒng)存儲，在整個集群內(nèi)分布并高可用。當一個 HRegion 中數(shù)據(jù)量太多時，HRegion (連同HFile)會分裂成兩個 HRegion, 并根據(jù)集群中服務器負載進行遷移，如果集群中有新加入的服務器，也就是說有了新的 HRegion Server, 由于其負載較低，也會把 HRegion 遷移過去并記錄到 HMaster, 從而實現(xiàn) HBase 的線性伸縮。

伸縮性架構(gòu)設(shè)計能力是網(wǎng)站架構(gòu)師必須具備的能力。

一個具有良好伸縮性架構(gòu)設(shè)計的網(wǎng)站，其設(shè)計總是走在業(yè)務發(fā)展的前面，在業(yè)務需要處理更多訪問和服務之前，就巳經(jīng)做好充足準備，當業(yè)務需要時，只需要購買或者租用服務器簡單部署實施就可以了