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

架構師小組交流會：每期選一個時下最熱門的技術話題進行實踐經驗分享。

第二期：高可用架構。

參與嘉賓：滴滴技術負責人彭令鵬、魅族系統架構師何偉、惟品會應用架構負責人張廣平、新浪微博技術專家聶永、大衆點評交易平臺技術負責人陳一方、七牛雲首席架構師李道兵。

本文是對這次交流的整理，歡迎探討。

 

第一輪：自由交流

滴滴彭令鵬：你們好，我是彭令鵬，目前在滴滴平臺部負責整個專快車業務的穩定性和效率，以前在百度作了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的都不多，基本上壓到1000左右就崩掉了。咱們投入了大量的一些硬件資源，可是發現問題不斷。後來組建了一個基礎架構團隊，從基本的服務化框架、消息框架、配置中心，還有監控模塊、安全一系列都作了開發，兩年多以來咱們如今基本上產品都有了。尤爲是比較有特點的，是咱們的OSP框架。這個框架主要是基於thrift，滴滴的那位同窗也提到了thrift。咱們OSP的框架也是一個thrift的長鏈接，一個RPC的框架。咱們是做爲應用架構在使用OSP。QPS從七八百，如今上萬是很是輕鬆，比較簡單的查詢，能夠到五六萬級別。咱們每次大促都要增長好多機器，可是此次雙11是省下來了，還把老的系統淘汰了下來。雖然對周邊沒有重合的一些系統作了擴容，整體省下來了，沒有去增長新的資源。咱們這個重構仍是值得的，咱們的OSP框架扛到如今，此次雙11沒有出現一個問題。

 

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

 

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

 

第二輪：話題交流

主持人：關於全鏈路壓測你們是怎麼作的，數據是怎麼處理的？生產的數據和測試的數據是放一塊兒仍是隔離的？

 

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

 

大衆點評陳一方：個人經驗跟滴滴是同樣的。咱們也是壓測單機的容量，在線生產環境的時候不必定是按等比例放大的，因此你壓一臺機子它支持1000QPS，可是你10臺不必定能支持1萬的QPS，確實有這個問題，由於它的鏈路太長，沒法用。好比說一個節點是10，第二個加入集羣中它不是否是線性擴大 。

 

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

 

主持人：同一個訂單，用戶打標是否是就是要侵入代碼了？

滴滴彭令鵬：好比說作trace或者作追查，確定自上而下要傳不少上下文，那咱們這樣對應的一個壓測標記，只是上下文裏面的一個。那條路原來就是通了的，好比說對於http來說，我記得好像就是直接放在那個http的那個query string 裏面，直接下去的。 

 

主持人：好比一個訂單要寫庫，用戶的ID是怎麼來的？

滴滴彭令鵬：這些邏輯它是不變的，剛剛我說了，咱們採了真實的用戶數據之後，會對一些ID類數據作偏移，好比說用戶Passenger ID和Driver ID，正常的可認爲是一些手機號，但偏移時咱們會把它的最高位，設置成特殊值，這是一類。另一類是座標，咱們會把這個座標，好比說北京直接平移到太平洋上面的一個經緯度，即平移到一個虛擬城市。咱們系統會將這些ID或座標做爲key去存儲數據，包括緩存的key，那對應的，這些key也被咱們偏移了，因此存儲的數據也就經過key隔離了。

 

大衆點評陳一方：我分享下咱們當時壓測的經驗，咱們在壓測線上服務的時候，咱們先壓的讀，讀數據的這塊壓測比較容易，而壓測寫，其實挺難的。剛纔滴滴分享他們經驗，每一個團隊不同。咱們的訂單系統，當時壓的時候就是很難就寫入了。由於有一些問題，有不少數據寫入咱們一次訪問，後面一個集羣，下面可能掛了一堆二三十臺的實例數據表。遇到這樣的問題怎麼辦呢，咱們當時是分段壓測，就是先壓數據層到db，就是先壓db的的極限，db的極限壓出來，好比說一個集羣在db寫的場景下支持2萬，那根據這個集羣服務器數量倒推，每臺服務器寫了多少db，而後再去測單臺的服務的性能，而後再乘以集羣數量，根據流量的翻量比。

 

主持人：咱們在談壓測，不少系統有第三方服務的，比方說第三方支付，對接外部的銀行，沒辦法要求第三方服務配合你，那這個時候大家怎麼辦？

 

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

 

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

 

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

 

滴滴彭令鵬：滴滴如今這邊，當前是三個9多一點點。咱們將來2017年的一個目標也就是三個9一個五。作到四個9很難，對消息交易系統來講。落實這一塊第一是咱們有一個專門的第三方組織，來總體評比各個部門的穩定性指標，作得仍是比較嚴的。第二個是老大，包括CTO對這一塊特別重視。

 

大衆點評陳一方：咱們跟滴滴挺像的，咱們也是第三方的，好比運維部部或者質量部，他會給你出報表，由於它的報表是一週或者一個月的，咱們如今交易系統，要求四個9，可是咱們其實達到三個9多一點。高層管理會看這個指標，中層也會看這個指標，而後這樣疊在每一個基層，他也會看這個指標，因此這樣已經造成一個機制了。