小米網(wǎng)技術(shù)架構(gòu)變遷實踐.
- 標(biāo)簽 :
文/ 張濤，小米網(wǎng)架構(gòu)師
“先賣10000臺再說！”2011年8月9日，小米網(wǎng)負責(zé)人黎萬強在公司內(nèi)部大會上這樣說道。時間回到4年多前，在小米“標(biāo)配”產(chǎn)品發(fā)布日8月16日前幾天，小米公司100多號人沉浸在即將到來的第一款產(chǎn)品誕生的亢奮中，但是，沒有人能告訴我們：未來，我們將能走多遠\做多大。彼時，小米網(wǎng)僅有三位開發(fā)工程師，在經(jīng)過兩個多月的緊張開發(fā)后，小米網(wǎng)將要第一次面對公眾在線銷售產(chǎn)品，接受大考。由于工程師資源極度緊張，我們甚至考慮過使用ECSHOP之類的開源系統(tǒng)搭建小米網(wǎng)，不過幸好我們很快放棄了這一想法。因為在3個月之后，我們就發(fā)現(xiàn)不得不對系統(tǒng)進行一輪重構(gòu)了。如果使用了第三方開源系統(tǒng)，為適應(yīng)原系統(tǒng)架構(gòu)，我們將長期被迫“遷就”原架構(gòu)而放棄很多更優(yōu)的設(shè)計，并為學(xué)習(xí)這個系統(tǒng)而付出時間成本。
第一代的小米網(wǎng)架構(gòu)非常簡單，如圖1所示。
圖1 第一代小米網(wǎng)架構(gòu)
我們實現(xiàn)了一個最基本的電商網(wǎng)站基本組件：在線銷售系統(tǒng)、訂單處理系統(tǒng)、倉儲和物流系統(tǒng)，其中物流只對接了兄弟公司凡客的子公司如風(fēng)達（現(xiàn)已獨立）。所有的業(yè)務(wù)系統(tǒng)共用一個數(shù)據(jù)庫。這樣運行了幾個月，發(fā)現(xiàn)網(wǎng)站訪問量越來越大，當(dāng)有新品銷售時，面對突然激增的大量訪問，數(shù)據(jù)庫壓力陡增，造成后端業(yè)務(wù)系統(tǒng)幾乎無法使用。
2012年上半年，在小米網(wǎng)運行半年多后，我們決定將業(yè)務(wù)系統(tǒng)進行拆分，首先將銷售系統(tǒng)剝離，之后逐步將越多越多的子系統(tǒng)拆分。拆分后各業(yè)務(wù)系統(tǒng)相對獨立，各自使用自己的數(shù)據(jù)庫，這樣就完美解決了不同系統(tǒng)搶占數(shù)據(jù)庫資源的問題，也讓模塊更清晰，程序員也能專注于自己負責(zé)的業(yè)務(wù)系統(tǒng)的開發(fā)，如圖2所示。
圖2 拆分業(yè)務(wù)系統(tǒng)
這種結(jié)構(gòu)隨著小米網(wǎng)子系統(tǒng)的增多，只運行了幾個月，我們就發(fā)現(xiàn)災(zāi)難開始顯現(xiàn)了：我們需要維護的接口越來越多。系統(tǒng)間接口調(diào)用圖變成了圖3這樣。
圖3 系統(tǒng)間接口調(diào)用圖
這張網(wǎng)越來越復(fù)雜，從而使系統(tǒng)越來越難以維護，問題層出不窮。為了讓各子系統(tǒng)盡量解耦，我們開發(fā)了小米網(wǎng)異步消息服務(wù)系統(tǒng)（Notify），讓它作為所有子系統(tǒng)異步通信的中間人，所有子系統(tǒng)只需與中間人通信，接口標(biāo)準化，將網(wǎng)狀結(jié)構(gòu)變?yōu)樾菭罱Y(jié)構(gòu)，大大降低了系統(tǒng)間通信成本，提高了開發(fā)效率，如圖4所示。
圖4 小米網(wǎng)異步消息服務(wù)系統(tǒng)（Notify）
此時，我們各子系統(tǒng)的網(wǎng)絡(luò)架構(gòu)也進行了相應(yīng)的升級，大體分三層：調(diào)度層、業(yè)務(wù)層、數(shù)據(jù)庫。在調(diào)度層，我們主要使用LVS、HAProxy做流量轉(zhuǎn)發(fā)和故障轉(zhuǎn)移；業(yè)務(wù)層則五花八門，不同語言，不同框架百花齊放；數(shù)據(jù)層主要使用MySQL、NoSQL存儲及緩存服務(wù)（Redis和Memcache）。
經(jīng)過以上改造，我們從結(jié)構(gòu)上，讓整個流程更清晰了。然而，流量在繼續(xù)增大，特別是小米網(wǎng)的爆品非常多，由于供應(yīng)鏈及硬件產(chǎn)業(yè)特性，導(dǎo)致新品上市時供應(yīng)量無法滿足用戶需求，用戶的熱情又遠超我們的期望。大量請求導(dǎo)致前端銷售系統(tǒng)的數(shù)據(jù)庫開始告急。我們急需采取一種方案，將峰值抹平。我們是一家電商網(wǎng)站，在交易時會有大量在線聯(lián)機事務(wù)處理，對數(shù)據(jù)一致性要求極高，所以經(jīng)過討論，我們決定采用淘寶開源的數(shù)據(jù)庫中間件產(chǎn)品Cobar來實現(xiàn)數(shù)據(jù)庫的水平切分。一共部署了32個實例，按用戶ID實現(xiàn)數(shù)據(jù)的均勻讀寫，每個實例都做了MM雙主高可用實現(xiàn)，如圖5所示。
圖5 采用淘寶開源的數(shù)據(jù)庫中間件產(chǎn)品Cobar
這種架構(gòu)保證了我們?nèi)粘５脑诰€銷售穩(wěn)定運行無壓力，但是，每逢重大產(chǎn)品發(fā)布時，仍然要面對數(shù)百萬QPS的搶購并發(fā)壓力。不光是對數(shù)據(jù)庫，對前端的應(yīng)用程序服務(wù)器一樣造成巨大的沖擊。非搶購時間和搶購時間的流量差距可達幾十倍到上百倍，如果我們按搶購峰值流量部署服務(wù)器，那將是一筆巨大的硬件資產(chǎn)浪費。在這個背景下，我們組織專門的人員開發(fā)了小米網(wǎng)的大型秒殺系統(tǒng)：BigTap。其實道理很簡單，大家都去銀行辦過業(yè)務(wù)，在銀行窗口排隊的多，但是我們幾乎很少看到有人在銀行的取號機面前排過隊。大秒系統(tǒng)其實就是充當(dāng)銀行的取號機的角色。它的業(yè)務(wù)邏輯非常簡單：判定用戶是否合法，合法則給這個用戶購買資格，用戶搶購成功；不合法則拒絕用戶請求，搶購失敗，如圖6所示。
圖6 小米網(wǎng)的大型秒殺系統(tǒng)BigTap
由于平時不搶購，大秒系統(tǒng)沒有任何流量，所以，我們將大秒系統(tǒng)整體遷移至AWS云上，搶購前一天，將系統(tǒng)擴容，搶購后，將服務(wù)器再下架，實現(xiàn)完美伸縮，大大節(jié)約了成本。
除了大秒系統(tǒng)以外，我們還額外開發(fā)了眾多小米網(wǎng)特色服務(wù)以支撐自己的業(yè)務(wù)。其中之一就是基于Redis和Twitter開源的Twemproxy開發(fā)的小米通用緩存服務(wù)（內(nèi)部代號MCC），集群中單節(jié)點達到14萬QPS，支持自動分片，熱加載，全Redis協(xié)議支持。由于MCC支撐了小米網(wǎng)全業(yè)務(wù)線的緩存服務(wù)，所以我們還將此服務(wù)設(shè)計成雙機房高可用架構(gòu)，如圖7所示。
圖7 小米雙機房架構(gòu)（圖中M表示主Redis實例，S表示從Redis實例）
常態(tài)下，雙機房同時工作，讀寫機房1的主和從實例。機房2的Mi-Twemproxy也讀寫機房1的主從實例。當(dāng)機房1故障時，只需修改機房2的Mi-Twemproxy讀寫機房2的從實例，并將此實例提升為主實例。當(dāng)機房2出現(xiàn)故障時，不需要做任何改動。不足之處是當(dāng)機房1出現(xiàn)故障時，機房2短期內(nèi)只有一個主實例工作，無冗余。
在搭建電商網(wǎng)站中，我們還要時刻考慮的一個業(yè)務(wù)問題是：如何盡快地將貨物售出，實現(xiàn)最快的庫存周轉(zhuǎn)，同時還要有好的購物體驗，在這個問題上，庫存系統(tǒng)的設(shè)計是一個很大的挑戰(zhàn)。我們嘗試考慮過很多電商的做法：按倉庫庫存賣商品。這種設(shè)計的好處是：倉與倉之間不用調(diào)撥，省去物流費用。缺點是，可能某個倉庫存過高賣不出，某個倉又缺貨，導(dǎo)致用戶無法下單購買。最終導(dǎo)致庫存周轉(zhuǎn)周期太長，降低了整體效率。小米網(wǎng)結(jié)合自身實際情況，設(shè)計了一套虛擬庫存分配系統(tǒng)，將各個倉作為庫存渠道，可以自由合并，拆分供給不同的銷售渠道，且可以自由調(diào)配。這種方法的缺點是訂單可能會跨倉發(fā)貨，增加物流成本，但是優(yōu)點也顯而易見：大大提高了庫存周轉(zhuǎn)率，用戶也獲得了較好的購物體驗，在以用戶為中心的小米網(wǎng)，這是我們首先會考慮的問題，設(shè)計如圖8所示。
圖8 小米虛擬庫存分配系統(tǒng)
跨倉調(diào)撥既然無法避免，那我們能做的是盡量減少跨倉調(diào)撥頻次，在多個倉庫之間調(diào)撥時盡量合理規(guī)劃。小米網(wǎng)的跨倉調(diào)撥問題實際上是一個多目標(biāo)線性規(guī)劃求最優(yōu)解的問題，我們將各倉當(dāng)前需求量，未來預(yù)測需求量，調(diào)撥線路和時間均考慮了進去。
在任何一家互聯(lián)網(wǎng)公司中，都必須要重視的一件事就是：監(jiān)控。服務(wù)器、應(yīng)用程序、我們的業(yè)務(wù)，都存在監(jiān)控需求。然而當(dāng)今好的監(jiān)控方案幾乎是空白，每個公司業(yè)務(wù)不同，特點不同，通用的監(jiān)控方案全都收效甚微。監(jiān)控的意義在于出故障時，責(zé)任人應(yīng)該第一時間知道并能采取措施。這要求監(jiān)控系統(tǒng)做到一是及時，二是準確。當(dāng)監(jiān)控對象是一家大型公司時，還要求監(jiān)控系統(tǒng)做到極其重要的一點是——有效。下面我會分析何為有效監(jiān)控。小米網(wǎng)一路走過來，做過很多監(jiān)控，當(dāng)業(yè)務(wù)觸發(fā)異常時就開始通過短信、郵件等告警。就算監(jiān)控點很少時也不足以構(gòu)成威脅，一旦觸發(fā)告警，馬上處理。然而，業(yè)務(wù)量激增后，監(jiān)控點非常多，責(zé)任人往往會在短時間內(nèi)收到大量重復(fù)的告警郵件和短信，時間一長，人都會疲勞，此時極容易忽略重大告警。所以，之前監(jiān)控系統(tǒng)設(shè)計的最大問題在于沒有區(qū)分異常和告警的關(guān)系，沒有設(shè)定異常的策略和告警的策略。如果一條告警送到了，但是沒有引起責(zé)任人的重視，那么這就是一條失敗的、無效的告警。遇到異常馬上觸發(fā)告警是不科學(xué)的設(shè)計。我們新設(shè)計的監(jiān)控系統(tǒng)的目的是大大提高有效告警量，其核心思想如下。
異常判斷策略：
異常判定函數(shù)
- val，監(jiān)控結(jié)果取值
- val(‘key’)，結(jié)果若有多個字段，如Server各參數(shù)，取指定 key 的值
- count，結(jié)果若有多條，取結(jié)果集條數(shù)
- exist，監(jiān)控結(jié)果是否存在
- empty，監(jiān)控結(jié)果是否為空
異常判定表達式
- val>3 ，取值大于3時判定為異常
- count>10，結(jié)果集條數(shù)大于10時判定為異常
- exist，結(jié)果不為空即判定為異常
- empty，結(jié)果為空即判定為異常
告警判斷策略：
告警判定函數(shù)
- times，當(dāng)前連續(xù)異常次數(shù) percent(num)，最近n次監(jiān)控結(jié)果中異常的百分比
- limit(num)，告警次數(shù)限制，num=0為不限制
- snooze(minutes)，不限制告警次數(shù)時，異常周期內(nèi)每隔minutes分鐘告警一次 告警
判定策表達式
- times>3，連續(xù)異常3次則告警
- percent(10)>0.8，最近10次監(jiān)控結(jié)果中異常數(shù)大于80%則告警
-
times>3 && limit(0) && snooze(30)，大于3次異常開始告警，異常周期內(nèi)，每隔30分鐘告警一次
通過這兩個策略組合，能夠?qū)崿F(xiàn)最大限度不打擾人的有效告警。
最后，我在此稍提一下小米網(wǎng)的服務(wù)化。這是目前我們正在進行的技術(shù)架構(gòu)大升級，采用Thrift+ETCD+Go+PHP實現(xiàn)。小米SOA框架完全自行開發(fā)，框架本身由Go語言實現(xiàn)。非Go語言的項目，我們通過兩個小插件：服務(wù)發(fā)現(xiàn)助手和服務(wù)注冊助手幫助接入到我們的服務(wù)平臺。關(guān)于服務(wù)化的意義，網(wǎng)上有非常多的詳細的分析，在此不再贅述。對于越來越大的技術(shù)架構(gòu)體系，服務(wù)化將是未來的趨勢。
發(fā)表評論
最新文章
分類目錄
熱門排行榜
What Can We Do?
