一、什么是高可用

高可用HA(High Availability)是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一，它通常是指，通過(guò)設(shè)計(jì)減少系統(tǒng)不能提供服務(wù)的時(shí)間。

假設(shè)系統(tǒng)一直能夠提供服務(wù)，我們說(shuō)系統(tǒng)的可用性是100%。

如果系統(tǒng)每運(yùn)行100個(gè)時(shí)間單位，會(huì)有1個(gè)時(shí)間單位無(wú)法提供服務(wù)，我們說(shuō)系統(tǒng)的可用性是99%。

很多公司的高可用目標(biāo)是4個(gè)9，也就是99.99%，這就意味著，系統(tǒng)的年停機(jī)時(shí)間為8.76個(gè)小時(shí)。

百度的搜索首頁(yè)，是業(yè)內(nèi)公認(rèn)高可用保障非常出色的系統(tǒng)，甚至人們會(huì)通過(guò)www.baidu.com 能不能訪(fǎng)問(wèn)來(lái)判斷“網(wǎng)絡(luò)的連通性”，百度高可用的服務(wù)讓人留下啦“網(wǎng)絡(luò)通暢，百度就能訪(fǎng)問(wèn)”，“百度打不開(kāi)，應(yīng)該是網(wǎng)絡(luò)連不上”的印象，這其實(shí)是對(duì)百度HA***的褒獎(jiǎng)。

二、如何保障系統(tǒng)的高可用

我們都知道，單點(diǎn)是系統(tǒng)高可用的大敵，單點(diǎn)往往是系統(tǒng)高可用***的風(fēng)險(xiǎn)和敵人，應(yīng)該盡量在系統(tǒng)設(shè)計(jì)的過(guò)程中避免單點(diǎn)。方法論上，高可用保證的原則是“集群化”，或者叫“冗余”：只有一個(gè)單點(diǎn)，掛了服務(wù)會(huì)受影響;如果有冗余備份，掛了還有其他backup能夠頂上。

保證系統(tǒng)高可用，架構(gòu)設(shè)計(jì)的核心準(zhǔn)則是：冗余。

有了冗余之后，還不夠，每次出現(xiàn)故障需要人工介入恢復(fù)勢(shì)必會(huì)增加系統(tǒng)的不可服務(wù)實(shí)踐。所以，又往往是通過(guò)“自動(dòng)故障轉(zhuǎn)移”來(lái)實(shí)現(xiàn)系統(tǒng)的高可用。

接下來(lái)我們看下典型互聯(lián)網(wǎng)架構(gòu)中，如何通過(guò)冗余+自動(dòng)故障轉(zhuǎn)移來(lái)保證系統(tǒng)的高可用特性。

三、常見(jiàn)的互聯(lián)網(wǎng)分層架構(gòu)

常見(jiàn)互聯(lián)網(wǎng)分布式架構(gòu)如上，分為：

(1)客戶(hù)端層：典型調(diào)用方是瀏覽器browser或者手機(jī)應(yīng)用APP

(2)反向代理層：系統(tǒng)入口，反向代理

(3)站點(diǎn)應(yīng)用層：實(shí)現(xiàn)核心應(yīng)用邏輯，返回html或者json

(4)服務(wù)層：如果實(shí)現(xiàn)了服務(wù)化，就有這一層

(5)數(shù)據(jù)-緩存層：緩存加速訪(fǎng)問(wèn)存儲(chǔ)

(6)數(shù)據(jù)-數(shù)據(jù)庫(kù)層：數(shù)據(jù)庫(kù)固化數(shù)據(jù)存儲(chǔ)

整個(gè)系統(tǒng)的高可用，又是通過(guò)每一層的冗余+自動(dòng)故障轉(zhuǎn)移來(lái)綜合實(shí)現(xiàn)的。

四、分層高可用架構(gòu)實(shí)踐

【客戶(hù)端層->反向代理層】的高可用

【客戶(hù)端層】到【反向代理層】的高可用，是通過(guò)反向代理層的冗余來(lái)實(shí)現(xiàn)的。以nginx為例：有兩臺(tái)nginx，一臺(tái)對(duì)線(xiàn)上提供服務(wù)，另一臺(tái)冗余以保證高可用，常見(jiàn)的實(shí)踐是keepalived存活探測(cè)，相同virtual IP提供服務(wù)。

自動(dòng)故障轉(zhuǎn)移：當(dāng)nginx掛了的時(shí)候，keepalived能夠探測(cè)到，會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移，將流量自動(dòng)遷移到shadow-nginx，由于使用的是相同的virtual IP，這個(gè)切換過(guò)程對(duì)調(diào)用方是透明的。

【反向代理層->站點(diǎn)層】的高可用

【反向代理層】到【站點(diǎn)層】的高可用，是通過(guò)站點(diǎn)層的冗余來(lái)實(shí)現(xiàn)的。假設(shè)反向代理層是nginx，nginx.conf里能夠配置多個(gè)web后端，并且nginx能夠探測(cè)到多個(gè)后端的存活性。

自動(dòng)故障轉(zhuǎn)移：當(dāng)web-server掛了的時(shí)候，nginx能夠探測(cè)到，會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移，將流量自動(dòng)遷移到其他的web-server，整個(gè)過(guò)程由nginx自動(dòng)完成，對(duì)調(diào)用方是透明的。

【站點(diǎn)層->服務(wù)層】的高可用

【站點(diǎn)層】到【服務(wù)層】的高可用，是通過(guò)服務(wù)層的冗余來(lái)實(shí)現(xiàn)的。“服務(wù)連接池”會(huì)建立與下游服務(wù)多個(gè)連接，每次請(qǐng)求會(huì)“隨機(jī)”選取連接來(lái)訪(fǎng)問(wèn)下游服務(wù)。

自動(dòng)故障轉(zhuǎn)移：當(dāng)service掛了的時(shí)候，service-connection-pool能夠探測(cè)到，會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移，將流量自動(dòng)遷移到其他的service，整個(gè)過(guò)程由連接池自動(dòng)完成，對(duì)調(diào)用方是透明的(所以說(shuō)RPC-client中的服務(wù)連接池是很重要的基礎(chǔ)組件)。

【服務(wù)層>緩存層】的高可用

【服務(wù)層】到【緩存層】的高可用，是通過(guò)緩存數(shù)據(jù)的冗余來(lái)實(shí)現(xiàn)的。

緩存層的數(shù)據(jù)冗余又有幾種方式：***種是利用客戶(hù)端的封裝，service對(duì)cache進(jìn)行雙讀或者雙寫(xiě)。

緩存層也可以通過(guò)支持主從同步的緩存集群來(lái)解決緩存層的高可用問(wèn)題。

以redis為例，redis天然支持主從同步，redis官方也有sentinel哨兵機(jī)制，來(lái)做redis的存活性檢測(cè)。

自動(dòng)故障轉(zhuǎn)移：當(dāng)redis主掛了的時(shí)候，sentinel能夠探測(cè)到，會(huì)通知調(diào)用方訪(fǎng)問(wèn)新的redis，整個(gè)過(guò)程由sentinel和redis集群配合完成，對(duì)調(diào)用方是透明的。

說(shuō)完緩存的高可用，這里要多說(shuō)一句，業(yè)務(wù)對(duì)緩存并不一定有“高可用”要求，更多的對(duì)緩存的使用場(chǎng)景，是用來(lái)“加速數(shù)據(jù)訪(fǎng)問(wèn)”：把一部分?jǐn)?shù)據(jù)放到緩存里，如果緩存掛了或者緩存沒(méi)有***，是可以去后端的數(shù)據(jù)庫(kù)中再取數(shù)據(jù)的。

這類(lèi)允許“cache miss”的業(yè)務(wù)場(chǎng)景，緩存架構(gòu)的建議是：

將kv緩存封裝成服務(wù)集群，上游設(shè)置一個(gè)代理(代理可以用集群冗余的方式保證高可用)，代理的后端根據(jù)緩存訪(fǎng)問(wèn)的key水平切分成若干個(gè)實(shí)例，每個(gè)實(shí)例的訪(fǎng)問(wèn)并不做高可用。

緩存實(shí)例掛了屏蔽：當(dāng)有水平切分的實(shí)例掛掉時(shí)，代理層直接返回cache miss，此時(shí)緩存掛掉對(duì)調(diào)用方也是透明的。key水平切分實(shí)例減少，不建議做re-hash，這樣容易引發(fā)緩存數(shù)據(jù)的不一致。

【服務(wù)層>數(shù)據(jù)庫(kù)層】的高可用

大部分互聯(lián)網(wǎng)技術(shù)，數(shù)據(jù)庫(kù)層都用了“主從同步，讀寫(xiě)分離”架構(gòu)，所以數(shù)據(jù)庫(kù)層的高可用，又分為“讀庫(kù)高可用”與“寫(xiě)庫(kù)高可用”兩類(lèi)。

【服務(wù)層>數(shù)據(jù)庫(kù)層“讀”】的高可用

【服務(wù)層】到【數(shù)據(jù)庫(kù)讀】的高可用，是通過(guò)讀庫(kù)的冗余來(lái)實(shí)現(xiàn)的。

既然冗余了讀庫(kù)，一般來(lái)說(shuō)就至少有2個(gè)從庫(kù)，“數(shù)據(jù)庫(kù)連接池”會(huì)建立與讀庫(kù)多個(gè)連接，每次請(qǐng)求會(huì)路由到這些讀庫(kù)。

自動(dòng)故障轉(zhuǎn)移：當(dāng)讀庫(kù)掛了的時(shí)候，db-connection-pool能夠探測(cè)到，會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移，將流量自動(dòng)遷移到其他的讀庫(kù)，整個(gè)過(guò)程由連接池自動(dòng)完成，對(duì)調(diào)用方是透明的(所以說(shuō)DAO中的數(shù)據(jù)庫(kù)連接池是很重要的基礎(chǔ)組件)。

【服務(wù)層>數(shù)據(jù)庫(kù)層“寫(xiě)”】的高可用

【服務(wù)層】到【數(shù)據(jù)庫(kù)寫(xiě)】的高可用，是通過(guò)寫(xiě)庫(kù)的冗余來(lái)實(shí)現(xiàn)的。

以mysql為例，可以設(shè)置兩個(gè)mysql雙主同步，一臺(tái)對(duì)線(xiàn)上提供服務(wù)，另一臺(tái)冗余以保證高可用，常見(jiàn)的實(shí)踐是keepalived存活探測(cè)，相同virtual IP提供服務(wù)。

自動(dòng)故障轉(zhuǎn)移：當(dāng)寫(xiě)庫(kù)掛了的時(shí)候，keepalived能夠探測(cè)到，會(huì)自動(dòng)的進(jìn)行故障轉(zhuǎn)移，將流量自動(dòng)遷移到shadow-db-master，由于使用的是相同的virtual IP，這個(gè)切換過(guò)程對(duì)調(diào)用方是透明的。

五、總結(jié)

高可用HA(High Availability)是分布式系統(tǒng)架構(gòu)設(shè)計(jì)中必須考慮的因素之一，它通常是指，通過(guò)設(shè)計(jì)減少系統(tǒng)不能提供服務(wù)的時(shí)間。

方法論上，高可用是通過(guò)冗余+自動(dòng)故障轉(zhuǎn)移來(lái)實(shí)現(xiàn)的。

整個(gè)互聯(lián)網(wǎng)分層系統(tǒng)架構(gòu)的高可用，又是通過(guò)每一層的冗余+自動(dòng)故障轉(zhuǎn)移來(lái)綜合實(shí)現(xiàn)的，具體的：

(1)【客戶(hù)端層】到【反向代理層】的高可用，是通過(guò)反向代理層的冗余實(shí)現(xiàn)的，常見(jiàn)實(shí)踐是keepalived + virtual IP自動(dòng)故障轉(zhuǎn)移

(2)【反向代理層】到【站點(diǎn)層】的高可用，是通過(guò)站點(diǎn)層的冗余實(shí)現(xiàn)的，常見(jiàn)實(shí)踐是nginx與web-server之間的存活性探測(cè)與自動(dòng)故障轉(zhuǎn)移

(3)【站點(diǎn)層】到【服務(wù)層】的高可用，是通過(guò)服務(wù)層的冗余實(shí)現(xiàn)的，常見(jiàn)實(shí)踐是通過(guò)service-connection-pool來(lái)保證自動(dòng)故障轉(zhuǎn)移

(4)【服務(wù)層】到【緩存層】的高可用，是通過(guò)緩存數(shù)據(jù)的冗余實(shí)現(xiàn)的，常見(jiàn)實(shí)踐是緩存客戶(hù)端雙讀雙寫(xiě)，或者利用緩存集群的主從數(shù)據(jù)同步與sentinel?；钆c自動(dòng)故障轉(zhuǎn)移;更多的業(yè)務(wù)場(chǎng)景，對(duì)緩存沒(méi)有高可用要求，可以使用緩存服務(wù)化來(lái)對(duì)調(diào)用方屏蔽底層復(fù)雜性

(5)【服務(wù)層】到【數(shù)據(jù)庫(kù)“讀”】的高可用，是通過(guò)讀庫(kù)的冗余實(shí)現(xiàn)的，常見(jiàn)實(shí)踐是通過(guò)db-connection-pool來(lái)保證自動(dòng)故障轉(zhuǎn)移

(6)【服務(wù)層】到【數(shù)據(jù)庫(kù)“寫(xiě)”】的高可用，是通過(guò)寫(xiě)庫(kù)的冗余實(shí)現(xiàn)的，常見(jiàn)實(shí)踐是keepalived + virtual IP自動(dòng)故障轉(zhuǎn)移

前段時(shí)間，受@謝工 邀請(qǐng)，在GitChat平臺(tái)首發(fā)《究竟啥才是互聯(lián)網(wǎng)架構(gòu)“高可用”》。

12月01日周四晚8點(diǎn)30分，在微信群進(jìn)行了針對(duì)該文章的的主題交流。以下是主持人@赫陽(yáng) 整理的問(wèn)題精華，記錄下了我和讀者之間關(guān)于高可用架構(gòu)的問(wèn)答精彩片段。

問(wèn)答中所有文章都是可以直接點(diǎn)擊跳轉(zhuǎn)的喲。

問(wèn)：在緩存層rehash過(guò)程中必然會(huì)有臟數(shù)據(jù)。一致性hash實(shí)際上只能減少rehash的成本，不能消滅臟數(shù)據(jù)，這種臟數(shù)據(jù)有沒(méi)有辦法避免?

答：如文章《究竟啥才是互聯(lián)網(wǎng)架構(gòu)“高可用”》所述，如果沒(méi)有高可用需求，一臺(tái) cache 掛了，不宜做rehash，會(huì)產(chǎn)生臟數(shù)據(jù)。此時(shí)對(duì)掛掉cache的key可以直接返回 cache miss。

問(wèn)：從您后面的回答來(lái)看，這其實(shí)也是“降級(jí)”的一種，這樣以后是直接把請(qǐng)求打到后端的數(shù)據(jù)庫(kù)上么?還是直接拋棄請(qǐng)求?如果發(fā)生雪崩效應(yīng)，miss的請(qǐng)求越來(lái)越多，如果miss的都打庫(kù)的話(huà)，庫(kù)馬上就會(huì)掛了。這一塊老師能再展開(kāi)講一講么?

答：打到數(shù)據(jù)庫(kù)上，cache集群的份數(shù)和數(shù)據(jù)庫(kù)能抗多少讀有關(guān)。理論上1-2份掛掉，數(shù)據(jù)庫(kù)能抗住。58的做法，有一個(gè) backup mc集群，有掛了可以頂上，不建議rehash。高可用的代價(jià)是冗余，冗余有成本和復(fù)雜性，一致性問(wèn)題 cache 我文章中***那種 cache 服務(wù)集群化，是比較好的方案(配上backup 集群)。

問(wèn)：服務(wù)層到數(shù)據(jù)層，如果寫(xiě)是通過(guò)冗余寫(xiě)入保證高可用，那么根據(jù)CAP, 一致性很大可能上是不能保證的。 如何能保證基本一致性的情況的下，保證數(shù)據(jù)層的高可用?

答：根據(jù)CAP理論，一般來(lái)說(shuō)，一致性和可用性取其一，其實(shí)最終一致就行。保證了高可用，得犧牲一些一致性，以主從數(shù)據(jù)庫(kù)為例，可能在主從數(shù)據(jù)同步時(shí)間窗口內(nèi)，會(huì)從從庫(kù)讀到舊數(shù)據(jù)。

問(wèn)：你對(duì)時(shí)間管理和自我實(shí)現(xiàn)有沒(méi)有什么格外經(jīng)驗(yàn)，貼之前的文章也行，想學(xué)習(xí)下。

答：時(shí)間管理個(gè)人經(jīng)驗(yàn)，工作時(shí)關(guān)閉朋友圈、qq、各種群、郵件提醒等，它們是影響效率的主要矛盾。

自我實(shí)現(xiàn)?還在努力編碼、寫(xiě)文章自我實(shí)現(xiàn)中。在百度的一段工作經(jīng)歷讓我印象很深刻，周?chē)任遗１频耐卤任遗?，一直努力向他們學(xué)習(xí)。

問(wèn)：其實(shí)***問(wèn)題我的意思是，如果不允許 cache miss 的 case 下怎么做rehash且盡可能少臟數(shù)據(jù)?

答：不允許cache miss，就做cache 高可用，cache高可用也如文章，有幾種實(shí)現(xiàn)方式。cache 一致性，見(jiàn)《緩存與數(shù)據(jù)庫(kù)一致性保證》，這篇文章會(huì)對(duì)你有幫助。

問(wèn)：我看了不少的大型網(wǎng)站的構(gòu)架演進(jìn)，都是從all in one然后慢慢變成服務(wù)化的系統(tǒng)。既然，前人開(kāi)路，我們后人已經(jīng)知道最終架構(gòu)，那能不能一步到達(dá)這個(gè)服務(wù)化的系統(tǒng)?很多人給出不能的理由是一開(kāi)始就搭建這樣的架構(gòu)成本太高，要先發(fā)展業(yè)務(wù)再治理。但是在我看來(lái)，很多東西都可以自動(dòng)化了，只要幾行命令就可以把一整套基礎(chǔ)架構(gòu)搭好了，比如 jenkins 自動(dòng)化集成+部署、大數(shù)據(jù)分析平臺(tái)kafka+spark+zookeeper+Hadoop 等，剩下就是在在這上面寫(xiě)業(yè)務(wù)應(yīng)用了及根據(jù)業(yè)務(wù)具體情況調(diào)參數(shù)了。正因如此，我不是很認(rèn)同“成本高”這個(gè)觀點(diǎn)。請(qǐng)問(wèn)，到底能不能一步到達(dá)最終的服務(wù)化的系統(tǒng)，跳到中間的演化過(guò)程?為什么?也許有人會(huì)說(shuō)了，適合的架構(gòu)才是好的架構(gòu)，你業(yè)務(wù)量現(xiàn)在還達(dá)不到，就沒(méi)必要做成和淘寶，58的架構(gòu)。我想說(shuō)，如果搭建和他們類(lèi)似的架構(gòu)的成本很低，那我為什么不搭建?簡(jiǎn)單的說(shuō)，問(wèn)題是：能不能跳過(guò)大多公司的架構(gòu)演化過(guò)程，直接搭建最終架構(gòu)?

答：架構(gòu)設(shè)計(jì)多想一步，不建議想太遠(yuǎn)，如果回到10年前58同城重新創(chuàng)業(yè)，估計(jì)架構(gòu)還會(huì)是當(dāng)初那個(gè)樣子，而不是現(xiàn)在一樣。

不建議跳過(guò)演化，架構(gòu)是支持業(yè)務(wù)，不同階段業(yè)務(wù)需求不同，架構(gòu)不同，***架構(gòu)演化。架構(gòu)師之路公眾號(hào)這篇文章《好架構(gòu)是進(jìn)化來(lái)的》可能會(huì)對(duì)你有幫助。

問(wèn)：服務(wù)層到數(shù)據(jù)庫(kù)讀的高可用與服務(wù)層到數(shù)據(jù)庫(kù)寫(xiě)的高可用 的取舍原則應(yīng)該遵循哪些方面考慮?想請(qǐng)沈老師的提出一下見(jiàn)解，看看是否給我思考的思路一致?

答：《DB主從一致性架構(gòu)優(yōu)化4種方法》這篇文章中有詳細(xì)的介紹。

問(wèn)：如何避免服務(wù)掛掉之后，rpc client在轉(zhuǎn)移server的時(shí)候?qū)е录褐械捏@群效應(yīng)?

答：我的理解，是不存在驚群的，假設(shè)原來(lái)5個(gè)服務(wù)10條連接，現(xiàn)在一個(gè)服務(wù)掛了，變成4個(gè)服務(wù)8條連接，只要負(fù)載分配策略是隨機(jī)的，流量依然是隨機(jī)的。

問(wèn)：58到家在灰度發(fā)布和A/B是怎么樣的一個(gè)落地方案?

答：灰度發(fā)布是APP的灰度發(fā)布?還是類(lèi)似推薦算法的AB測(cè)，多個(gè)算法同時(shí)運(yùn)行?還是服務(wù)的平滑升級(jí)?對(duì)于***個(gè)，常見(jiàn)方法是渠道包，越獄包。對(duì)于第二個(gè)，需要有推薦算法分流平臺(tái)支持。對(duì)于第三個(gè)，web/service的升級(jí)，間隔重啟過(guò)程中，要切走流量，保證所有用戶(hù)不受影響。

以webserver平滑重啟為例，一般從nginx層切走一天tomcat的流量，這一臺(tái)升級(jí)站點(diǎn)重啟，nginx流量再切回，這么平滑。

問(wèn)：58是否也做了分中心的建設(shè)，中心和中心的內(nèi)部調(diào)用是否是rpc這種方式，又有那些場(chǎng)景是用消息調(diào)用，那些用rpc服務(wù)，怎么考量的，***有舉例?

答： 58沒(méi)有做多機(jī)房架構(gòu)，《從IDC到云端架構(gòu)遷移之路》這篇文章，講了同城機(jī)房遷移過(guò)程中，一段時(shí)間多機(jī)房的一些經(jīng)驗(yàn)。原則是：不能做到完全不跨機(jī)房，就減少跨機(jī)房，“同連”架構(gòu)，具體可以看文章。

問(wèn): 對(duì)于內(nèi)存計(jì)算怎么看，目前redis功能太低級(jí)，內(nèi)存計(jì)算同時(shí)勢(shì)必要讀取緩存信息，是否可以在內(nèi)存計(jì)算中就把緩存的事情做了，還是緩存就是緩存，只做這一件事情?

答：不太清楚問(wèn)題是想問(wèn)什么，mc支持kv，redis支持一些數(shù)據(jù)結(jié)構(gòu)，還有主從，還支持落地(不建議用)，功能我倒是覺(jué)得太強(qiáng)大了，cache就是cache，做計(jì)算不合適，計(jì)算還是業(yè)務(wù)服務(wù)層自己做吧。

問(wèn)：關(guān)于緩存和數(shù)據(jù)庫(kù)分布式后，重新分區(qū)后的數(shù)據(jù)遷移是否有好的方案?

答：這篇文章《58怎么玩數(shù)據(jù)庫(kù)架構(gòu)》講了數(shù)據(jù)庫(kù)擴(kuò)容，一種秒級(jí)擴(kuò)容，一種遷數(shù)據(jù)擴(kuò)容(不停服務(wù))，或許有幫助。緩存的擴(kuò)容，可以二倍擴(kuò)容，如果像我文章中proxy+cache集群的架構(gòu)，擴(kuò)容其實(shí)對(duì)調(diào)用方是透明的。

問(wèn)：你的文章介紹了每個(gè)層級(jí)和階段的高可用方案和設(shè)計(jì)原則，我關(guān)心的是有了這些方案和原則設(shè)計(jì)出來(lái)的東西怎么檢驗(yàn)，設(shè)計(jì)檢驗(yàn)方案的思路和原則?

答：不是特別理解這個(gè)“怎么檢驗(yàn)”，高可用上線(xiàn)前完全是可測(cè)的。例如nigix層高可用，做keepalived+vip后，干掉一臺(tái)，測(cè)試下能否繼續(xù)服務(wù)。

問(wèn)：我想了解云環(huán)境下數(shù)據(jù)庫(kù)高可用怎么做?沒(méi)有vip怎么做?他們提供的負(fù)載，用起來(lái)有限制。比如mha不能做到vip漂移。

答：云端兩種方式，以阿里云為例。一種ECS+自搭建DB+購(gòu)買(mǎi)阿里云類(lèi)似vip的服務(wù)，一種用直接用rds高可用數(shù)據(jù)。印象中阿里云只有主庫(kù)提供rds高可用，從庫(kù)貌似不高可用(需要數(shù)據(jù)庫(kù)連接池自己實(shí)現(xiàn))。58到家目前使用阿里云，兩種方式都有用。

問(wèn)：使用微服務(wù)的方式后如何保證某個(gè)服務(wù)的版本更新后，對(duì)其他各個(gè)服務(wù)之間的影響能盡可能小?

答：和服務(wù)化粒度有關(guān)，粒度越粗越耦合，一個(gè)地方升級(jí)影響其他。粒度越細(xì)，越不影響。這篇文章《微服務(wù)架構(gòu)多“微”才合適》對(duì)你或許有幫助。

問(wèn)：架構(gòu)高可用就是否架構(gòu)師和運(yùn)維人員的事情?開(kāi)發(fā)人員有能做和需要注意的?

答：我的理解，不適合存在專(zhuān)職架構(gòu)師負(fù)責(zé)架構(gòu)設(shè)計(jì)，開(kāi)發(fā)人員負(fù)責(zé)編碼，本身架構(gòu)就是 技術(shù)人 設(shè)計(jì)的，rd、dba、op等一起，高可用是大家的事情，只是說(shuō)可能有個(gè)經(jīng)驗(yàn)稍微豐富的研發(fā)(暫且叫架構(gòu)師)牽頭來(lái)梳理和設(shè)計(jì)。

問(wèn)：請(qǐng)問(wèn)老師分布式系統(tǒng)里面唯一全局ID的生成規(guī)則有什么好的方式么?

答：請(qǐng)看這篇文章《細(xì)聊分布式ID生成方法》。

問(wèn): 從高程轉(zhuǎn)向架構(gòu)師需要提高那方面的能力，在提高系統(tǒng)設(shè)計(jì)能力方面有什么建議?

答：這個(gè)問(wèn)題有點(diǎn)泛，這篇文章或許有幫助(非我原創(chuàng))《互聯(lián)網(wǎng)架構(gòu)師必備技能》。

問(wèn)：假如我之前5個(gè)機(jī)器能支撐10w用戶(hù)，突然有一臺(tái)機(jī)器斷電了，然后流量分散到其他4臺(tái)，那么這4臺(tái)都超過(guò)***值了，就會(huì)掛了，也就是驚群效應(yīng)，是否做拒絕策略，具體的落地怎么去做?

答：1)如果流量能抗住，直接分配沒(méi)問(wèn)題。2)如果流量超出余下系統(tǒng)負(fù)載，要做降級(jí)，最簡(jiǎn)單的方法就是拋棄請(qǐng)求，只為一部分用戶(hù)提供服務(wù)，而不是超出負(fù)載直接掛掉，這樣所有用戶(hù)都服務(wù)不了=> 服務(wù)自身需要做自我保護(hù)。

問(wèn)：類(lèi)似支付寶750積分這樣的灰度，類(lèi)似運(yùn)營(yíng)可以配置策略這種方式來(lái)控制不同的人根據(jù)不同的策略，接觸的服務(wù)類(lèi)型都是不一樣，這種的話(huà)具體的落地該如何去做呢?

答：這樣的灰度，就是不同的用戶(hù)的界面、功能、算法都不一樣的，需要系統(tǒng)支持(開(kāi)關(guān)、流量策略、分流、不同實(shí)現(xiàn))，《58同城推薦系統(tǒng)架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)》這篇文章中“分流”的部分，應(yīng)該會(huì)有幫助。

問(wèn)：請(qǐng)問(wèn)web集群中的數(shù)據(jù)同步，如果涉及跨機(jī)房，有什么好的方法盡量避免跨不同區(qū)域機(jī)房的數(shù)據(jù)同步和復(fù)制中的可靠性，或有其他更好的方法避免跨機(jī)房間的數(shù)據(jù)交互嗎?

答：這是多機(jī)房的問(wèn)題，后續(xù)在多機(jī)房架構(gòu)的文章中在具體闡述。多機(jī)房架構(gòu)常見(jiàn)三個(gè)方案：

1)冷備(強(qiáng)烈不推薦);

2)偽多機(jī)房(跨機(jī)房讀主庫(kù)數(shù)據(jù));

3)多機(jī)房多活(入口流量切分+雙機(jī)房數(shù)據(jù)同步)。

問(wèn)：58的服務(wù)降級(jí)如何做的?

答：不說(shuō)結(jié)合業(yè)務(wù)的降級(jí)(跳過(guò)非關(guān)鍵路徑)，通用的系統(tǒng)層面的降級(jí)，常見(jiàn)做法是設(shè)置隊(duì)列，超出負(fù)載拋棄請(qǐng)求。這個(gè)方案是不好的，當(dāng)一個(gè)上游請(qǐng)求變大，會(huì)是的所有上游排隊(duì)，拋棄請(qǐng)求，都受影響。

58服務(wù)治理一般這么做：針對(duì)不同調(diào)用方，限定流量;一個(gè)調(diào)用方超量，只拋棄這個(gè)調(diào)用方的請(qǐng)求，其他調(diào)用方不受影響。

末了，希望文章的思路是清晰的，希望大家對(duì)高可用的概念和實(shí)踐有個(gè)系統(tǒng)的認(rèn)識(shí)，感謝大家。

【本文為51CTO專(zhuān)欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】