傳統(tǒng)企業(yè)電商峰值系統(tǒng)應(yīng)對實踐

1、摘要：雙11這樣的場景要求電商對系統(tǒng)進(jìn)行合理的峰值架構(gòu)設(shè)計，以保證業(yè)務(wù)的順利開展。那么一個能夠應(yīng)對短時間流量暴漲的電商系統(tǒng)，在同時考慮成本因素的情況下，具體會遇到哪些瓶頸，主要需要解決哪些層面的技術(shù)障礙呢?近年來，隨著電子商務(wù)交易額在社會消費品零售總額中占比的不斷提升，電子商務(wù)越來越成為傳統(tǒng)企業(yè)不可忽視的銷售渠道之一，甚至很多具備前瞻性眼光的傳統(tǒng)企業(yè)，已開始了利用電子商務(wù)手段改造其線下業(yè)務(wù)的探索。但是，傳統(tǒng)企業(yè)在執(zhí)行電子商務(wù)項目的過程中，特別是在應(yīng)對峰值方面，由于對互聯(lián)網(wǎng)峰值架構(gòu)的不熟悉，經(jīng)常出現(xiàn)一些認(rèn)識上的誤區(qū)，造成系統(tǒng)上線后出現(xiàn)不穩(wěn)定甚至連續(xù)宕機的情況，不但在經(jīng)濟上造成損失，而且對企業(yè)的品

2、牌也造成了傷害。作為電子商務(wù)技術(shù)與服務(wù)提供商，商派已執(zhí)行了近千個傳統(tǒng)企業(yè)的電商項目，收獲了很多的經(jīng)驗與教訓(xùn)。下面我們就傳統(tǒng)企業(yè)電商峰值系統(tǒng)的設(shè)計與維護(hù)過程中常見的問題進(jìn)行探討。在一個典型的電商系統(tǒng)中，核心對象主要有三個：會員、商品和訂單。整個系統(tǒng)主要是為消費者服務(wù)，運營模型以流量與用戶量為核心，流量以導(dǎo)入新客戶為主，用戶量代表著老客戶的貢獻(xiàn)。無論是大規(guī)模進(jìn)行新客戶獲取還是老客戶營銷，都會給系統(tǒng)帶來極大的壓力，其中特別是限時搶購、秒殺等營銷方式尤為明顯，這就要求我們對系統(tǒng)進(jìn)行合理的峰值架構(gòu)設(shè)計，以保證業(yè)務(wù)的順利開展。那么一個能夠應(yīng)對業(yè)務(wù)峰值的電商系統(tǒng)，在同時考慮成本因素的情況下，具體會遇到哪些瓶

3、頸，主要需要解決哪些層面的技術(shù)障礙呢？大規(guī)模查詢優(yōu)化對會員與商品的大規(guī)模查詢是一個常見的場景。例如，在一個秒殺系統(tǒng)中，在開放購買的時間點附近，會產(chǎn)生大量的基于會員和商品的查詢請求，通常情況下，比平時的請求量會多數(shù)十倍甚至百倍，同時訪問帶寬也會相應(yīng)大幅增加。在我們以往的運維實踐中，曾經(jīng)出現(xiàn)過由于帶寬預(yù)估不足造成無法訪問的情況。應(yīng)對類似的大規(guī)模查詢業(yè)務(wù)，只依靠數(shù)據(jù)庫的能力是遠(yuǎn)遠(yuǎn)不足的，因此，我們需要用到大量的緩存架構(gòu)，將峰值的訪問壓力由磁盤轉(zhuǎn)向內(nèi)存。一般來說，商品的主數(shù)據(jù)、會員的登錄，系統(tǒng)的Session、頁面都可以采用Memcache、Redis、Varnish等KV架構(gòu)進(jìn)行緩存。另外，某些動態(tài)

4、數(shù)據(jù)在特定業(yè)務(wù)場景下也可以進(jìn)行緩存。例如，由于庫存量在下單前只用于控制前臺是否可售展示，對一致性要求不高，只要求保證最終一致性，因此也可以在此場景下使用內(nèi)存進(jìn)行緩存。商品搜索和基于屬性的面包屑導(dǎo)航等場景，在峰值下對數(shù)據(jù)庫的壓力也非常明顯。由于該業(yè)務(wù)不具備高命中率的特征，所以緩存解決方案不適用。我們通常需要使用搜索引擎去解決，一般常見的搜索引擎解決方案有Sphinx、Lucene等。前臺的應(yīng)用服務(wù)器需要設(shè)計成無狀態(tài)的可水平擴展架構(gòu)，這樣在高負(fù)載下只要通過簡單地增加應(yīng)用服務(wù)器即可通過負(fù)載均衡設(shè)備線性擴展前端的負(fù)載能力。分布式架構(gòu)設(shè)計一個完整的電商系統(tǒng)，分為前臺交易系統(tǒng)與后臺作業(yè)系統(tǒng)，前后臺共庫是傳

5、統(tǒng)企業(yè)在設(shè)計電商項目時的一個常見做法。但這個做法引發(fā)了上線后的諸多麻煩。在前臺交易系統(tǒng)處于峰值情況下，數(shù)據(jù)庫本身已存在很大的壓力，此時如果后臺作業(yè)系統(tǒng)產(chǎn)生大規(guī)模的查詢或?qū)懭胝埱?，則很容易造成數(shù)據(jù)庫無法響應(yīng)。我們在很多客戶案例中發(fā)現(xiàn)，如果前后臺共庫，正常非峰值情況下，每日訂單數(shù)只要超過2000單，就會不同程度地出現(xiàn)前后臺互相干擾，數(shù)據(jù)庫成為主要瓶頸。此時，客戶不得不在系統(tǒng)高峰時停止在后臺作業(yè)系統(tǒng)上的操作，這給業(yè)務(wù)造成了很大傷害，發(fā)貨延時、客服水平下降、統(tǒng)計不準(zhǔn)確等情況成了家常便飯。實際上，從架構(gòu)上來說，前臺交易系統(tǒng)與后臺作業(yè)系統(tǒng)服務(wù)的用戶對象不同，前者是消費者，后者是企業(yè)內(nèi)部員工，完全可以進(jìn)行系

6、統(tǒng)分離，兩者之間采用消息隊列進(jìn)行異步訂單傳輸，以隔離互相之間的影響。當(dāng)然，對于交易系統(tǒng)，我們也要根據(jù)業(yè)務(wù)特征進(jìn)行分布式設(shè)計，提升業(yè)務(wù)擴展性、應(yīng)對高負(fù)載。例如對商品貨架系統(tǒng)、會員系統(tǒng)、核心交易系統(tǒng)、資金系統(tǒng)、日志系統(tǒng)等以高內(nèi)聚、低耦合的原則進(jìn)行分離，以分別根據(jù)不同的訪問特征進(jìn)行優(yōu)化。根據(jù)分布式架構(gòu)的CAP理論，Consistency（一致性）、 Availability（可用性）和Partition tolerance（分區(qū)容忍性）最多只能同時滿足兩點。對于一個峰值系統(tǒng)而言，分布式（分區(qū)）設(shè)計是必然的，可用性也是基礎(chǔ)要求，因此，我們只能放棄一致性要求，只達(dá)到最終一致性。不過，在一個電商系統(tǒng)的架構(gòu)

7、設(shè)計中，最容易出現(xiàn)的問題是濫用CAP原則。例如在交易過程中，后臺的供應(yīng)能力（庫存）是至關(guān)重要的，在交易生成過程必須要保證嚴(yán)格一致性，而不是最終一致性，這就要求我們以事務(wù)的方式來解決。否則，雖然在架構(gòu)實踐中很容易達(dá)到從容應(yīng)對峰值訪問的目的，但超賣等傷害業(yè)務(wù)的現(xiàn)象必然會出現(xiàn)。在分布式系統(tǒng)設(shè)計中，必然要求我們采用面向服務(wù)的體系結(jié)構(gòu)（SOA）。但需要在設(shè)計中注意幾點。第一，在峰值系統(tǒng)中，每一個多余字節(jié)的傳輸都意味著對系統(tǒng)的極大開銷，以每日1000萬PV為例，假設(shè)這是每個請求都需要調(diào)用的服務(wù)，每新增一個字節(jié)，就意味著會新增10MB的流量。第二，千萬不要直接使用自己企業(yè)內(nèi)部IT原來部署的服務(wù)。這是因為企業(yè)

8、內(nèi)部原有的SOA服務(wù)不是為互聯(lián)網(wǎng)峰值系統(tǒng)所設(shè)計的。我們曾經(jīng)有一個客戶，在電商網(wǎng)站上使用了企業(yè)內(nèi)部IT提供的客戶驗證服務(wù)，看上去只是一個簡單查詢，結(jié)果甫一上線，直接導(dǎo)致該服務(wù)崩潰，進(jìn)而引發(fā)整個內(nèi)部IT SOA體系的下線，對內(nèi)部系統(tǒng)造成的影響用了好幾天才得以消除，更不用說對線上系統(tǒng)的影響了，嚴(yán)重傷害了企業(yè)的形象。第三，冪等原則。假設(shè)所有的服務(wù)調(diào)用都是不可靠的，所以重試是常態(tài)，因此對于重復(fù)的API寫入操作應(yīng)進(jìn)行判重處理。前臺交易系統(tǒng)的數(shù)據(jù)庫架構(gòu)對于一個典型的前臺交易系統(tǒng)而言，對數(shù)據(jù)庫的讀寫比例差距很大，讀操作遠(yuǎn)大于寫操作，此時除了通過前面提到的緩存及搜索方面的優(yōu)化以外，一般還會對數(shù)據(jù)庫的架構(gòu)進(jìn)行優(yōu)化

9、。以MySQL為例，可以采用主從讀寫分離的方式進(jìn)行調(diào)優(yōu)。也就是，部署一主多從的MySQL實例，應(yīng)用層寫操作只發(fā)生在主實例上，讀操作只發(fā)生在從實例上，此時通過調(diào)整從實例的數(shù)量，可以很大程度地緩解對數(shù)據(jù)庫的查詢壓力。在使用主從讀寫分離的MySQL架構(gòu)中，比較常見的是在峰值時出現(xiàn)寫入操作擁堵，其后果可能是系統(tǒng)不響應(yīng)或主從復(fù)制延遲。主從復(fù)制延遲在前臺很難立即發(fā)現(xiàn)，直到有用戶發(fā)現(xiàn)注冊或下單問題時，通過排查才能發(fā)現(xiàn)。所以對一個主從讀寫分離系統(tǒng)，必須做好主從復(fù)制延遲的監(jiān)控。如果出現(xiàn)了復(fù)制延遲等性能問題，我們就應(yīng)該著力分析瓶頸到底在哪里。除了對配置參數(shù)和硬件進(jìn)行調(diào)優(yōu)以外，一般在架構(gòu)上存在幾種處理方法。第一，水

10、平切分，常見的情況是對訂單歸檔，對于一個電商系統(tǒng)而言，商品和用戶是核心，訂單數(shù)據(jù)從某種意義上來說只是日志而已，當(dāng)然也有一些系統(tǒng)層面的水平切分方案。第二，熱點隔離，如在秒殺情況下，很可能只有一到兩個商品參與，我們完全可以將對相關(guān)商品的庫存寫入等操作與其他商品隔離開來。當(dāng)然這在應(yīng)用層上要做的工作比較多。第三，異步寫入。對于事務(wù)要求不嚴(yán)格的寫入，如一些日志的寫入，可以采用先寫入隊列，然后再以一定速率寫入數(shù)據(jù)庫的方法降解壓力。第四，報表等只讀類應(yīng)用可以獨立調(diào)用一個專用的從庫。服務(wù)降級在設(shè)計峰值系統(tǒng)時必須考慮當(dāng)系統(tǒng)壓力劇增時，需要根據(jù)業(yè)務(wù)與流量情況，對某些服務(wù)或頁面進(jìn)行有策略的降級，以釋放服務(wù)器資源保證

11、核心業(yè)務(wù)的運行。服務(wù)降級一般有業(yè)務(wù)層降級和系統(tǒng)層降級兩種。業(yè)務(wù)層降級，指的是對除核心主流程以外的功能，根據(jù)系統(tǒng)壓力情況進(jìn)行有策略的關(guān)閉，從而達(dá)成服務(wù)降級的目的。例如，停止某些運算復(fù)雜的促銷配置、關(guān)閉某些頁面的訪問或?qū)懭氩僮鞯?。一般對于前臺交易系統(tǒng)來說，業(yè)務(wù)層降級點的優(yōu)先級排序是根據(jù)對轉(zhuǎn)化率的影響進(jìn)行的。而對于后臺作業(yè)系統(tǒng)，以商派的ERP為例，在峰值時會采用關(guān)閉數(shù)據(jù)條數(shù)顯示、實時報表查詢等非主業(yè)務(wù)流程的模塊或功能，全力保障訂單處理作業(yè)的順利運轉(zhuǎn)。系統(tǒng)層降級，指的是通過對操作系統(tǒng)、Web服務(wù)器、數(shù)據(jù)庫等系統(tǒng)架構(gòu)層面的配置進(jìn)行調(diào)整，從而達(dá)成服務(wù)降級的目的。一般的方法有訪問限流、寫入限制、異步延遲持久

12、化等?？傮w來說，系統(tǒng)層降級對用戶體驗的影響會比業(yè)務(wù)層降級大很多，但在執(zhí)行上比較簡單，實現(xiàn)成本較低。注意，服務(wù)降級方案可能會在不同程度上影響用戶體驗、交易系統(tǒng)的轉(zhuǎn)化率及業(yè)務(wù)處理流程，因此，開發(fā)運維方需要事先與業(yè)務(wù)方或客戶方做好充分的溝通并經(jīng)審核同意后，再進(jìn)行控制點的埋點與開發(fā)，同時還應(yīng)寫入峰值情況應(yīng)對預(yù)案。監(jiān)控與運維一個成功運行的電子商務(wù)峰值系統(tǒng)，三分靠研發(fā)，七分靠運維。而一個完善的監(jiān)控系統(tǒng)則是運維的眼睛。通過監(jiān)控到的指標(biāo)變化，運維人員可以對系統(tǒng)資源進(jìn)行人工或自動化調(diào)整，可以產(chǎn)生告警通知進(jìn)行故障處理，也可以及時作出服務(wù)降級決策。常見的監(jiān)控系統(tǒng)分為三類：系統(tǒng)性能監(jiān)控、用戶體驗監(jiān)控和業(yè)務(wù)實時監(jiān)控。系

13、統(tǒng)性能監(jiān)控，主要是對下列指標(biāo)進(jìn)行監(jiān)控：服務(wù)器指標(biāo)，如CPU、內(nèi)存、磁盤等；數(shù)據(jù)庫指標(biāo)，如QPS、主從復(fù)制延時、進(jìn)程、慢查詢等。另外，根據(jù)采用的架構(gòu)不同，還有消息隊列堆積監(jiān)控等。通過對這一系列系統(tǒng)指標(biāo)進(jìn)行監(jiān)控，可以發(fā)現(xiàn)運行健康狀態(tài)出現(xiàn)問題的服務(wù)與服務(wù)器，同時也可以評估系統(tǒng)的繁忙程度，以供及時處理。對于服務(wù)器指標(biāo)監(jiān)控，一般可以選用Nagios、Cacti進(jìn)行，數(shù)據(jù)庫監(jiān)控可以使用相關(guān)數(shù)據(jù)庫提供的監(jiān)控工具或自行結(jié)合Nagios和Cacti進(jìn)行少量的二次開發(fā)。用戶體驗監(jiān)控，主要是對業(yè)務(wù)關(guān)鍵流程進(jìn)行監(jiān)控，如對頁面訪問、用戶登錄流程、下單流程等流程的可用性進(jìn)行監(jiān)控，監(jiān)控可以由Last mile最終客戶模擬或

14、由各地IDC機房部署的測試腳本發(fā)起。用戶體驗監(jiān)控對于及時發(fā)現(xiàn)一些從系統(tǒng)監(jiān)控層上無法發(fā)現(xiàn)的問題或尚未列入監(jiān)控的指標(biāo)異常具有重大意義，如系統(tǒng)Bug、之前提到的主動同步延遲等?？梢越Y(jié)合當(dāng)前使用的監(jiān)控工具進(jìn)行一定程度的二次開發(fā)，市場上也有一些第三方提供的云服務(wù)可供選擇。業(yè)務(wù)實時監(jiān)控，主要是指對業(yè)務(wù)數(shù)據(jù)進(jìn)行監(jiān)控，如PV、UV、轉(zhuǎn)化率、下單量、支付量、發(fā)貨量和倉內(nèi)作業(yè)效率數(shù)據(jù)，在給業(yè)務(wù)提供相關(guān)決策的同時，也可以用于輔助判斷系統(tǒng)問題。業(yè)務(wù)實時監(jiān)控一般分為入侵型與非入侵型兩種。入侵型需要在程序的各個流程節(jié)點上進(jìn)行埋點，相關(guān)動作被觸發(fā)后，通過消息隊列推送給監(jiān)控界面進(jìn)行展示；非入侵型一般通過分析網(wǎng)絡(luò)流量，匹配出相應(yīng)的請求進(jìn)行內(nèi)容分析，從而判斷出相關(guān)目標(biāo)事件的發(fā)生并進(jìn)行統(tǒng)計與展示監(jiān)控界面。入侵型監(jiān)控系統(tǒng)一般需要進(jìn)行定制開發(fā)，但實現(xiàn)邏輯簡單，技術(shù)難度較高；非入侵型監(jiān)控系統(tǒng)開發(fā)難度較高，但部署配置簡單，同時由于無需在目標(biāo)系統(tǒng)上進(jìn)行二