首先，所謂網(wǎng)站的伸縮性，指不需要改變網(wǎng)站的軟硬件設(shè)計(jì)，僅僅通過改變部署的服務(wù)器數(shù)量就可以擴(kuò)大或者縮小網(wǎng)站的服務(wù)處理能力。在整個互聯(lián)網(wǎng)行業(yè)的發(fā)展?jié)u進(jìn)演化中，最重要的技術(shù)就是服務(wù)器集群，通過不斷地向集群中添加服務(wù)器來增強(qiáng)整個集群的處理能力。

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

1.1 不同功能進(jìn)行物理分離實(shí)現(xiàn)伸縮

　　（1）縱向分離：將業(yè)務(wù)處理流程上得不同部分分離部署，實(shí)現(xiàn)系統(tǒng)的伸縮性；

　　（2）橫向分離：將不同的業(yè)務(wù)模塊分離部署，實(shí)現(xiàn)系統(tǒng)的伸縮性；

1.2 單一功通過集群規(guī)模實(shí)現(xiàn)伸縮

　　使用服務(wù)器集群，即將相同服務(wù)部署在多臺服務(wù)器上構(gòu)成一個集群整體對外提供服務(wù)。具體來說，集群伸縮性又分為應(yīng)用服務(wù)器集群伸縮性和數(shù)據(jù)服務(wù)器集群伸縮性。這兩種集群對于數(shù)據(jù)狀態(tài)管理的不同，技術(shù)實(shí)現(xiàn)也有很大的區(qū)別。

　It is said that?當(dāng)一頭牛拉不動車的時(shí)候，不要去尋找一頭更強(qiáng)壯的牛，而是用兩頭牛來拉車。

二、應(yīng)用服務(wù)器集群的伸縮性設(shè)計(jì)

2.1 應(yīng)用服務(wù)器那點(diǎn)必須知道的事兒

　　（1）應(yīng)用服務(wù)器應(yīng)該被設(shè)計(jì)成無狀態(tài)的，即應(yīng)用服務(wù)器不存儲請求上下文信息；構(gòu)建集群后，每次用戶的請求都可以發(fā)到集群中任意一臺服務(wù)器上處理，任何一臺服務(wù)器的處理結(jié)果都是相同的；

　　（2）HTTP本身是一個無狀態(tài)的連接協(xié)議，為了支持客戶端與服務(wù)器之間的交互，我們就需要通過不同的技術(shù)為交互存儲狀態(tài)，而這些不同的技術(shù)就是Cookie和Session了。

　　（3）HTTP請求的分發(fā)是應(yīng)用服務(wù)器集群實(shí)現(xiàn)伸縮性的核心問題，而負(fù)載均衡服務(wù)器就是HTTP請求的分發(fā)裝置，它是網(wǎng)站必不可少的基礎(chǔ)手段，也被稱為網(wǎng)站的殺手锏之一。

2.2 負(fù)載均衡技術(shù)—網(wǎng)站必不可少的基礎(chǔ)技術(shù)手段

　　負(fù)載均衡的實(shí)現(xiàn)方式多種多樣，從硬件到軟件，從商業(yè)產(chǎn)品到開源產(chǎn)品，應(yīng)有盡有。但是，實(shí)現(xiàn)負(fù)載均衡的基礎(chǔ)技術(shù)不外乎以下幾種：

　　（1）HTTP重定向負(fù)載均衡　　評價(jià)：★★

　　此方案的優(yōu)點(diǎn)是簡單易行，缺點(diǎn)是：

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

　　②重定向服務(wù)器自身的處理能力有可能成為瓶頸，整個集群的伸縮性規(guī)模有限；

　　③使用HTTP 302重定向有可能使搜索引擎判斷為SEO作弊，降低搜索排名；

　　（2）DNS域名解析負(fù)載均衡　　評價(jià)：★★★

　　此方案要求在DNS服務(wù)器中配置多個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

　　此方案的優(yōu)點(diǎn)是將負(fù)載均衡的工作轉(zhuǎn)交給了DNS，省掉了網(wǎng)站管理維護(hù)負(fù)載均衡服務(wù)器的麻煩。而缺點(diǎn)是：

　　①目前的DNS是多級解析，每一級DNS都可能緩存A記錄，當(dāng)某臺服務(wù)器下線后，即使修改了DNS的A記錄，要使其生效仍然需要較長時(shí)間。這段期間，會導(dǎo)致用戶訪問已經(jīng)下線的服務(wù)器造成訪問失敗。

　　②DNS負(fù)載均衡的控制權(quán)在域名服務(wù)商那里，網(wǎng)站無法對其做更多改善和管理；

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

　　（3）反向代理負(fù)載均衡　　評價(jià)：★★★★

　　Web服務(wù)器不需要使用外部IP地址，而反向代理服務(wù)器則需要配置雙網(wǎng)卡和內(nèi)外部兩套IP地址。

　　此方案的優(yōu)點(diǎn)是和反向代理服務(wù)器功能集成在一起，部署簡單。缺點(diǎn)是反向代理服務(wù)器是所有請求和響應(yīng)的中轉(zhuǎn)站，其性能可能會成為瓶頸。

　　（4）IP負(fù)載均衡　　評價(jià)：★★★★

　　此方案優(yōu)點(diǎn)在于在內(nèi)核進(jìn)程完成數(shù)據(jù)分發(fā)，較反向代理負(fù)載均衡（在應(yīng)用程序中分發(fā)數(shù)據(jù)）有更好的處理性能。缺點(diǎn)是由于所有請求響應(yīng)都需要經(jīng)過負(fù)載均衡服務(wù)器，集群的最大響應(yīng)數(shù)據(jù)吞吐量不得不受制于負(fù)載均衡服務(wù)器網(wǎng)卡帶寬。

　　（5）數(shù)據(jù)鏈路層負(fù)載均衡　　評價(jià)：★★★★★

　　此種方式又稱作三角傳輸模式，負(fù)載均衡數(shù)據(jù)分發(fā)過程中不修改IP地址，只修改mac地址，由于實(shí)際處理請求的真實(shí)物理IP地址和數(shù)據(jù)請求目的IP地址一致，所以不需要通過負(fù)載均衡服務(wù)器進(jìn)行地址轉(zhuǎn)換，可將響應(yīng)數(shù)據(jù)包直接返回給用戶瀏覽器，避免負(fù)載均衡服務(wù)器網(wǎng)卡帶寬成為瓶頸。這種負(fù)載均衡方式又稱作直接路由方式（DR）。

　　使用三角傳輸模式的鏈路層負(fù)載均衡是目前大型網(wǎng)站使用最廣泛的一種負(fù)載均衡手段。在Linux平臺上最好的鏈路層負(fù)載均衡開源產(chǎn)品是LVS（Linux Virutal Server）。

2.3 負(fù)載均衡算法—負(fù)載均衡技術(shù)賴以生存的核心

　　前面的方法解決了負(fù)載均衡通過何種方式實(shí)現(xiàn)，而更為重要的則是如何從Web服務(wù)器列表中計(jì)算得到一臺Web服務(wù)器的地址，而這正是負(fù)載均衡的核心—算法。這里簡單介紹一下通常的集中負(fù)載均衡計(jì)算的算法，如果需要深入了解請自行百度。

　　（1）輪詢

　　所有請求被以此分發(fā)到每臺應(yīng)用服務(wù)器上，即每臺服務(wù)器需要處理的請求數(shù)目都相同，適合于所有服務(wù)器硬件都相同的場景。

　　（2）加權(quán)輪詢

　　根據(jù)應(yīng)用服務(wù)器的配置性能的情況，在輪詢的基礎(chǔ)上，按照配置的權(quán)重將請求分發(fā)到每個服務(wù)器，高性能的服務(wù)器能分配更多的請求。

　　（3）隨機(jī)

　　此算法比較簡單實(shí)用，請求被隨機(jī)分配到各個應(yīng)用服務(wù)器，因?yàn)楹玫碾S機(jī)數(shù)本身就很均衡。

　　（4）最少連接

　　記錄每個應(yīng)用服務(wù)器正在處理的連接數(shù)（請求數(shù)），將新到的請求分發(fā)到最少連接的服務(wù)器上，應(yīng)該說，這是最符合負(fù)載均衡定義的算法。

　　（5）源地址散列

　　根據(jù)請求來源的IP地址進(jìn)行Hash計(jì)算得到應(yīng)用服務(wù)器，這樣來自同一個IP地址的請求總在同一個服務(wù)器上處理，該請求的上下文信息可以存儲在這臺服務(wù)器上，在一個會話周期內(nèi)重復(fù)使用，從而實(shí)現(xiàn)會話粘滯。

三、分布式緩存集群的伸縮性設(shè)計(jì)

　　不同于應(yīng)用服務(wù)器集群的伸縮性設(shè)計(jì)，分布式緩存集群的伸縮性不能使用簡單的負(fù)載均衡手段來實(shí)現(xiàn)。因?yàn)?#xff1a;分布式緩存服務(wù)器集群中緩存的數(shù)據(jù)各不相同，緩存訪問請求不可以在緩存服務(wù)器集群中的任意一臺處理，必須先找到緩存有需要的數(shù)據(jù)的服務(wù)器，然后才能訪問。

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

　　（1）以Memcached為代表的分布式緩存集群的訪問模型

　　以上圖片展示了一個典型的緩存寫操作，應(yīng)用程序需要寫緩存數(shù)據(jù)<'CHENGDU',DATA>，API將KEY（'CHENGDU'）輸入路由算法模塊，路由算法根據(jù)KEY和Memcached服務(wù)器集群列表計(jì)算得到一臺服務(wù)器編號（如Node1），進(jìn)而得到該機(jī)器的IP地址和端口（10.0.0.1:91000）。然后，API調(diào)用通信模塊和編號為Node1的Memcached服務(wù)器進(jìn)行通信，將數(shù)據(jù)<'CHENGDU',DATA>寫入該服務(wù)器，至此便完成了一次分布式緩存的寫操作。

　　而讀操作和寫操作一樣，使用同樣的路由算法和服務(wù)器列表，只要提供相同的KEY（如上面提到的'CHENGDU'），Memcached客戶端總是訪問相通的服務(wù)器（如上面計(jì)算得到的Node1）去讀取數(shù)據(jù)。

　　（2）以Memcached為代表的分布式緩存集群的伸縮性挑戰(zhàn)

　　簡單的路由算法（通過使用余數(shù)Hash）無法滿足業(yè)務(wù)發(fā)展時(shí)服務(wù)器擴(kuò)容的需要：緩存命中率下降。例如：當(dāng)3臺服務(wù)器擴(kuò)容至4臺時(shí)，采用普通的余數(shù)Hash算法會導(dǎo)致大約75%（3/4）被緩存了的數(shù)據(jù)無法正確命中，隨著服務(wù)器集群規(guī)模的增大，這個比例會線性地上升。那么，可以想象，當(dāng)100臺服務(wù)器的急群眾加入一臺服務(wù)器，不能命中的概率大概是99%（N/N+1），這個結(jié)果顯然是無法接受的。

　　那么，能否通過改進(jìn)路由算法，使得新加入的服務(wù)器不影響大部分緩存數(shù)據(jù)的正確性呢？請看下面的一致性Hash算法。

　　（3）分布式緩存的一致性Hash算法

說明：一致性Hash算法是分布式緩存的核心理論，這里只是簡單介紹一下，后續(xù)有空我會單獨(dú)寫一篇文章來詳細(xì)介紹一致性Hash算法，以及用C#實(shí)現(xiàn)一致性Hash算法。

　　一致性Hash算法通過一個叫做一致性Hash還的數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)KEY到緩存服務(wù)器的Hash映射，如下圖所示：

　　具體算法過程是：

　　①先構(gòu)造一個長度為0~2^32（2的32次冪）個的整數(shù)環(huán)（又稱：一致性Hash環(huán)），根據(jù)節(jié)點(diǎn)名稱的Hash值將緩存服務(wù)器節(jié)點(diǎn)防置在這個Hash環(huán)中，如上圖中的node1，node2等；

　　②根據(jù)需要緩存的數(shù)據(jù)的KEY值計(jì)算得到其Hash值，如上圖中右半部分的“鍵”，計(jì)算其Hash值后離node2很近；

　　③在Hash環(huán)上順時(shí)針查找距離這個KEY的Hash值最近的緩存服務(wù)器節(jié)點(diǎn)，完成KEY到服務(wù)器的Hash映射查找，如上圖中離右邊這個鍵的Hash值最近的順時(shí)針方向的服務(wù)器節(jié)點(diǎn)是node2，因此這個KEY會到node2中讀取數(shù)據(jù)；

　　當(dāng)緩存服務(wù)器集群需要擴(kuò)容的時(shí)候，只需要將新加入的節(jié)點(diǎn)名稱（如node5）的Hash值放入一致性Hash環(huán)中，由于KEY總是順時(shí)針查找距離其最近的節(jié)點(diǎn)，因此新加入的節(jié)點(diǎn)只影響整個環(huán)中的一部分。如下圖中所示，添加node5后，只影響右邊逆時(shí)針方向的三個Key/Value對數(shù)據(jù)，只占整個Hash環(huán)中的一小部分。

　　因此，我們可以與之前的普通余數(shù)Hash作對比：采用一直性Hash算法時(shí)，當(dāng)3臺服務(wù)器擴(kuò)容到4臺時(shí)，可以繼續(xù)命中原有緩存數(shù)據(jù)的概率為75%，遠(yuǎn)高于普通余數(shù)Hash的25%，而且隨著集群規(guī)模越大，繼續(xù)命中原有緩存數(shù)據(jù)的概率也會隨之增大。當(dāng)100臺服務(wù)器增加1臺時(shí)，繼續(xù)命中的概率是99%。雖然，仍有小部分?jǐn)?shù)據(jù)緩存在服務(wù)器中無法被讀取到，但是這個比例足夠小，通過訪問數(shù)據(jù)庫也不會對數(shù)據(jù)庫造成致命的負(fù)載壓力。

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

　　首先，數(shù)據(jù)存儲服務(wù)器必須保證數(shù)據(jù)的可靠存儲，任何情況下都必須保證數(shù)據(jù)的可用性和正確性。因此，緩存服務(wù)器集群的伸縮性架構(gòu)方案不能直接適用于數(shù)據(jù)庫等存儲服務(wù)器。

　　（1）關(guān)系數(shù)據(jù)庫集群的伸縮性設(shè)計(jì)

　　①市場上主要的關(guān)系數(shù)據(jù)庫都支持?jǐn)?shù)據(jù)復(fù)制功能，使用這個功能可以對數(shù)據(jù)庫進(jìn)行簡單伸縮。下圖顯示了使用數(shù)據(jù)復(fù)制的MySQL集群伸縮性方案：多臺MySQL的角色有主從之分，寫操作都在主服務(wù)器上，由主服務(wù)器將數(shù)據(jù)同步到集群中其他從服務(wù)器。而讀操作及數(shù)據(jù)分析等離線操作都會在從服務(wù)器上完成。

　　②前面提到的業(yè)務(wù)分割模式也可以用在數(shù)據(jù)庫，不同業(yè)務(wù)數(shù)據(jù)表部署在不同的數(shù)據(jù)庫集群上，這就是所謂的“數(shù)據(jù)分庫”；但是其有一個制約條件：跨庫的表無法進(jìn)行Join操作；

　　③在實(shí)際運(yùn)維中，對一些單表數(shù)據(jù)仍然很大的表，例如Facebook的用戶數(shù)據(jù)庫、淘寶的商品數(shù)據(jù)庫等，還需要進(jìn)行分片，將一張表拆分開分別存儲在多個數(shù)據(jù)庫中，這就是所謂的“數(shù)據(jù)分片”；

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

　　首先，NoSQL主要指非關(guān)系的、分布式的數(shù)據(jù)庫設(shè)計(jì)模式。也有許多專家將NoSQL解讀為Not Only SQL，表示NoSQL是關(guān)系數(shù)據(jù)庫的補(bǔ)充，而不是替代方案。一般而言，NoSQL數(shù)據(jù)庫產(chǎn)品都放棄了關(guān)系數(shù)據(jù)庫的兩大重要基礎(chǔ)：①以關(guān)系代數(shù)為基礎(chǔ)的結(jié)構(gòu)化查詢語言（SQL）②事務(wù)的一致性保證（ACID）；與之對應(yīng)的是強(qiáng)化一些大型網(wǎng)站更關(guān)注的特性：高可用性和可伸縮性；

　　開源社區(qū)的NoSQL產(chǎn)品不盡其數(shù)，其支持的數(shù)據(jù)結(jié)構(gòu)和伸縮性特性也各不相同。目前看來，應(yīng)用最廣泛的是Apache HBase。HBase的伸縮性主要依賴于其可分裂的HRegion及可伸縮的分布式文件系統(tǒng)HDFS（如果您不知道HDFS又對HDFS有興趣，可以閱讀我的另一篇博文《不怕故障的海量存儲—HDFS基礎(chǔ)入門》）實(shí)現(xiàn)。

　　上圖是HBase的整體架構(gòu)圖：

　　①HBase中數(shù)據(jù)以HRegion為單位進(jìn)行管理，也就是說應(yīng)用程序如果想要訪問一個數(shù)據(jù)，必須先找到HRegion，然后將數(shù)據(jù)讀寫操作提交給HRegion，由HRegion完成存儲層面的數(shù)據(jù)操作。

　　②每個HRegion中存儲一段Key區(qū)間（例如：[Key1,Key2)）的數(shù)據(jù)，HRegionServer是物理服務(wù)器，每個HRegionServer上可以啟動多個HRegion實(shí)例。當(dāng)一個HRegion中寫入的數(shù)據(jù)太多，達(dá)到配置的閥值時(shí)，HRegion會分裂成兩個HRegion，并將HRegion在整個集群中進(jìn)行遷移，以使HRegionServer的負(fù)載均衡。

　　③所有的HRegion的信息都（例如：存儲的Key值區(qū)間、所在HRegionServer的IP地址和端口號等）記錄在HMaster服務(wù)器上。同時(shí)為了保證高可用，HBase啟動了多個HMaster，并通過ZooKeeper（一個支持分布式一致性的數(shù)據(jù)管理服務(wù)）選舉出一個主服務(wù)器，通過這個主HMaster服務(wù)器獲得Key值所在的HRegionServer，最后請求該HRegionServer上的HRegion實(shí)例，獲得需要的數(shù)據(jù)。其具體的數(shù)據(jù)尋址訪問流程如下圖所示：

五、學(xué)習(xí)小結(jié)

　　在本章的學(xué)習(xí)中，我們了解到要實(shí)現(xiàn)網(wǎng)站的可伸縮性，關(guān)鍵技術(shù)就在于如何構(gòu)建“良好”的服務(wù)器集群。要達(dá)到良好的目標(biāo)，就要求每次擴(kuò)容和減少服務(wù)器時(shí)，對整個網(wǎng)站的影響是最小的，甚至無影響的。伸縮性是復(fù)雜的，沒有通用的、完美的解決方案和產(chǎn)品。一個具有良好伸縮性的網(wǎng)站，其設(shè)計(jì)總是走在業(yè)務(wù)發(fā)展的前面，在業(yè)務(wù)需要處理更多訪問和處理之前，就已經(jīng)做好了充分的準(zhǔn)備，當(dāng)業(yè)務(wù)需要時(shí)，只需要增加服務(wù)器并簡單部署就可以了，技術(shù)團(tuán)隊(duì)便可輕松應(yīng)對了。

　　在本篇的介紹中，有些核心的內(nèi)容比如一致性Hash算法只是進(jìn)行了簡單的介紹，并沒有深入的分析，這個源于我目前對其的理解還只是皮毛。等待我深入學(xué)習(xí)之后，我會抽空寫一篇單獨(dú)介紹一致性Hash算法的博文，并使用C#進(jìn)行一個粗略的實(shí)現(xiàn)，有興趣的朋友敬請期待吧。

　　另外，前面幾篇博文中有些園友提出介紹一些實(shí)踐性質(zhì)的東西，我在這里表示抱歉，因?yàn)楸緯皇菃渭兊刂v解理論，而且也沒有深入地去講解這些理論，只是單純地?cái)U(kuò)展知識面，管中窺豹，一覽大型網(wǎng)站的技術(shù)體系。而我本人也還是一個即將求職和畢業(yè)的學(xué)生，在理論和實(shí)踐上都缺乏相應(yīng)的經(jīng)驗(yàn)，但我會在精讀完本書后去做一些相應(yīng)場景的具體實(shí)踐，比如使用Memcached或Redis構(gòu)建分布式緩存集群，使用Mono在Linux下搭建ASP.NET MVC應(yīng)用環(huán)境，使用高性能的Nginx或Jexus服務(wù)器構(gòu)建反向代理負(fù)載均衡服務(wù)器環(huán)境，使用發(fā)布訂閱模式實(shí)現(xiàn)MS SQL的讀寫分離實(shí)踐等等，如果園友有興趣的話，也可以自行找資料去做相關(guān)實(shí)踐。如果覺得喜歡我的博文，那我只能說敬請期待了（現(xiàn)在時(shí)間寶貴啊，馬上要找工作了，還得復(fù)習(xí)復(fù)習(xí)，再過段時(shí)間畢業(yè)論文的鴨梨又要來了，我勒個去），么么嗒。

參考文獻(xiàn)

　　（1）李智慧，《大型網(wǎng)站技術(shù)架構(gòu)-核心原理與案例分析》，http://item.jd.com/11322972.html

　　（2）老徐的私房菜，《HTTP無狀態(tài)協(xié)議和Session原理》，http://laoxu.blog.51cto.com/4120547/1219699

　　（3）百度百科，《一致性Hash算法》，http://baike.baidu.com/view/1588037.htm

　　（4）charlee，《Memcached完全剖析》，http://kb.cnblogs.com/page/42731/

　　（5）bluishglc，《數(shù)據(jù)庫Sharding的基本思想和切分策略》，http://blog.csdn.net/bluishglc/article/details/6161475

本章思維導(dǎo)圖

來源:http://www.cnblogs.com/edisonchou/p/3851333.html

總結(jié)

以上是生活随笔為你收集整理的《大型网站技术架构》读书笔记之六：永无止境之网站的伸缩性架构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。