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

架構師小組交流會：每期選一個時下最熱門的技術話題進行實踐經驗分享。
第二期：因爲大家對全鏈路壓測的問題比較感興趣，因此做了一番探討。
參與嘉賓：滴滴技術負責人彭令鵬、魅族系統架構師何偉、唯品會應用架構負責人張廣平、新浪微博技術專家聶永、大衆點評交易平臺技術負責人陳一方、七牛雲首席架構師李道兵。
本文是對此次交流的整理，歡迎探討。

第一輪：自由交流
滴滴彭令鵬：大家好，我是彭令鵬，目前在滴滴平臺部負責整個專快車業務的穩定性和效率，之前在百度做了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對這一塊特別重視，基本上今年每個團隊有30%的kpi是穩定性。

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