架構(gòu)師小組交流會(huì)是由國(guó)內(nèi)知名公司技術(shù)專家參與的技術(shù)交流會(huì)，每期選擇一個(gè)時(shí)下最熱門(mén)的技術(shù)話題進(jìn)行實(shí)踐經(jīng)驗(yàn)分享。
上期我們分享了當(dāng)前最具顛覆性的開(kāi)源技術(shù)之一—— 的相關(guān)實(shí)踐。我們邀請(qǐng)了滬江黃凱、滴滴田智偉、蘑菇街張振華、蘑菇街向靖、扇貝丁彥以及七牛云袁曉沛在上期交流會(huì)上分享了各自的經(jīng)驗(yàn)。
本期話題：高可用架構(gòu)。高可用性對(duì)于有海量用戶的互聯(lián)網(wǎng)產(chǎn)品系統(tǒng)架構(gòu)至關(guān)重要，此次我們邀請(qǐng)到滴滴技術(shù)負(fù)責(zé)人彭令鵬、魅族系統(tǒng)架構(gòu)師何偉、唯品會(huì)應(yīng)用架構(gòu)負(fù)責(zé)人張廣平、新浪微博技術(shù)專家聶永、大眾點(diǎn)評(píng)交易平臺(tái)技術(shù)負(fù)責(zé)人陳一方、七牛云首席架構(gòu)師李道兵，對(duì)高可用話題進(jìn)行交流，歡迎探討。
自由交流
大家好，我是彭令鵬，目前在滴滴平臺(tái)部負(fù)責(zé)整個(gè)專快車業(yè)務(wù)的穩(wěn)定性和效率，之前在百度做了5年半的網(wǎng)頁(yè)搜索部底層架構(gòu)的工作。現(xiàn)在在滴滴主要在推四個(gè)項(xiàng)目，第一個(gè)項(xiàng)目是異地多活 ，第二個(gè)項(xiàng)目是全鏈路壓測(cè)，為了盡快發(fā)現(xiàn)線上的一些容量風(fēng)險(xiǎn)，第三個(gè)是一鍵降級(jí)的平臺(tái)，為了加快止損速度。第四個(gè)是服務(wù)治理，滴滴的業(yè)務(wù)也比較復(fù)雜，機(jī)器和服務(wù)規(guī)模也越來(lái)越大，我們?cè)谕埔粋€(gè)整體的服務(wù)治理工作。
異地多活我們分三期，現(xiàn)在第一期差不多做完了。第一期主要是實(shí)現(xiàn)一個(gè)同城的 /。我們的數(shù)據(jù)兩個(gè)機(jī)房都有，流量主要在一個(gè)機(jī)房，另一個(gè)機(jī)房只有少量流量，這少量流量主要是保證機(jī)房不會(huì)因?yàn)樯?jí)或其他原因，導(dǎo)致它不可用。第二期才會(huì) -，比如說(shuō)兩個(gè)機(jī)房分兩半各 50%的流量。第三期是支付這一塊，現(xiàn)在不考慮雙活，第三期我們會(huì)去考慮。當(dāng)前第一期可以認(rèn)為 99%的流量跑在一個(gè)機(jī)房，1%的流量跑在另外一個(gè)機(jī)房，而且另外那個(gè) 1%可能隨時(shí)會(huì)切回來(lái)。
數(shù)據(jù)同步有兩大塊。第一大塊在數(shù)據(jù)存儲(chǔ)這一層，比如說(shuō)用了 MySQL 的主從復(fù)制，還有在我們的緩存層次，為了保證命中率，我們也做了一些雙寫(xiě)同步復(fù)制。第二個(gè)層次，對(duì)于部分業(yè)務(wù)系統(tǒng)，特別是像我們分單，它因?yàn)闋顟B(tài)比較多，并且依賴的存儲(chǔ)也比較多，如果在存儲(chǔ)層做的話比較麻煩，所以我們直接在業(yè)務(wù)層做的雙寫(xiě)。
滴滴的業(yè)務(wù)模式異地多活是比較難的，主要是要求的狀態(tài)比較實(shí)時(shí)，打不到車立馬就有人反饋投訴，不像購(gòu)物一樣。異地多活，我們一共有三大塊技術(shù)，第一個(gè)是前面說(shuō)的數(shù)據(jù)同步。第二個(gè)就是流量路由，前面說(shuō)的 99%和 1%的流量的一個(gè)分配。第三大塊我們?cè)谧鼋导?jí)，降級(jí)包括一個(gè)最小系統(tǒng)，如果數(shù)據(jù)同步真出了問(wèn)題，我們會(huì)用端上面的一些數(shù)據(jù)來(lái)做補(bǔ)償，反正整體還是很難的，因?yàn)橛唵螤顟B(tài)機(jī)這一塊還是比較復(fù)雜，狀態(tài)比較多。
我是魅族科技何偉，負(fù)責(zé)基礎(chǔ)架構(gòu)技術(shù)平臺(tái)。魅族的互聯(lián)網(wǎng)業(yè)務(wù)主要是用戶數(shù)據(jù)同步，應(yīng)用商店，音樂(lè)、視頻等等，然后是 push 服務(wù)，push 服務(wù)每天也有幾個(gè)億的推送。我們也在做全鏈路壓測(cè)、容量管理，后面會(huì)準(zhǔn)備上容器這一塊，現(xiàn)在還是 VM 的。全鏈路壓測(cè)我們現(xiàn)在正在做，簡(jiǎn)單講一下，在入口時(shí)我們會(huì)去對(duì)流量打標(biāo)記，就是著色，然后我們就能把流量根據(jù)這個(gè)著色把它調(diào)度到某一個(gè)指定的節(jié)點(diǎn)，在系統(tǒng)的各個(gè)層級(jí)我們都可以去做調(diào)度。我們不是像 那樣工作。我們的做法是把流量引到某個(gè)節(jié)點(diǎn)，去壓某個(gè)節(jié)點(diǎn)的極限容量，然后我們就能看到我們的流量到底要多大的集群才能扛得起來(lái)。
大家好，我是李道兵，負(fù)責(zé)七牛存儲(chǔ)的技術(shù)架構(gòu)。七牛是多數(shù)據(jù)中心，在全國(guó)有數(shù)個(gè)存儲(chǔ)區(qū)域，每個(gè)存儲(chǔ)區(qū)域有多個(gè)核心的存儲(chǔ)機(jī)房，這些機(jī)房的規(guī)模都比較大，用于存儲(chǔ)客戶的數(shù)據(jù)。將數(shù)據(jù)存放于一個(gè)數(shù)據(jù)中心內(nèi)的風(fēng)險(xiǎn)很大，如果數(shù)據(jù)中心斷電、斷網(wǎng)，會(huì)造成數(shù)據(jù)的不可用，如果一個(gè)數(shù)據(jù)中心發(fā)生災(zāi)難性事故，還可能會(huì)造成數(shù)據(jù)丟失，所以七牛使用了雙數(shù)據(jù)中心的互備技術(shù)。我們將兩個(gè)數(shù)據(jù)中心用裸光纖互聯(lián)，當(dāng)用戶上傳文件到某個(gè)數(shù)據(jù)中心時(shí)，系統(tǒng)異步將文件數(shù)據(jù)和相關(guān)原數(shù)據(jù)同步到與之互備的另一數(shù)據(jù)中心，這樣當(dāng)一個(gè)數(shù)據(jù)中心故障時(shí)，我們會(huì)根據(jù)故障的級(jí)別啟用不同的應(yīng)急預(yù)案，將請(qǐng)求切換到與之互備的數(shù)據(jù)中心。
我是來(lái)自新浪微博的聶永，現(xiàn)在負(fù)責(zé)微博客戶端 IM 消息下推系統(tǒng)基礎(chǔ)設(shè)施的維護(hù)和優(yōu)化。前段時(shí)間還參與了公司的一個(gè)性能測(cè)試系統(tǒng)的建設(shè)，為系統(tǒng)性能提供完整壓測(cè)支持，舉一個(gè)例子，以前做過(guò)一個(gè)聊天室項(xiàng)目。我們對(duì)這個(gè)聊天室所有的功能接口都會(huì)一一地進(jìn)行測(cè)試，并且會(huì)完整的模擬用戶從上線到離線這個(gè)中間過(guò)程之中所有的全鏈路交互，并且設(shè)定每一個(gè)交互的執(zhí)行的次數(shù)，這個(gè)要先去梳理用戶在實(shí)際操作的所有行為。比如我們執(zhí)行一次完整全鏈路壓測(cè)，其中每個(gè)用戶至少能持續(xù) 30 多分鐘，壓測(cè)強(qiáng)度還是很大的。同時(shí)，我們?cè)谧鰤簻y(cè)的時(shí)候，其實(shí)完全可以拿手機(jī)，和模擬的用戶一同參與到壓測(cè)情景中來(lái)，這樣就可以以終端用戶的角度，去切身體驗(yàn)我們的系統(tǒng)的穩(wěn)定性支付標(biāo)記化系統(tǒng)架構(gòu)，終端操作的流暢程度等。我們當(dāng)時(shí)單機(jī)是直接的執(zhí)行 50 萬(wàn)用戶的壓力測(cè)試，然后線上執(zhí)行 100 萬(wàn)用戶容量壓測(cè)。
大家好，我是張廣平，唯品會(huì)應(yīng)用架構(gòu)負(fù)責(zé)人。最近在做一個(gè)核心系統(tǒng)的重構(gòu)。采購(gòu)的一些商品，怎么去選購(gòu)到我們銷售環(huán)節(jié)去售賣，這時(shí)候就涉及到，怎么把我的庫(kù)存導(dǎo)進(jìn)來(lái)？怎么把我的商品導(dǎo)到銷售環(huán)節(jié)，讓用戶能看得到？用戶去瀏覽商品詳情頁(yè)面，怎么去做收藏？還有就包括結(jié)算購(gòu)物車、訂單支付、促銷，我們把這些項(xiàng)目，作為我們的核心系統(tǒng)重構(gòu)的第一階段。這些系統(tǒng)重構(gòu)了以后，其他的外圍的系統(tǒng)，包括采購(gòu)、物流都做一些調(diào)用。
唯品會(huì)這幾年發(fā)展非常快，基本上每年的量都在翻跟頭，之前主要還是靠硬件去頂，以前的應(yīng)用程序主要還是 PHP。通過(guò)我們這次的重構(gòu)，這次 雙11 效果非常好，雖然碰到了一個(gè)購(gòu)物車刷單的事件，但我們核心系統(tǒng)還是比較爭(zhēng)氣，頂下來(lái)了。談一下刷單，刷單是需要綜合地去防治，我們是從入口上判斷一些請(qǐng)求，這些請(qǐng)求如果發(fā)現(xiàn)它是有風(fēng)險(xiǎn)的，我們會(huì)去做限流措施。因?yàn)槲覀兊南到y(tǒng)從入口的地方還沒(méi)有一個(gè)整體的重構(gòu)設(shè)計(jì)，所以有些流量進(jìn)來(lái)，比如說(shuō)流到購(gòu)物車，購(gòu)物車要去調(diào)用我們目前一些商品查詢，包括庫(kù)存價(jià)格之類的，對(duì)后臺(tái)系統(tǒng)壓力特別大。
我們當(dāng)時(shí)是針對(duì)用戶的請(qǐng)求去做一些分析，看看他的 IP 地址，調(diào)用我們的風(fēng)控模塊之類的，但是這一次沒(méi)有防得住，因?yàn)榱刻蟆Ｎ覀兿到y(tǒng)相對(duì)來(lái)說(shuō)比較健康的，這些進(jìn)來(lái)的請(qǐng)求應(yīng)該還是一些合理的請(qǐng)求，所以沒(méi)有過(guò)多的限制。真要是扛不住，我們會(huì)去做系統(tǒng)限流、系統(tǒng)降級(jí)之類的。我們的 OSP 框架有一個(gè)比較有特色，我們對(duì)訪問(wèn)的服務(wù)做限流，比如量達(dá)到多少以后我們把后面的請(qǐng)求關(guān)閉，這樣是保證我們正常的應(yīng)用能運(yùn)轉(zhuǎn)下去，不然會(huì)導(dǎo)致后面的商品查詢服務(wù)、庫(kù)存、價(jià)格，會(huì)癱掉。
兩年半以前我來(lái)唯品會(huì)的時(shí)候，清一色的 PHP，只有個(gè)別團(tuán)隊(duì)在用嘗試 Java 做開(kāi)發(fā)，但是 PHP 是主流，那時(shí)候我們面臨一個(gè) PHP 在擴(kuò)展性方面的問(wèn)題，尤其是它的框架，版本很多，用起來(lái)性能很差，基本上 QPS 都是在七八百左右，能上千的都很少，基本上壓到 1000 左右就崩掉了。我們投入了大量的一些硬件資源，但是發(fā)現(xiàn)問(wèn)題不斷。后來(lái)組建了一個(gè)基礎(chǔ)架構(gòu)團(tuán)隊(duì)，從基本的服務(wù)化框架、消息框架、配置中心，還有監(jiān)控模塊、安全一系列都做了開(kāi)發(fā)，兩年多以來(lái)我們現(xiàn)在基本上產(chǎn)品都有了。尤其是比較有特色的，是我們的 OSP 框架。這個(gè)框架主要是基于 ，滴滴的那位同學(xué)也提到了 。我們 OSP 的框架也是一個(gè) 的長(zhǎng)連接，一個(gè) RPC 的框架。我們是作為應(yīng)用架構(gòu)在使用 OSP。QPS 從七八百，現(xiàn)在上萬(wàn)是非常輕松，比較簡(jiǎn)單的查詢，可以到五六萬(wàn)級(jí)別。我們每次大促都要增加好多機(jī)器，但是這次 雙11 是省下來(lái)了，還把老的系統(tǒng)淘汰了下來(lái)。雖然對(duì)周邊沒(méi)有重合的一些系統(tǒng)做了擴(kuò)容，總體省下來(lái)了，沒(méi)有去增加新的資源。我們這個(gè)重構(gòu)還是值得的，我們的 OSP 框架扛到現(xiàn)在，這次 雙11 沒(méi)有出現(xiàn)問(wèn)題。
我是陳一方，來(lái)自大眾點(diǎn)評(píng)。我原來(lái)是交易平臺(tái)的，主要負(fù)責(zé)幾個(gè)團(tuán)隊(duì)，優(yōu)惠團(tuán)隊(duì)、訂單團(tuán)隊(duì)和整個(gè)支付團(tuán)隊(duì)。現(xiàn)在負(fù)責(zé)整個(gè)點(diǎn)評(píng)的團(tuán)購(gòu)平臺(tái)，這幾年一直在做高并發(fā)的規(guī)模化的 C端 系統(tǒng)，B端 系統(tǒng)也做了一些營(yíng)銷系統(tǒng)和結(jié)算系統(tǒng)。原來(lái)點(diǎn)評(píng)美團(tuán)分別有個(gè)支付平臺(tái)，融合以后，上海的支付也就是我負(fù)責(zé)的支付平臺(tái)，會(huì)交到北京去。
新美大有一個(gè)支付，剛拿到牌照，原來(lái)是沒(méi)牌照，但是我們是有支付團(tuán)隊(duì)的，做整個(gè)支付后端的能力建設(shè)，比如說(shuō)支付通道、賬戶體系，還有前端統(tǒng)一支付的。支付后端挺復(fù)雜的，后端主要分 3 塊，第一塊就是支付資金渠道來(lái)源，資金渠道這塊，比如支付寶，微信或銀聯(lián)或者任何支付通道，我們叫它支付資金渠道，這塊是管理資金通道的。第二塊是管理用戶賬戶體系，因?yàn)橹Ц稌?huì)有一些資金的往來(lái)，所以你必須有明細(xì)賬戶，所以會(huì)有賬戶體系。第三塊是面向公司類的業(yè)務(wù)聚集的，業(yè)務(wù)網(wǎng)關(guān)和支付網(wǎng)關(guān)。業(yè)務(wù)接入我們?cè)趺粗Ц叮恍枰尤胛覀兙W(wǎng)關(guān)就可以了。網(wǎng)關(guān)提供能力有兩種，有一種是 API 的模式在接入的，現(xiàn)在大部分是以那種組件，前端組件，比如 的話，我們就直接有收銀臺(tái)，你只需嵌進(jìn)去就行，什么都不需要做。早期我們是 Call API，因?yàn)槟菚r(shí)候沒(méi)有客服端的開(kāi)發(fā)，后期的話，我們 iOS 逐漸成熟了，我們后面 API 全部都上了，用那種產(chǎn)品化平臺(tái)化的模塊來(lái)接，因?yàn)檫@樣的話自動(dòng)掛了我們切支付，或者是做支付上的營(yíng)銷，那時(shí)候他非常好做，產(chǎn)品化的一個(gè)過(guò)程。
話題交流Q：關(guān)于全鏈路壓測(cè)大家是怎么做的，數(shù)據(jù)是怎么處理的？生產(chǎn)的數(shù)據(jù)和測(cè)試的數(shù)據(jù)是放一起還是隔離的？
滴滴彭令鵬：魅族的全鏈路壓測(cè)是壓?jiǎn)蝹€(gè)節(jié)點(diǎn)的極限，這與我們稍微有點(diǎn)不同，其實(shí)我們也有一個(gè)類似的做法，就是常態(tài)我們?cè)谡{(diào)度的時(shí)候，可能會(huì)在地圖那種業(yè)務(wù)上面放置一個(gè)哨兵節(jié)點(diǎn)支付標(biāo)記化系統(tǒng)架構(gòu)，這個(gè)哨兵結(jié)點(diǎn)的流量會(huì)比別人高一點(diǎn)，以便提前去發(fā)現(xiàn)一些問(wèn)題，這點(diǎn)和魅族類似，但是我們的壓測(cè)不是這樣的，我們的壓測(cè)是真正直接打到整個(gè)集群，就是線上集群，和正常業(yè)務(wù)是一樣的。我們的用戶行為也盡可能和正常用戶一致，只是打上了特殊的標(biāo)記，但是其他處理行為是完全一致的，除了發(fā)券等那些和錢(qián)相關(guān)的。測(cè)試的是生產(chǎn)集群，這樣做的目的是想真正去看這個(gè)生產(chǎn)集群的一個(gè)容量水平。這個(gè)和看單個(gè)節(jié)點(diǎn)的極限我覺(jué)得可能有點(diǎn)不一樣。以前我在百度的時(shí)候，因?yàn)槊總€(gè)模塊都很大，全系統(tǒng)的模塊沒(méi)幾個(gè)，所以可以通過(guò)單模塊的情況直接去推導(dǎo)整個(gè)系統(tǒng)，是不是全鏈路容量都是夠的。但是來(lái)了滴滴以后，因?yàn)榈蔚蔚臉I(yè)務(wù)，每一類小的接口都獨(dú)立成了服務(wù)，這就導(dǎo)致它的服務(wù)特別多，整個(gè)全鏈路下來(lái)可能有幾十個(gè)，所以不直接去壓一壓其實(shí)還是有很多問(wèn)題是看不出來(lái)的。
大眾點(diǎn)評(píng)陳一方：我的經(jīng)驗(yàn)跟滴滴是一樣的。我們也是壓測(cè)單機(jī)的容量，在線生產(chǎn)環(huán)境的時(shí)候不一定是按等比例放大的，所以你壓一臺(tái)機(jī)子它支持 1000 QPS，但是你 10 臺(tái)不一定能支持 1 萬(wàn)的 QPS，確實(shí)有這個(gè)問(wèn)題，因?yàn)樗逆溌诽L(zhǎng)，無(wú)法用。比如說(shuō)一個(gè)節(jié)點(diǎn)是 10，第二個(gè)加入集群中它不是不是線性擴(kuò)大 。
滴滴彭令鵬：我們這邊的做法，第一我們?cè)诹髁康哪M方面也是基于用戶的歷史數(shù)據(jù)去回放，打上特殊的標(biāo)記，這個(gè)標(biāo)記會(huì)從鏈路的最前端到最后端，全部染色上。針對(duì)標(biāo)記的流量，我們的數(shù)據(jù)有幾類處理：第一數(shù)據(jù)庫(kù)這塊我們是在一個(gè) proxy 這樣的中間件里面，直接把數(shù)據(jù)寫(xiě)到了一個(gè)影子表里面，相當(dāng)于表級(jí)別隔離。第二個(gè)是緩存這塊，因?yàn)榫彺鏀?shù)據(jù)都會(huì)以司機(jī)的 ID、用戶的 ID、訂單的 ID、坐標(biāo)，作為 key 的組成部分，我們所有的測(cè)試數(shù)據(jù)對(duì)這些 ID 做了一個(gè)偏移，比如對(duì)于坐標(biāo)，我們可能直接把這個(gè)坐標(biāo)偏移到太平洋上面的一個(gè)地方，不會(huì)是真正的一個(gè)城市，這樣保證我們的緩存調(diào)用者不用改，數(shù)據(jù)就可通過(guò) key 直接隔離開(kāi)。第三個(gè)是消息隊(duì)列，我們會(huì)通過(guò) kafka 訂閱和消費(fèi)消息，我們會(huì)改造生產(chǎn)者，讓他們將消息寫(xiě)到一些虛擬的 topic 上去。壓測(cè)完了以后，我們可能需要做數(shù)據(jù)清理，但是因?yàn)榈蔚维F(xiàn)在存儲(chǔ)空間這一塊其實(shí)并不是特別瓶頸，所以清理我們基本上不用做，當(dāng)前是這樣子。
Q：我們?cè)谡剦簻y(cè)，很多系統(tǒng)有第三方服務(wù)的，比方說(shuō)第三方支付，對(duì)接外部的銀行，沒(méi)辦法要求第三方服務(wù)配合你，那這個(gè)時(shí)候你們?cè)趺崔k？
大眾點(diǎn)評(píng)陳一方：第三方有兩種做法，一種做法就是，如果它不是一個(gè)強(qiáng)依賴的話，你就直接把它關(guān)掉，最高峰的時(shí)候肯定不夠用，你就把他降級(jí)。這是第一個(gè)，第二個(gè)像支付，他強(qiáng)依賴的話，系統(tǒng)第三服務(wù)方會(huì)給你 SLA，你根據(jù)它的極限值往下壓就行了，如果他那個(gè)值沒(méi)達(dá)到，你找他去，他達(dá)到了，你那就算了。
滴滴彭令鵬：我們是這樣子的，因?yàn)橛幸环N場(chǎng)景，雖然支付那邊會(huì)給你承諾 SLA，但我們的系統(tǒng)容量可能是高于它的。那這個(gè)時(shí)候怎么壓呢？我們本身的壓測(cè)是分為兩期的。第一期，是在分單以前的壓測(cè)，第二個(gè)是整個(gè)全鏈路。分單以前壓測(cè)，是當(dāng)流量到了分單系統(tǒng)以后，直接把它截?cái)啵瑥亩ＷC這樣的一些流量，不會(huì)走到下游去，對(duì)于支付也是一樣的，你可以在支付模塊的上游那里做一個(gè)截?cái)唷?/p>
Q：做高可用有一個(gè)指標(biāo)，就是要達(dá)到五個(gè) 9。但最后在落地時(shí)，在多一些場(chǎng)景上面這些指示有實(shí)際測(cè)量嗎，后面有沒(méi)有一個(gè)定論去達(dá)到這個(gè)要求，或者沒(méi)有達(dá)到這個(gè)要求？
滴滴彭令鵬：滴滴現(xiàn)在這邊，當(dāng)前是三個(gè) 9 多一點(diǎn)點(diǎn)。我們未來(lái) 2017 年的一個(gè)目標(biāo)也就是三個(gè) 9 一個(gè) 5。對(duì)消息交易系統(tǒng)來(lái)說(shuō)做到四個(gè) 9 很難。落實(shí)這一塊第一是我們有一個(gè)專門(mén)的第三方組織，來(lái)整體評(píng)比各個(gè)部門(mén)的穩(wěn)定性指標(biāo)，做得還是比較嚴(yán)的。第二個(gè)是老大們對(duì)這一塊特別重視。
大眾點(diǎn)評(píng)陳一方：我們跟滴滴挺像的，我們也是第三方的，比如運(yùn)維部部或者質(zhì)量部，他會(huì)給你出報(bào)表，因?yàn)樗膱?bào)表是一周或者一個(gè)月的，我們現(xiàn)在交易系統(tǒng)，要求四個(gè) 9，但是我們其實(shí)達(dá)到三個(gè) 9 多一點(diǎn)。高層管理會(huì)看這個(gè)指標(biāo)，中層也會(huì)看這個(gè)指標(biāo)，然后這樣疊在每個(gè)基層，他也會(huì)看這個(gè)指標(biāo)，所以這樣已經(jīng)形成一個(gè)機(jī)制了。