高可用彈性伸縮系統(tǒng)架構(gòu)設(shè)計(jì)

1、 高可用彈性伸縮系統(tǒng)架構(gòu)設(shè)計(jì)移動(dòng)互聯(lián)網(wǎng)、云計(jì)算和大數(shù)據(jù)的成熟和發(fā)展，讓更多的好想法得以在很短的時(shí)間內(nèi)實(shí)現(xiàn)為產(chǎn)品。此時(shí)，如果用戶(hù)需求抓得準(zhǔn)，用戶(hù)數(shù)量將很可能獲得爆發(fā)式增長(zhǎng)，而不需要像以往一樣需要精心運(yùn)營(yíng)幾年的時(shí)間。然而用戶(hù)數(shù)量的快速增長(zhǎng)（尤其是短時(shí)間內(nèi)的爆發(fā)式增長(zhǎng)），通常會(huì)讓?xiě)?yīng)用開(kāi)發(fā)者有些吃不消，不得不面臨一些嚴(yán)峻的技術(shù)挑戰(zhàn)：如何避免因?yàn)閱闻_(tái)機(jī)器當(dāng)機(jī)導(dǎo)致服務(wù)不可用；如何避免在服務(wù)容量不足時(shí)，用戶(hù)體驗(yàn)下降，等等。在系統(tǒng)構(gòu)建之初就采用高可用和可伸縮架構(gòu)，將能有效避免這些問(wèn)題。如何構(gòu)建高可用和可伸縮架構(gòu)呢？七牛云存儲(chǔ)首席架構(gòu)師李道兵在3月22的開(kāi)發(fā)者最佳實(shí)踐日第十期沙龍活動(dòng)上給出了自己的想法。他結(jié)合自

2、己多年的實(shí)踐經(jīng)驗(yàn)，針對(duì)一些不太復(fù)雜的業(yè)務(wù)場(chǎng)景，從入口層、業(yè)務(wù)層、緩存層和數(shù)據(jù)庫(kù)層四個(gè)層面細(xì)致講述了如何構(gòu)建高可用和可伸縮系統(tǒng)。希望大家讀完這篇文章，能覺(jué)得高可用和可伸縮不是一個(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ī)了，那么用戶(hù)的訪問(wèn)肯定會(huì)中斷。此時(shí)，可以用keepalived來(lái)實(shí)現(xiàn)入口層的高可用。例如，機(jī)器A 的IP是 ，機(jī)器 B 的 IP 是 , 那么再申請(qǐng)一個(gè) IP （

3、稱(chēng)為?跳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)小問(wèn)題。第一，它的切換可能會(huì)有一到兩秒的中斷，也就是說(shuō)，如果不是要求到非常嚴(yán)格的毫秒級(jí)就不會(huì)有問(wèn)題。第二，對(duì)入口的機(jī)器會(huì)有些浪費(fèi)，因?yàn)橘I(mǎi)了兩臺(tái)機(jī)器的入口，可能就只有一臺(tái)機(jī)器用上。對(duì)一些長(zhǎng)連接的應(yīng)用可能會(huì)導(dǎo)致服務(wù)中斷，這時(shí)候就需要客戶(hù)端做配合做一些重新創(chuàng)建連接的工作。簡(jiǎn)單來(lái)說(shuō)，對(duì)于比較普通的業(yè)務(wù)來(lái)說(shuō)，這個(gè)方案就能解決一部分問(wèn)題。這里要注意，keepalived在使用上會(huì)有一些限制。1.兩臺(tái)機(jī)器必須在同

4、一個(gè)網(wǎng)段，不是在同一個(gè)網(wǎng)段，沒(méi)有辦法實(shí)現(xiàn)互相搶IP。2.內(nèi)網(wǎng)服務(wù)也可以做心跳，但需要注意的是，以前為了安全我們會(huì)把內(nèi)網(wǎng)服務(wù)綁定在內(nèi)網(wǎng)IP上，避免出現(xiàn)安全問(wèn)題。但為了使用keepalived，必須監(jiān)聽(tīng)在所有IP上（如果監(jiān)聽(tīng)在心跳IP上，那么機(jī)器沒(méi)有持有該IP時(shí)，服務(wù)無(wú)法啟動(dòng)），簡(jiǎn)單的方案是啟用 iptables, 避免內(nèi)網(wǎng)服務(wù)被外網(wǎng)訪問(wèn)。3.服務(wù)器利用率下降，這時(shí)可以考慮做混合部署來(lái)改善這一點(diǎn)。比較常見(jiàn)的一個(gè)錯(cuò)誤是，如果有兩臺(tái)機(jī)器，兩個(gè)公網(wǎng)IP，DNS上把域名同時(shí)定位到兩個(gè)IP，就覺(jué)得已經(jīng)做了高可用了。這完全不是高可用，因?yàn)槿绻慌_(tái)機(jī)器當(dāng)機(jī),那么就有一半左右的用戶(hù)無(wú)法訪問(wèn)。除了keepalive

5、，lvs也能用來(lái)解決入口層的高可用問(wèn)題。不過(guò)，與keepalived相比，lvs會(huì)更復(fù)雜一些，門(mén)檻也會(huì)高一些。業(yè)務(wù)層業(yè)務(wù)層通常是由PHP、Java、Python、Go等寫(xiě)的邏輯代碼構(gòu)成的，需要依賴(lài)于后臺(tái)數(shù)據(jù)庫(kù)及一些緩存層面的東西。如何實(shí)現(xiàn)業(yè)務(wù)層的高可用呢？最核心的就是，業(yè)務(wù)層不要有狀態(tài),將狀態(tài)分散到緩存層和數(shù)據(jù)庫(kù)。目前大家通常喜歡將以下幾種數(shù)據(jù)放入業(yè)務(wù)層。第一個(gè)是session，即用戶(hù)登錄相關(guān)的數(shù)據(jù)，但好的做法是將session放在數(shù)據(jù)庫(kù)里，或者一個(gè)比較穩(wěn)定的緩存系統(tǒng)中。第二個(gè)是緩存，在訪問(wèn)數(shù)據(jù)庫(kù)時(shí)，如果一個(gè)查詢(xún)很慢，就希望將這些結(jié)果暫時(shí)放到進(jìn)程里，下次再做查詢(xún)時(shí)就不用再訪問(wèn)數(shù)據(jù)庫(kù)了。這種做法

6、帶來(lái)的問(wèn)題是，當(dāng)業(yè)務(wù)層服務(wù)器不只一臺(tái)時(shí)，數(shù)據(jù)很難做到一致，從緩存拿到的數(shù)據(jù)就可能是錯(cuò)誤的。一個(gè)簡(jiǎn)單的原則就是業(yè)務(wù)層不要有狀態(tài)。在業(yè)務(wù)層沒(méi)有狀態(tài)時(shí)，一臺(tái)業(yè)務(wù)層服務(wù)器當(dāng)?shù)袅酥?，Nginx/Apache會(huì)自動(dòng)將所有的請(qǐng)求打到另外一臺(tái)業(yè)務(wù)層的服務(wù)器上。由于沒(méi)有狀態(tài)，兩臺(tái)服務(wù)器沒(méi)有任何差異，所以用戶(hù)完全感受不到。如果把session放在業(yè)務(wù)層里面的話，那么面臨的問(wèn)題是，這個(gè)用戶(hù)以前是登錄在一臺(tái)機(jī)器上的，這個(gè)進(jìn)程死掉后，用戶(hù)就會(huì)被登出了。友情提醒：有一段時(shí)間比較流行cookie session，就是將session中的數(shù)據(jù)加密之后放在客戶(hù)的cookie里，然后下發(fā)到客戶(hù)端，這樣也能做到與服務(wù)端完全無(wú)狀態(tài)

7、。但這里面有很多坑，如果能繞過(guò)這些坑就可以這樣使用。第一個(gè)坑是怎么保證加密的密鑰不泄露，一旦泄露就意味著攻擊者可以偽造任何人的身份。第二個(gè)坑是重放攻擊，如何避免別人通過(guò)保存 cookie 去不停地嘗試的驗(yàn)證碼，當(dāng)然也還有其他一些攻擊手段。如果沒(méi)有好辦法解決這兩方面的問(wèn)題，那么cookie session盡量慎用。最好是將session放在一個(gè)性能比較好的數(shù)據(jù)庫(kù)中。如果數(shù)據(jù)庫(kù)性能不行，那么將session放在緩存中也比放在cookie里要好一點(diǎn)。緩存層非常簡(jiǎn)單的架構(gòu)里是沒(méi)有緩存這個(gè)概念的。但在訪問(wèn)量上來(lái)之后，MySQL之類(lèi)的數(shù)據(jù)庫(kù)扛不住了，比如在SATA盤(pán)里跑MySQL，QPS到達(dá)200、300

8、甚至500時(shí)，MySQL的性能會(huì)大幅下降，這時(shí)就可以考慮用緩存層來(lái)?yè)踝〗^大部分服務(wù)請(qǐng)求，提升系統(tǒng)整體的容量。緩存層做高可用一個(gè)簡(jiǎn)單的方法就是，將緩存層分得細(xì)一點(diǎn)兒。比如說(shuō)，緩存層就一臺(tái)機(jī)器的話，那么這臺(tái)機(jī)器當(dāng)了以后，所有應(yīng)用層的壓力就會(huì)往數(shù)據(jù)庫(kù)里壓，數(shù)據(jù)庫(kù)扛不住的話，整個(gè)網(wǎng)站（或應(yīng)用）就會(huì)隨之當(dāng)?shù)?。而如果緩存層分在四臺(tái)機(jī)器上的話，每臺(tái)只有四分之一，這臺(tái)機(jī)器當(dāng)?shù)袅艘院螅仓挥锌傇L問(wèn)量的四分之一會(huì)壓在數(shù)據(jù)庫(kù)上面，數(shù)據(jù)庫(kù)能扛住的話，網(wǎng)站就能很穩(wěn)定地等到緩存層重新起來(lái)。在實(shí)踐中，四分之一顯然是不夠的，我們會(huì)將它分得更細(xì)，以保證單臺(tái)緩存當(dāng)機(jī)后數(shù)據(jù)庫(kù)還能撐得住即可。在中小規(guī)模下，緩存層和業(yè)務(wù)層可以混合部署

9、,這樣可以節(jié)省機(jī)器。數(shù)據(jù)庫(kù)層在數(shù)據(jù)庫(kù)層面實(shí)現(xiàn)高可用，通常是在軟件層面來(lái)做。例如，MySQL有主從模式(Master-Slave)，還有主主模式(Master-Master)都能滿(mǎn)足需求。MongoDB也有ReplicaSet的概念,基本都能滿(mǎn)足大家的需求?？傊?，要想實(shí)現(xiàn)高可用，需要做到這幾點(diǎn)：入口層做心跳，業(yè)務(wù)層服務(wù)器無(wú)狀態(tài)，緩存層減小粒度，數(shù)據(jù)庫(kù)做一個(gè)主從模式。對(duì)于這種模式來(lái)講，我們做的高可用不需要太多服務(wù)器，這些東西都可以同時(shí)部署在兩臺(tái)服務(wù)器上。這時(shí)，兩臺(tái)服務(wù)器就能滿(mǎn)足早期的高可用需求了。任何一臺(tái)服務(wù)器當(dāng)機(jī)用戶(hù)完全無(wú)感知。如何實(shí)現(xiàn)可伸縮入口層在入口層實(shí)現(xiàn)伸縮性，可以通過(guò)直接水平擴(kuò)機(jī)器，然后

10、DNS加IP來(lái)實(shí)現(xiàn)。但需要注意，盡管一個(gè)域名解析到幾十個(gè)IP沒(méi)有問(wèn)題,但是很多瀏覽器客戶(hù)端只會(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類(lèi)型的業(yè)務(wù)這種方式居多)。另外,也可以把所有IP下發(fā)到客戶(hù)端，然后在客戶(hù)端做一些調(diào)度(特別是非HTTP型的業(yè)務(wù),如游戲、直播)。業(yè)務(wù)層業(yè)務(wù)層的伸縮性如何實(shí)現(xiàn)?與做高可用時(shí)的解決方案一樣,要實(shí)現(xiàn)業(yè)務(wù)層的伸縮性，保證無(wú)狀態(tài)是很好的手段。此外，加機(jī)器繼續(xù)水平部署即可。緩存層比較麻煩的是緩存層的伸縮性，最簡(jiǎn)單粗暴的方式是什么呢？趁著半夜量比較低

11、的時(shí)候，把整個(gè)緩存層全部下線，然后上線新的緩存層。新的緩存層啟動(dòng)起來(lái)之后，再等這些緩存慢慢預(yù)熱。當(dāng)然這里一個(gè)要求，你的數(shù)據(jù)庫(kù)能抗住低估期的請(qǐng)求量。如果扛不住呢？取決于緩存類(lèi)型，下面我們先可以將緩存的類(lèi)型區(qū)分一下。1.強(qiáng)一致性緩存：無(wú)法接受從緩存拿到錯(cuò)誤的數(shù)據(jù) (比如用戶(hù)余額，或者會(huì)被下游繼續(xù)緩存這種情形)2.弱一致性緩存：能接受在一段時(shí)間內(nèi)從緩存拿到錯(cuò)誤的數(shù)據(jù) (比如微博的轉(zhuǎn)發(fā)數(shù))。3.不變型緩存：緩存key對(duì)應(yīng)的value不會(huì)變更 (比如從SHA1推出來(lái)的密碼, 或者其他復(fù)雜公式的計(jì)算結(jié)果)。那什么緩存類(lèi)型伸縮性比較好呢？弱一致性和不變型緩存的擴(kuò)容很方便,用一致性Hash即可；強(qiáng)一致性情況稍

12、微復(fù)雜一些，稍后再講。使用一致性Hash，而不用簡(jiǎn)單Hash的原因是緩存的失效率。如果緩存從9臺(tái)擴(kuò)容到10臺(tái),簡(jiǎn)單Hash 情況下90%的緩存會(huì)馬上失效,而如果使用一致性Hash情況,只有10%的緩存會(huì)失效。那么，強(qiáng)一致性緩存會(huì)有什么問(wèn)題？第一個(gè)問(wèn)題是，緩存客戶(hù)端的配置更新時(shí)間會(huì)有微小的差異,在這個(gè)時(shí)間窗內(nèi)有可能會(huì)拿到過(guò)期的數(shù)據(jù)。第二個(gè)問(wèn)題是，如果擴(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ù)。要解決問(wèn)題2比較簡(jiǎn)單，要么保持永不減少節(jié)點(diǎn),要么節(jié)點(diǎn)調(diào)整間隔大于數(shù)據(jù)的有效時(shí)間。問(wèn)題1可以用如下的步驟來(lái)解決：1.兩套hash配置都更新到客戶(hù)端，但仍然使用舊配置；2.逐個(gè)客戶(hù)端改為只有兩套hash結(jié)果一致的情況下會(huì)使用緩存，其余情況從數(shù)據(jù)庫(kù)讀，但寫(xiě)入緩存；3.逐個(gè)客戶(hù)端通知使用新配置。Memcache 設(shè)計(jì)得比較早，導(dǎo)致在伸縮性高可用方面的考慮得不太周到。Redis 在這方面有不少改進(jìn)，特別是 ngaut 團(tuán)隊(duì)基于 redis 開(kāi)發(fā)了 codis 這個(gè)軟件，一次性地解決了緩存層的絕大部分問(wèn)題。推薦大家考察一下。數(shù)據(jù)庫(kù)在數(shù)據(jù)庫(kù)層面實(shí)現(xiàn)伸縮，方法很多，文檔也很多，此