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

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

上期我們分享了當前最具顛覆性的開源技術之一—— 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 多一點。高層管理會看這個指標，中層也會看這個指標，然後這樣疊在每個基層，他也會看這個指標，所以這樣已經形成一個機制了。