來自滴滴、微博、唯品會、魅族、點評關於高可用架構的實踐分享

架構師小組交流會是由國內知名公司技術專家參與的技術交流會，每期選擇一個時下最熱門的技術話題進行實踐經驗分享。

上期我們分享了當前最具顛覆性的開源技術之一—— Docker 的相關實踐。我們邀請了滬江黃凱、滴滴田智偉、蘑菇街張振華、蘑菇街向靖、扇貝丁彥以及七牛雲袁曉沛在上期交流會上分享了各自的經驗。

本期話題：高可用架構。高可用性對於有海量用戶的互聯網產品系統架構至關重要，此次我們邀請到滴滴技術負責人彭令鵬、魅族系統架構師何偉、唯品會應用架構負責人張廣平、新浪微博技術專家聶永、大眾點評交易平台技術負責人陳一方、七牛雲首席架構師李道兵，對高可用話題進行交流，歡迎探討。

自由交流

• 滴滴彭令鵬

大家好，我是彭令鵬，目前在滴滴平台部負責整個專快車業務的穩定性和效率，之前在百度做了5年半的網頁搜索部底層架構的工作。現在在滴滴主要在推四個項目，第一個項目是異地多活 ，第二個項目是全鏈路壓測，為了儘快發現線上的一些容量風險，第三個是一鍵降級的平台，為了加快止損速度。第四個是服務治理，滴滴的業務也比較複雜，機器和服務規模也越來越大，我們在推一個整體的服務治理工作。

異地多活我們分三期，現在第一期差不多做完了。第一期主要是實現一個同城的 active /standby。我們的數據兩個機房都有，流量主要在一個機房，另一個機房只有少量流量，這少量流量主要是保證機房不會因為升級或其他原因，導致它不可用。第二期才會 active-active，比如說兩個機房分兩半各 50%的流量。第三期是支付這一塊，現在不考慮雙活，第三期我們會去考慮。當前第一期可以認為 99%的流量跑在一個機房，1%的流量跑在另外一個機房，而且另外那個 1%可能隨時會切回來。

數據同步有兩大塊。第一大塊在數據存儲這一層，比如說用了 MySQL 的主從複製，還有在我們的緩存層次，為了保證命中率，我們也做了一些雙寫同步複製。第二個層次，對於部分業務系統，特別是像我們分單，它因為狀態比較多，並且依賴的存儲也比較多，如果在存儲層做的話比較麻煩，所以我們直接在業務層做的雙寫。

滴滴的業務模式異地多活是比較難的，主要是要求的狀態比較實時，打不到車立馬就有人反饋投訴，不像購物一樣。異地多活，我們一共有三大塊技術，第一個是前面說的數據同步。第二個就是流量路由，前面說的 99%和 1%的流量的一個分配。第三大塊我們在做降級，降級包括一個最小系統，如果數據同步真出了問題，我們會用端上面的一些數據來做補償，反正整體還是很難的，因為訂單狀態機這一塊還是比較複雜，狀態比較多。

• 魅族何偉

我是魅族科技何偉，負責基礎架構技術平台。魅族的互聯網業務主要是用戶數據同步，應用商店，音樂、視頻等等，然後是 push 服務，push 服務每天也有幾個億的推送。我們也在做全鏈路壓測、容量管理，後面會準備上容器這一塊，現在還是 VM 的。全鏈路壓測我們現在正在做，簡單講一下，在入口時我們會去對流量打標記，就是著色，然後我們就能把流量根據這個著色把它調度到某一個指定的節點，在系統的各個層級我們都可以去做調度。我們不是像 TCPCopy 那樣工作。我們的做法是把流量引到某個節點，去壓某個節點的極限容量，然後我們就能看到我們的流量到底要多大的集群才能扛得起來。

• 七牛雲李道兵

大家好，我是李道兵，負責七牛存儲的技術架構。七牛是多數據中心，在全國有數個存儲區域，每個存儲區域有多個核心的存儲機房，這些機房的規模都比較大，用於存儲客戶的數據。將數據存放於一個數據中心內的風險很大，如果數據中心斷電、斷網，會造成數據的不可用，如果一個數據中心發生災難性事故，還可能會造成數據丟失，所以七牛使用了雙數據中心的互備技術。我們將兩個數據中心用裸光纖互聯，當用戶上傳文件到某個數據中心時，系統非同步將文件數據和相關原數據同步到與之互備的另一數據中心，這樣當一個數據中心故障時，我們會根據故障的級別啟用不同的應急預案，將請求切換到與之互備的數據中心。

• 微博聶永

我是來自新浪微博的聶永，現在負責微博客戶端 IM 消息下推系統基礎設施的維護和優化。前段時間還參與了公司的一個性能測試系統的建設，為系統性能提供完整壓測支持，舉一個例子，以前做過一個聊天室項目。我們對這個聊天室所有的功能介面都會一一地進行測試，並且會完整的模擬用戶從上線到離線這個中間過程之中所有的全鏈路交互，並且設定每一個交互的執行的次數，這個要先去梳理用戶在實際操作的所有行為。比如我們執行一次完整全鏈路壓測，其中每個用戶至少能持續 30 多分鐘，壓測強度還是很大的。同時，我們在做壓測的時候，其實完全可以拿手機，和模擬的用戶一同參與到壓測情景中來，這樣就可以以終端用戶的角度，去切身體驗我們的系統的穩定性，終端操作的流暢程度等。我們當時單機是直接的執行 50 萬用戶的壓力測試，然後線上執行 100 萬用戶容量壓測。

• 唯品會張廣平

大家好，我是張廣平，唯品會應用架構負責人。最近在做一個核心系統的重構。採購的一些商品，怎麼去選購到我們銷售環節去售賣，這時候就涉及到，怎麼把我的庫存導進來？怎麼把我的商品導到銷售環節，讓用戶能看得到？用戶去瀏覽商品詳情頁面，怎麼去做收藏？還有就包括結算購物車、訂單支付、促銷，我們把這些項目，作為我們的核心系統重構的第一階段。這些系統重構了以後，其他的外圍的系統，包括採購、物流都做一些調用。

唯品會這幾年發展非常快，基本上每年的量都在翻跟頭，之前主要還是靠硬體去頂，以前的應用程序主要還是 PHP。通過我們這次的重構，這次 雙11 效果非常好，雖然碰到了一個購物車刷單的事件，但我們核心系統還是比較爭氣，頂下來了。談一下刷單，刷單是需要綜合地去防治，我們是從入口上判斷一些請求，這些請求如果發現它是有風險的，我們會去做限流措施。因為我們的系統從入口的地方還沒有一個整體的重構設計，所以有些流量進來，比如說流到購物車，購物車要去調用我們目前一些商品查詢，包括庫存價格之類的，對後台系統壓力特別大。

我們當時是針對用戶的請求去做一些分析，看看他的 IP 地址，調用我們的風控模塊之類的，但是這一次沒有防得住，因為量太大。我們系統相對來說比較健康的，這些進來的請求應該還是一些合理的請求，所以沒有過多的限制。真要是扛不住，我們會去做系統限流、系統降級之類的。我們的 OSP 框架有一個比較有特色，我們對訪問的服務做限流，比如量達到多少以後我們把後面的請求關閉，這樣是保證我們正常的應用能運轉下去，不然會導致後面的商品查詢服務、庫存、價格，會癱掉。

兩年半以前我來唯品會的時候，清一色的 PHP，只有個別團隊在用嘗試 Java 做開發，但是 PHP 是主流，那時候我們面臨一個 PHP 在擴展性方面的問題，尤其是它的框架，版本很多，用起來性能很差，基本上 QPS 都是在七八百左右，能上千的都很少，基本上壓到 1000 左右就崩掉了。我們投入了大量的一些硬體資源，但是發現問題不斷。後來組建了一個基礎架構團隊，從基本的服務化框架、消息框架、配置中心，還有監控模塊、安全一系列都做了開發，兩年多以來我們現在基本上產品都有了。尤其是比較有特色的，是我們的 OSP 框架。這個框架主要是基於 thrift，滴滴的那位同學也提到了 thrift。我們 OSP 的框架也是一個 thrift 的長連接，一個 RPC 的框架。我們是作為應用架構在使用 OSP。QPS 從七八百，現在上萬是非常輕鬆，比較簡單的查詢，可以到五六萬級別。我們每次大促都要增加好多機器，但是這次 雙11 是省下來了，還把老的系統淘汰了下來。雖然對周邊沒有重合的一些系統做了擴容，總體省下來了，沒有去增加新的資源。我們這個重構還是值得的，我們的 OSP 框架扛到現在，這次 雙11 沒有出現問題。

• 大眾點評陳一方

我是陳一方，來自大眾點評。我原來是交易平台的，主要負責幾個團隊，優惠團隊、訂單團隊和整個支付團隊。現在負責整個點評的團購平台，這幾年一直在做高並發的規模化的 C端 系統，B端 系統也做了一些營銷系統和結算系統。原來點評美團分別有個支付平台，融合以後，上海的支付也就是我負責的支付平台，會交到北京去。

新美大有一個支付，剛拿到牌照，原來是沒牌照，但是我們是有支付團隊的，做整個支付後端的能力建設，比如說支付通道、賬戶體系，還有前端統一支付的。支付後端挺複雜的，後端主要分 3 塊，第一塊就是支付資金渠道來源，資金渠道這塊，比如支付寶，微信或銀聯或者任何支付通道，我們叫它支付資金渠道，這塊是管理資金通道的。第二塊是管理用戶賬戶體系，因為支付會有一些資金的往來，所以你必須有明細賬戶，所以會有賬戶體系。第三塊是面向公司類的業務聚集的，業務網關和支付網關。業務接入我們怎麼支付，他只需要接入我們網關就可以了。網關提供能力有兩種，有一種是 API 的模式在接入的，現在大部分是以那種組件，前端組件，比如 native 的話，我們就直接有收銀台，你只需嵌進去就行，什麼都不需要做。早期我們是 Call API，因為那時候沒有客服端的開發，後期的話，我們 iOS 逐漸成熟了，我們後面 API 全部都上了，用那種產品化平台化的模塊來接，因為這樣的話自動掛了我們切支付，或者是做支付上的營銷，那時候他非常好做，產品化的一個過程。

話題交流

Q：關於全鏈路壓測大家是怎麼做的，數據是怎麼處理的？生產的數據和測試的數據是放一起還是隔離的？

滴滴彭令鵬：魅族的全鏈路壓測是壓單個節點的極限，這與我們稍微有點不同，其實我們也有一個類似的做法，就是常態我們在調度的時候，可能會在地圖那種業務上面放置一個哨兵節點，這個哨兵結點的流量會比別人高一點，以便提前去發現一些問題，這點和魅族類似，但是我們的壓測不是這樣的，我們的壓測是真正直接打到整個集群，就是線上集群，和正常業務是一樣的。我們的用戶行為也儘可能和正常用戶一致，只是打上了特殊的標記，但是其他處理行為是完全一致的，除了發券等那些和錢相關的。測試的是生產集群，這樣做的目的是想真正去看這個生產集群的一個容量水平。這個和看單個節點的極限我覺得可能有點不一樣。以前我在百度的時候，因為每個模塊都很大，全系統的模塊沒幾個，所以可以通過單模塊的情況直接去推導整個系統，是不是全鏈路容量都是夠的。但是來了滴滴以後，因為滴滴的業務，每一類小的介面都獨立成了服務，這就導致它的服務特別多，整個全鏈路下來可能有幾十個，所以不直接去壓一壓其實還是有很多問題是看不出來的。

大眾點評陳一方：我的經驗跟滴滴是一樣的。我們也是壓測單機的容量，在線生產環境的時候不一定是按等比例放大的，所以你壓一台機子它支持 1000 QPS，但是你 10 台不一定能支持 1 萬的 QPS，確實有這個問題，因為它的鏈路太長，無法用。比如說一個節點是 10，第二個加入集群中它不是不是線性擴大 。

滴滴彭令鵬：我們這邊的做法，第一我們在流量的模擬方面也是基於用戶的歷史數據去回放，打上特殊的標記，這個標記會從鏈路的最前端到最後端，全部染色上。針對標記的流量，我們的數據有幾類處理：第一資料庫這塊我們是在一個 proxy 這樣的中間件裡面，直接把數據寫到了一個影子表裡面，相當於表級別隔離。第二個是緩存這塊，因為緩存數據都會以司機的 ID、用戶的 ID、訂單的 ID、坐標，作為 key 的組成部分，我們所有的測試數據對這些 ID 做了一個偏移，比如對於坐標，我們可能直接把這個坐標偏移到太平洋上面的一個地方，不會是真正的一個城市，這樣保證我們的緩存調用者不用改，數據就可通過 key 直接隔離開。第三個是消息隊列，我們會通過 kafka 訂閱和消費消息，我們會改造生產者，讓他們將消息寫到一些虛擬的 topic 上去。壓測完了以後，我們可能需要做數據清理，但是因為滴滴現在存儲空間這一塊其實並不是特別瓶頸，所以清理我們基本上不用做，當前是這樣子。

Q：我們在談壓測，很多系統有第三方服務的，比方說第三方支付，對接外部的銀行，沒辦法要求第三方服務配合你，那這個時候你們怎麼辦？

大眾點評陳一方：第三方有兩種做法，一種做法就是，如果它不是一個強依賴的話，你就直接把它關掉，最高峰的時候肯定不夠用，你就把他降級。這是第一個，第二個像支付，他強依賴的話，系統第三服務方會給你 SLA，你根據它的極限值往下壓就行了，如果他那個值沒達到，你找他去，他達到了，你那就算了。

滴滴彭令鵬：我們是這樣子的，因為有一種場景，雖然支付那邊會給你承諾 SLA，但我們的系統容量可能是高於它的。那這個時候怎麼壓呢？我們本身的壓測是分為兩期的。第一期，是在分單以前的壓測，第二個是整個全鏈路。分單以前壓測，是當流量到了分單系統以後，直接把它截斷，從而保證這樣的一些流量，不會走到下游去，對於支付也是一樣的，你可以在支付模塊的上游那裡做一個截斷。

Q：做高可用有一個指標，就是要達到五個 9。但最後在落地時，在多一些場景上面這些指示有實際測量嗎，後面有沒有一個定論去達到這個要求，或者沒有達到這個要求？

滴滴彭令鵬：滴滴現在這邊，當前是三個 9 多一點點。我們未來 2017 年的一個目標也就是三個 9 一個 5。對消息交易系統來說做到四個 9 很難。落實這一塊第一是我們有一個專門的第三方組織，來整體評比各個部門的穩定性指標，做得還是比較嚴的。第二個是老大們對這一塊特別重視。

大眾點評陳一方：我們跟滴滴挺像的，我們也是第三方的，比如運維部部或者質量部，他會給你出報表，因為它的報表是一周或者一個月的，我們現在交易系統，要求四個 9，但是我們其實達到三個 9 多一點。高層管理會看這個指標，中層也會看這個指標，然後這樣疊在每個基層，他也會看這個指標，所以這樣已經形成一個機制了。