移動(dòng)互聯(lián)網(wǎng)、云計(jì)算和大數(shù)據(jù)的成熟和發(fā)展，讓更多的好想法得以在很短的時(shí)間內(nèi)實(shí)現(xiàn)為產(chǎn)品。此時(shí)，如果用戶需求抓得準(zhǔn)，用戶數(shù)量將很可能獲得爆發(fā)式增 長，而不需要像以往一樣需要精心運(yùn)營幾年的時(shí)間。然而用戶數(shù)量的快速增長（尤其是短時(shí)間內(nèi)的爆發(fā)式增長），通常會(huì)讓應(yīng)用開發(fā)者有些吃不消，不得不面臨一些 嚴(yán)峻的技術(shù)挑戰(zhàn)：如何避免因?yàn)閱闻_(tái)機(jī)器當(dāng)機(jī)導(dǎo)致服務(wù)不可用；如何避免在服務(wù)容量不足時(shí)，用戶體驗(yàn)下降，等等。在系統(tǒng)構(gòu)建之初就采用高可用和可伸縮架構(gòu)，將 能有效避免這些問題。

如何構(gòu)建高可用和可伸縮架構(gòu)呢？七牛云存儲(chǔ)首席架構(gòu)師李道兵在3月22的「開發(fā)者最佳實(shí)踐日」第十期沙龍活動(dòng)上給出了自己的想法。他結(jié)合自己多年的 實(shí)踐經(jīng)驗(yàn)，針對(duì)一些不太復(fù)雜的業(yè)務(wù)場景，從入口層、業(yè)務(wù)層、緩存層和數(shù)據(jù)庫層四個(gè)層面細(xì)致講述了如何構(gòu)建高可用和可伸縮系統(tǒng)。希望大家讀完這篇文章，能覺 得高可用和可伸縮不是一個(gè)高不可攀的東西，投入不高的成本就能在項(xiàng)目早期把高可用和可伸縮納入架構(gòu)設(shè)計(jì)之中。

如何實(shí)現(xiàn)高可用

入口層

入口層，通常指Nginx和Apache等層面的東西，負(fù)責(zé)應(yīng)用（不管是Web應(yīng)用還是移動(dòng)應(yīng)用）的服務(wù)入口。我們通常會(huì)將服務(wù)定位在一個(gè)IP，如 果這個(gè)IP對(duì)應(yīng)的服務(wù)器當(dāng)機(jī)了，那么用戶的訪問肯定會(huì)中斷。此時(shí)，可以用keepalived來實(shí)現(xiàn)入口層的高可用。例如，機(jī)器A 的IP是 1.2.3.4，機(jī)器 B 的 IP 是 1.2.3.5, 那么再申請(qǐng)一個(gè) IP 1.2.3.6（稱為⼼跳IP）, 平時(shí)綁定在機(jī)器A上,如果A當(dāng)機(jī)，IP會(huì)自動(dòng)綁定在機(jī)器B上；如果B當(dāng)機(jī)，IP會(huì)自動(dòng)綁定在機(jī)器A上。對(duì)于這種形式，我們將DNS綁定到心跳IP上，即可 實(shí)現(xiàn)入口層的高可用。

但這個(gè)方案有一點(diǎn)小問題。第一，它的切換可能會(huì)有一到兩秒的中斷，也就是說，如果不是要求到非常嚴(yán)格的毫秒級(jí)就不會(huì)有問題。第二，對(duì)入口的機(jī)器會(huì)有 些浪費(fèi)，因?yàn)橘I了兩臺(tái)機(jī)器的入口，可能就只有一臺(tái)機(jī)器用上。對(duì)一些長連接的應(yīng)用可能會(huì)導(dǎo)致服務(wù)中斷，這時(shí)候就需要客戶端做配合做一些重新創(chuàng)建連接的工作。 簡單來說，對(duì)于比較普通的業(yè)務(wù)來說，這個(gè)方案就能解決一部分問題。

這里要注意，keepalived在使用上會(huì)有一些限制。

• 兩臺(tái)機(jī)器必須在同一個(gè)網(wǎng)段，不是在同一個(gè)網(wǎng)段，沒有辦法實(shí)現(xiàn)互相搶IP。

• 內(nèi)網(wǎng)服務(wù)也可以做心跳，但需要注意的是，以前為了安全我們會(huì)把內(nèi)網(wǎng)服務(wù)綁定在內(nèi)網(wǎng)IP上，避免出現(xiàn)安全問題。但為了使用keepalived，必 須監(jiān)聽在所有IP上（如果監(jiān)聽在心跳IP上，那么機(jī)器沒有持有該IP時(shí)，服務(wù)無法啟動(dòng)），簡單的方案是啟用 iptables, 避免內(nèi)網(wǎng)服務(wù)被外網(wǎng)訪問。

• 服務(wù)器利用率下降，這時(shí)可以考慮做混合部署來改善這一點(diǎn)。

比較常見的一個(gè)錯(cuò)誤是，如果有兩臺(tái)機(jī)器，兩個(gè)公網(wǎng)IP，DNS上把域名同時(shí)定位到兩個(gè)IP，就覺得已經(jīng)做了高可用了。這完全不是高可用，因?yàn)槿绻慌_(tái)機(jī)器當(dāng)機(jī),那么就有一半左右的用戶無法訪問。

除了keepalive，lvs也能用來解決入口層的高可用問題。不過，與keepalived相比，lvs會(huì)更復(fù)雜一些，門檻也會(huì)高一些。

業(yè)務(wù)層

業(yè)務(wù)層通常是由PHP、Java、Python、Go等寫的邏輯代碼構(gòu)成的，需要依賴于后臺(tái)數(shù)據(jù)庫及一些緩存層面的東西。如何實(shí)現(xiàn)業(yè)務(wù)層的高可用呢？最核心的就是，業(yè)務(wù)層不要有狀態(tài),將狀態(tài)分散到緩存層和數(shù)據(jù)庫。目前大家通常喜歡將以下幾種數(shù)據(jù)放入業(yè)務(wù)層。

第一個(gè)是session，即用戶登錄相關(guān)的數(shù)據(jù)，但好的做法是將session放在數(shù)據(jù)庫里，或者一個(gè)比較穩(wěn)定的緩存系統(tǒng)中。

第二個(gè)是緩存，在訪問數(shù)據(jù)庫時(shí)，如果一個(gè)查詢很慢，就希望將這些結(jié)果暫時(shí)放到進(jìn)程里，下次再做查詢時(shí)就不用再訪問數(shù)據(jù)庫了。這種做法帶來的問題是，當(dāng)業(yè)務(wù)層服務(wù)器不只一臺(tái)時(shí)，數(shù)據(jù)很難做到一致，從緩存拿到的數(shù)據(jù)就可能是錯(cuò)誤的。。

一個(gè)簡單的原則就是業(yè)務(wù)層不要有狀態(tài)。在業(yè)務(wù)層沒有狀態(tài)時(shí)，一臺(tái)業(yè)務(wù)層服務(wù)器當(dāng)?shù)袅酥螅琋ginx/Apache會(huì)自動(dòng)將所有的請(qǐng)求打到另外一臺(tái) 業(yè)務(wù)層的服務(wù)器上。由于沒有狀態(tài)，兩臺(tái)服務(wù)器沒有任何差異，所以用戶完全感受不到。如果把session放在業(yè)務(wù)層里面的話，那么面臨的問題是，這個(gè)用戶 以前是登錄在一臺(tái)機(jī)器上的，這個(gè)進(jìn)程死掉后，用戶就會(huì)被登出了。

友情提醒：有一段時(shí)間比較流行cookie session，就是將session中的數(shù)據(jù)加密之后放在客戶的cookie里，然后下發(fā)到客戶端，這樣也能做到與服務(wù)端完全無狀態(tài)。但這里面有很多 坑，如果能繞過這些坑就可以這樣使用。第一個(gè)坑是怎么保證加密的密鑰不泄露，一旦泄露就意味著攻擊者可以偽造任何人的身份。第二個(gè)坑是重放攻擊，如何避免 別人通過保存 cookie 去不停地嘗試的驗(yàn)證碼，當(dāng)然也還有其他一些攻擊手段。如果沒有好辦法解決這兩方面的問題，那么cookie session盡量慎用。最好是將session放在一個(gè)性能比較好的數(shù)據(jù)庫中。如果數(shù)據(jù)庫性能不行，那么將session放在緩存中也比放在 cookie里要好一點(diǎn)。

緩存層

非常簡單的架構(gòu)里是沒有緩存這個(gè)概念的。但在訪問量上來之后，MySQL之類的數(shù)據(jù)庫扛不住了，比如在SATA盤里跑MySQL，QPS到達(dá)200、300甚至500時(shí)，MySQL的性能會(huì)大幅下降，這時(shí)就可以考慮用緩存層來擋住絕大部分服務(wù)請(qǐng)求，提升系統(tǒng)整體的容量。

緩存層做高可用一個(gè)簡單的方法就是，將緩存層分得細(xì)一點(diǎn)兒。比如說，緩存層就一臺(tái)機(jī)器的話，那么這臺(tái)機(jī)器當(dāng)了以后，所有應(yīng)用層的壓力就會(huì)往數(shù)據(jù)庫里 壓，數(shù)據(jù)庫扛不住的話，整個(gè)網(wǎng)站（或應(yīng)用）就會(huì)隨之當(dāng)?shù)簟６绻彺鎸臃衷谒呐_(tái)機(jī)器上的話，每臺(tái)只有四分之一，這臺(tái)機(jī)器當(dāng)?shù)袅艘院螅仓挥锌傇L問量的四分 之一會(huì)壓在數(shù)據(jù)庫上面，數(shù)據(jù)庫能扛住的話，網(wǎng)站就能很穩(wěn)定地等到緩存層重新起來。在實(shí)踐中，四分之一顯然是不夠的，我們會(huì)將它分得更細(xì)，以保證單臺(tái)緩存當(dāng) 機(jī)后數(shù)據(jù)庫還能撐得住即可。在中小規(guī)模下，緩存層和業(yè)務(wù)層可以混合部署,這樣可以節(jié)省機(jī)器。

數(shù)據(jù)庫層

在數(shù)據(jù)庫層面實(shí)現(xiàn)高可用，通常是在軟件層面來做。例如，MySQL有主從模式(Master-Slave)，還有主主模式(Master-Master)都能滿足需求。MongoDB也有ReplicaSet的概念,基本都能滿足大家的需求。

總之，要想實(shí)現(xiàn)高可用，需要做到這幾點(diǎn)：入口層做心跳，業(yè)務(wù)層服務(wù)器無狀態(tài)，緩存層減小粒度，數(shù)據(jù)庫做一個(gè)主從模式。對(duì)于這種模式來講，我們做的高 可用不需要太多服務(wù)器，這些東西都可以同時(shí)部署在兩臺(tái)服務(wù)器上。這時(shí)，兩臺(tái)服務(wù)器就能滿足早期的高可用需求了。任何一臺(tái)服務(wù)器當(dāng)機(jī)用戶完全無感知。

如何實(shí)現(xiàn)可伸縮

入口層

在入口層實(shí)現(xiàn)伸縮性，可以通過直接水平擴(kuò)機(jī)器，然后DNS加IP來實(shí)現(xiàn)。但需要注意，盡管一個(gè)域名解析到幾十個(gè)IP沒有問題,但是很多瀏覽器客戶端只會(huì)使用前幾個(gè)IP,部分域名供應(yīng)商對(duì)此有優(yōu)化(如每次返回的IP順序隨機(jī)),但這個(gè)優(yōu)化效果不穩(wěn)定。

推薦的做法是使用少量的Nginx機(jī)器作為入口,業(yè)務(wù)服務(wù)器隱藏在內(nèi)網(wǎng)(HTTP類型的業(yè)務(wù)這種方式居多)。另外,也可以把所有IP下發(fā)到客戶端，然后在客戶端做一些調(diào)度(特別是非HTTP型的業(yè)務(wù),如游戲、直播)。

業(yè)務(wù)層

業(yè)務(wù)層的伸縮性如何實(shí)現(xiàn)?與做高可用時(shí)的解決方案一樣,要實(shí)現(xiàn)業(yè)務(wù)層的伸縮性，保證無狀態(tài)是很好的手段。此外，加機(jī)器繼續(xù)水平部署即可。

緩存層

比較麻煩的是緩存層的伸縮性，最簡單粗暴的方式是什么呢？趁著半夜量比較低的時(shí)候，把整個(gè)緩存層全部下線，然后上線新的緩存層。新的緩存層啟動(dòng)起來 之后，再等這些緩存慢慢預(yù)熱。當(dāng)然這里一個(gè)要求，你的數(shù)據(jù)庫能抗住低估期的請(qǐng)求量。如果扛不住呢？取決于緩存類型，下面我們先可以將緩存的類型區(qū)分一下。

• 強(qiáng)一致性緩存：無法接受從緩存拿到錯(cuò)誤的數(shù)據(jù) (比如用戶余額，或者會(huì)被下游繼續(xù)緩存這種情形)

• 弱一致性緩存：能接受在一段時(shí)間內(nèi)從緩存拿到錯(cuò)誤的數(shù)據(jù) (比如微博的轉(zhuǎn)發(fā)數(shù))。

• 不變型緩存：緩存key對(duì)應(yīng)的value不會(huì)變更 (比如從SHA1推出來的密碼, 或者其他復(fù)雜公式的計(jì)算結(jié)果)。

那什么緩存類型伸縮性比較好呢？弱一致性和不變型緩存的擴(kuò)容很方便,用一致性Hash即可；強(qiáng)一致性情況稍微復(fù)雜一些，稍后再講。使用一致性 Hash，而不用簡單Hash的原因是緩存的失效率。如果緩存從9臺(tái)擴(kuò)容到10臺(tái),簡單Hash 情況下90%的緩存會(huì)馬上失效,而如果使用一致性Hash情況,只有10%的緩存會(huì)失效。

那么，強(qiáng)一致性緩存會(huì)有什么問題？第一個(gè)問題是，緩存客戶端的配置更新時(shí)間會(huì)有微小的差異,在這個(gè)時(shí)間窗內(nèi)有可能會(huì)拿到過期的數(shù)據(jù)。第二個(gè)問題是， 如果擴(kuò)容之后再裁撤節(jié)點(diǎn),會(huì)拿到臟數(shù)據(jù)。比如 a 這個(gè)key之前在機(jī)器1，擴(kuò)容后在機(jī)器2，數(shù)據(jù)更新了，但裁撤節(jié)點(diǎn)后key回到機(jī)器1，這時(shí)候就會(huì)拿到臟數(shù)據(jù)。

要解決問題2比較簡單，要么保持永不減少節(jié)點(diǎn),要么節(jié)點(diǎn)調(diào)整間隔大于數(shù)據(jù)的有效時(shí)間。問題1可以用如下的步驟來解決：

1. 兩套hash配置都更新到客戶端，但仍然使用舊配置；

2. 逐個(gè)客戶端改為只有兩套hash結(jié)果一致的情況下會(huì)使用緩存，其余情況從數(shù)據(jù)庫讀，但寫入緩存；

3. 逐個(gè)客戶端通知使用新配置。

Memcache 設(shè)計(jì)得比較早，導(dǎo)致在伸縮性高可用方面的考慮得不太周到。Redis 在這方面有不少改進(jìn)，特別是 @ngaut 團(tuán)隊(duì)基于 redis 開發(fā)了 codis 這個(gè)軟件，一次性地解決了緩存層的絕大部分問題。推薦大家考察一下。

數(shù)據(jù)庫

在數(shù)據(jù)庫層面實(shí)現(xiàn)伸縮，方法很多，文檔也很多，此處不做過多贅述。大致方法為：水平拆分、垂直拆分和定期滾動(dòng)。

總之，我們可以在入口層、業(yè)務(wù)層面、緩存層和數(shù)據(jù)庫層四個(gè)層面，使用剛才介紹的方法和技術(shù)實(shí)現(xiàn)系統(tǒng)高可用和可伸縮性。具體為：在入口層用心跳來做到 高可用，用平行部署來伸縮；在業(yè)務(wù)層做到服務(wù)無狀態(tài)；在緩存層，可以減小一些粒度，以方便實(shí)現(xiàn)高可用，使用一致性Hash將有助于實(shí)現(xiàn)緩存層的伸縮性；數(shù) 據(jù)庫層的主從模式能解決高可用問題，拆分和滾動(dòng)能解決可伸縮問題。

本文中分享的這些技巧和方法，主要想幫助不太復(fù)雜的業(yè)務(wù)場景或者中小型應(yīng)用快速搭建起高可用可伸縮的系統(tǒng)。關(guān)于如何構(gòu)建高可用和可伸縮系統(tǒng)還有很多更為細(xì)節(jié)的點(diǎn)和實(shí)踐經(jīng)驗(yàn)值得探討，望以后能與大家做更充分的交流。