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

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

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

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

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

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

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

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

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

（1）應(yīng)用服務(wù)器應(yīng)該被設(shè)計成無狀態(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ù)器集群實現(xiàn)伸縮性的核心問題历等，而負載均衡服務(wù)器就是HTTP請求的分發(fā)裝置，它是網(wǎng)站必不可少的基礎(chǔ)手段辟癌，也被稱為網(wǎng)站的殺手锏之一寒屯。

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

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

（1）HTTP重定向負載均衡評價：★★

此方案的優(yōu)點是簡單易行要出，缺點是：

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

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

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

（2）DNS域名解析負載均衡評價：★★★

　　此方案要求在DNS服務(wù)器中配置多個A記錄囱挑，例如：

www.mysite.com IN A114.100.80.1

www.mysite.com IN A114.100.80.2

www.mysite.com IN A114.100.80.3

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

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

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

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

（3）反向代理負載均衡評價：★★★★

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

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

（4）IP負載均衡評價：★★★★

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

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

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

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

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

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

　《脑（1）輪詢

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

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

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

　∏Ч帷（3）隨機

　　此算法比較簡單實用，請求被隨機分配到各個應(yīng)用服務(wù)器搞坝，因為好的隨機數(shù)本身就很均衡搔谴。

　　（4）最少連接

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

（5）源地址散列

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

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

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

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

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

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

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

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

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

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

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

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

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

　　具體算法過程是：

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

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

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

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

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

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

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

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

　　①市場上主要的關(guān)系數(shù)據(jù)庫都支持數(shù)據(jù)復(fù)制功能笤妙，使用這個功能可以對數(shù)據(jù)庫進行簡單伸縮冒掌。下圖顯示了使用數(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ù)分庫”祭陷；但是其有一個制約條件：跨庫的表無法進行Join操作；

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

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

首先，NoSQL主要指非關(guān)系的嵌纲、分布式的數(shù)據(jù)庫設(shè)計模式俘枫。也有許多專家將NoSQL解讀為Not Only SQL，表示NoSQL是關(guān)系數(shù)據(jù)庫的補充逮走，而不是替代方案鸠蚪。一般而言，NoSQL數(shù)據(jù)庫產(chǎn)品都放棄了關(guān)系數(shù)據(jù)庫的兩大重要基礎(chǔ)：①以關(guān)系代數(shù)為基礎(chǔ)的結(jié)構(gòu)化查詢語言（SQL）②事務(wù)的一致性保證（ACID）师溅；與之對應(yī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ǔ)入門》）實現(xiàn)酌摇。

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

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

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

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

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

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

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

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

參考文獻

　　（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)圖