[置頂] 電商峰值系統架構設計


1.1 系統架構設計目錄

摘要:11來臨之際,《程序員》以電商峰值系統架構設計為主題,力邀京東、當當、小米、1號店、海爾商城、唯品會、蘑菇街、麥包包等電商企業,及商派、基調網絡等服務公司,分享電商峰值系統架構設計的最佳技術實踐。

20091111,淘寶商城(現名天貓)拉開網購狂歡節的序幕,各大電商的促銷浪潮此起彼伏。此時的電商大戰不僅是價格之爭,更是技術的較量。如何設計電商峰值系統來更好地滿足用戶蜂擁而至的訪問,如何在海量數據處理中實時發現有效信息並轉化為商機,成為眾多電商企業密切關注的問題。

2014年雙11即將來臨之際,《程序員》雜志以電商峰值系統架構設計為主題,力邀京東、當當、小米、1號店、海爾商城、唯品會、蘑菇街、麥包包等國內知名電商企業,以及商派、基調網絡等相關服務公司,分享電商峰值系統架構設計的最佳技術實踐。讓讀者切身感受,這場購物狂歡背后的技術狂歡。

1快穩炫:電商峰值系統架構三字訣

2傳統企業電商峰值系統應對實踐

3當當網系統分級與海量信息動態發布實踐

4京東峰值系統設計

5“米粉節”背后的故事——小米網搶購系統開發實踐

6海爾電商峰值系統架構設計最佳實踐

7唯品會峰值系統的架構演變

81號店電商峰值與流式計算

9如何在雙11中創造99.99%的可用性——蘑菇街在大型促銷活動中的穩定性實踐

10履單流程的彈性架構——麥包包峰值架構實踐

11電商峰值監控經驗談

文章來源:http://www.csdn.net/article/2014-11-04/2822459

 

1.2 快穩炫:電商峰值系統架構三字訣

摘要:隨着電商促銷規模越來越大,競爭點已不僅是價格,而延生到背后的技術:如何設計峰值系統來應對爆發流量,如何實時發現有效信息轉化為商機,成為關鍵點。本文結合快穩炫三字訣,講述電商峰值系統架構設計的最佳實踐。

20091111日,淘寶商城光棍節開啟了網購促銷全新規模的序幕,隨后各大電商的促銷浪潮此起彼伏且規模越來越大。在用戶暢享購物狂歡的背后,電商系統承受着嚴峻的考驗。電商大戰已不僅是價格之爭,更是后台和技術的較量。大型促銷活動帶來的是流量暴漲,在高訪問量的沖擊下,電商系統會受到以下挑戰:瞬間訪問量可能是平時的幾十倍;網絡帶寬被占滿,用戶響應很慢;機器負載高甚至宕機;數據庫壓力過大導致服務不可用。

時間就是金錢,效率就是生命。如何設計電商峰值系統來更好地滿足用戶蜂擁而至的訪問,如何在海量數據處理中實時發現有效信息並轉化為商機,成為眾多電商架構師都在認真思考的問題。針對峰值現象,各家電商陸續推出了自己的解決方案。設計良好的系統架構猶如電商平台的發動引擎,需要擁有非凡的動力系統以滿足極致的用戶體驗和強勁的峰值承載力。

本期《程序員》雜志在基於海爾電商技術沙龍第九期研討內容的基礎上,組織了京東、當當、小米、一號店、海爾商城、唯品會、蘑菇街、麥包包等國內知名電商企業,以及商派、聽雲等相關服務公司,進行了電商峰值系統架構設計的最佳技術實踐專題分享。

縱觀上述各家電商峰值系統的架構設計,由於電商規模、商業模式以及技術選型的不同,其技術方案多彩多樣、百花齊放,着實令人興奮,全面展現了互聯網技術開放和創新的特征。下面從這些架構設計方案中,抽象和總結出其共性相通的核心思路,進行一些概述。核心思路集中表現為:采用分而治之的思想,大系統小做,小系統大做。濃縮一下就是三個字:快、穩、炫。

——天下武功,唯快不破

快的目標是確保用戶端快速流暢的體驗。概括來說,可以通過以下技術手段實現快的目標。

對前端頁面的處理

·         將有效期較長的靜態頁面通過CDNContent Delivery Network,內容分發網絡)緩存到離用戶最近的服務節點上。

·         將有效期較短或者需要對失效時間做最大限度控制的靜態頁面,通過類似於Memcache的高速緩存系統或類似於Squid的反向代理系統緩存在服務端。

·         將混合型頁面(如商品單頁)進行動靜分離,靜態數據(如商品介紹等)緩存在本地,動態數據(如可用庫存和促銷價格等)異步進行加載。

對后端數據的處理

·         數據庫SQL慢查詢優化。例如,重構相關索引,對where子句進行優化等。

·         數據庫讀寫分離。例如,MySQLMaster/Slave結構。

·         數據庫分庫分表。這是減輕單個數據庫服務器壓力的有效手段,不過同時也會帶來系統的復雜性,是魚和熊掌之間的關系。

對網絡傳輸的處理

·         執行負載均衡,第四層交換按實現分類,分為硬件實現和軟件實現。通過硬件實現一般都由專業的硬件廠商作為商業解決方案提供,如F5等,這些產品非常昂貴,但能夠提供非常優秀的性能和很靈活的管理能力。通過軟件實現,如LVS等,雖然性能比專業硬件稍差,但軟件實現配置起來更靈活。

——不管風吹浪打,勝似閑庭信步

穩的目標是確保系統端穩定可靠的服務。無論在任何情況下,都要做到盡可能不宕機、不出錯。要做到這一點,可以在以下幾個方面做文章。

系統解耦

拆分業務模塊和功能模塊,使得每個模塊都做到高度內聚,然后用SOA,通過嚴格定義模塊之間的服務接口,做到模塊間的松散耦合。在一個模塊發生問題時盡可能不影響其他模塊的執行,尤其不能影響關鍵業務的執行。同時,可以對單個模塊進行橫向擴展,尤其是對關鍵的業務模塊,以確保關鍵業務一定不能受影響。需要注意的是,模塊划分的粒度應進行權衡,過細的粒度雖然可以帶來更多的靈活性,但也會帶來編程的復雜性。

有損服務

根據CAPConsistency一致性,Availability可用性,Partition Tolerance分區容忍性)理論,三者不可得兼。對於電商平台,其中多數應用並不需要很強的一致性,因此合理的方式是用犧牲部分一致性來換取較高的可用性。有損服務(服務降級)就是一種提高系統穩定性和可用性的有效實踐。在電商系統中,要優先保證類目瀏覽、產品單頁和訂單流程能夠執行。

數據庫減負

我們知道數據庫是所有節點中最不容易擴展的,復雜的SQL查詢條件會導致數據庫負擔過重,此時可用增加應用計算中間服務器的方式,通過高效簡潔的SQL查詢,應用計算中間服務器一次性地從數據庫中取出最小全集的數據行,然后在內存中利用算法剔除冗余數據,以應用算法的復雜度換數據庫負擔的方式。

——運籌於帷幄之中,決勝於千里之外

炫的目標是確保業務端實時高效的調度。從日志收集和實時計算入手,通過對用戶行為數據的可視化(圖1),及時發現問題和洞察商機,調度應用系統,對用戶多樣化和個性化的需求進行智能引導。

 

1  用戶行為數據可視化

審視當下暢想未來,隨着雲計算的興起和成熟以及智能移動設備的普及,電子商務與這兩者深度結合,必將引起一場激動人心的變革。各種設備上的在線商城將是主流的商業模式,目前分類式的購物體驗平台將演變成一個高度集成以用戶為中心的全流程價值交互體驗雲平台。該雲平台有四大核心組成部分,環環相扣形成一個閉環(圖2)。

 

2  全流程價值交互體驗雲平台

通過雲屏(TouchApp),打造流連忘返的體驗;通過雲網(DataLink),提供隨時隨地的服務;通過雲芯(FansTree),進行細致入微的洞察;通過雲播(Broadcast),推送引人入勝的營銷。

最后,請你放下手中的所有工作,找個陽光明媚安靜的地方,泡杯香濃的咖啡,細細品味本期各大電商為你帶來的最佳技術實踐

文章來源:http://www.csdn.net/article/2014-11-11/2822572

1.3 傳統企業電商峰值系統應對實踐

 

摘要:11這樣的場景要求電商對系統進行合理的峰值架構設計,以保證業務的順利開展。那么一個能夠應對短時間流量暴漲的電商系統,在同時考慮成本因素的情況下,具體會遇到哪些瓶頸,主要需要解決哪些層面的技術障礙呢?

近年來,隨着電子商務交易額在社會消費品零售總額中占比的不斷提升,電子商務越來越成為傳統企業不可忽視的銷售渠道之一,甚至很多具備前瞻性眼光的傳統企業,已開始了利用電子商務手段改造其線下業務的探索。

但是,傳統企業在執行電子商務項目的過程中,特別是在應對峰值方面,由於對互聯網峰值架構的不熟悉,經常出現一些認識上的誤區,造成系統上線后出現不穩定甚至連續宕機的情況,不但在經濟上造成損失,而且對企業的品牌也造成了傷害。

作為電子商務技術與服務提供商,商派已執行了近千個傳統企業的電商項目,收獲了很多的經驗與教訓。下面我們就傳統企業電商峰值系統的設計與維護過程中常見的問題進行探討。

在一個典型的電商系統中,核心對象主要有三個:會員、商品和訂單。整個系統主要是為消費者服務,運營模型以流量與用戶量為核心,流量以導入新客戶為主,用戶量代表着老客戶的貢獻。無論是大規模進行新客戶獲取還是老客戶營銷,都會給系統帶來極大的壓力,其中特別是限時搶購、秒殺等營銷方式尤為明顯,這就要求我們對系統進行合理的峰值架構設計,以保證業務的順利開展。那么一個能夠應對業務峰值的電商系統,在同時考慮成本因素的情況下,具體會遇到哪些瓶頸,主要需要解決哪些層面的技術障礙呢?

大規模查詢優化

對會員與商品的大規模查詢是一個常見的場景。例如,在一個秒殺系統中,在開放購買的時間點附近,會產生大量的基於會員和商品的查詢請求,通常情況下,比平時的請求量會多數十倍甚至百倍,同時訪問帶寬也會相應大幅增加。在我們以往的運維實踐中,曾經出現過由於帶寬預估不足造成無法訪問的情況。

應對類似的大規模查詢業務,只依靠數據庫的能力是遠遠不足的,因此,我們需要用到大量的緩存架構,將峰值的訪問壓力由磁盤轉向內存。一般來說,商品的主數據、會員的登錄,系統的Session、頁面都可以采用MemcacheRedisVarnishKV架構進行緩存。另外,某些動態數據在特定業務場景下也可以進行緩存。例如,由於庫存量在下單前只用於控制前台是否可售展示,對一致性要求不高,只要求保證最終一致性,因此也可以在此場景下使用內存進行緩存。

商品搜索和基於屬性的面包屑導航等場景,在峰值下對數據庫的壓力也非常明顯。由於該業務不具備高命中率的特征,所以緩存解決方案不適用。我們通常需要使用搜索引擎去解決,一般常見的搜索引擎解決方案有SphinxLucene等。前台的應用服務器需要設計成無狀態的可水平擴展架構,這樣在高負載下只要通過簡單地增加應用服務器即可通過負載均衡設備線性擴展前端的負載能力。

分布式架構設計

一個完整的電商系統,分為前台交易系統與后台作業系統,前后台共庫是傳統企業在設計電商項目時的一個常見做法。但這個做法引發了上線后的諸多麻煩。在前台交易系統處於峰值情況下,數據庫本身已存在很大的壓力,此時如果后台作業系統產生大規模的查詢或寫入請求,則很容易造成數據庫無法響應。我們在很多客戶案例中發現,如果前后台共庫,正常非峰值情況下,每日訂單數只要超過2000單,就會不同程度地出現前后台互相干擾,數據庫成為主要瓶頸。此時,客戶不得不在系統高峰時停止在后台作業系統上的操作,這給業務造成了很大傷害,發貨延時、客服水平下降、統計不准確等情況成了家常便飯。實際上,從架構上來說,前台交易系統與后台作業系統服務的用戶對象不同,前者是消費者,后者是企業內部員工,完全可以進行系統分離,兩者之間采用消息隊列進行異步訂單傳輸,以隔離互相之間的影響。

當然,對於交易系統,我們也要根據業務特征進行分布式設計,提升業務擴展性、應對高負載。例如對商品貨架系統、會員系統、核心交易系統、資金系統、日志系統等以高內聚、低耦合的原則進行分離,以分別根據不同的訪問特征進行優化。

根據分布式架構的CAP理論,Consistency(一致性)、 Availability(可用性)和Partition tolerance(分區容忍性)最多只能同時滿足兩點。對於一個峰值系統而言,分布式(分區)設計是必然的,可用性也是基礎要求,因此,我們只能放棄一致性要求,只達到最終一致性。不過,在一個電商系統的架構設計中,最容易出現的問題是濫用CAP原則。例如在交易過程中,后台的供應能力(庫存)是至關重要的,在交易生成過程必須要保證嚴格一致性,而不是最終一致性,這就要求我們以事務的方式來解決。否則,雖然在架構實踐中很容易達到從容應對峰值訪問的目的,但超賣等傷害業務的現象必然會出現。

在分布式系統設計中,必然要求我們采用面向服務的體系結構(SOA)。但需要在設計中注意幾點。第一,在峰值系統中,每一個多余字節的傳輸都意味着對系統的極大開銷,以每日1000PV為例,假設這是每個請求都需要調用的服務,每新增一個字節,就意味着會新增10MB的流量。第二,千萬不要直接使用自己企業內部IT原來部署的服務。這是因為企業內部原有的SOA服務不是為互聯網峰值系統所設計的。我們曾經有一個客戶,在電商網站上使用了企業內部IT提供的客戶驗證服務,看上去只是一個簡單查詢,結果甫一上線,直接導致該服務崩潰,進而引發整個內部IT SOA體系的下線,對內部系統造成的影響用了好幾天才得以消除,更不用說對線上系統的影響了,嚴重傷害了企業的形象。第三,冪等原則。假設所有的服務調用都是不可靠的,所以重試是常態,因此對於重復的API寫入操作應進行判重處理。

前台交易系統的數據庫架構

對於一個典型的前台交易系統而言,對數據庫的讀寫比例差距很大,讀操作遠大於寫操作,此時除了通過前面提到的緩存及搜索方面的優化以外,一般還會對數據庫的架構進行優化。

MySQL為例,可以采用主從讀寫分離的方式進行調優。也就是,部署一主多從的MySQL實例,應用層寫操作只發生在主實例上,讀操作只發生在從實例上,此時通過調整從實例的數量,可以很大程度地緩解對數據庫的查詢壓力。

在使用主從讀寫分離的MySQL架構中,比較常見的是在峰值時出現寫入操作擁堵,其后果可能是系統不響應或主從復制延遲。主從復制延遲在前台很難立即發現,直到有用戶發現注冊或下單問題時,通過排查才能發現。所以對一個主從讀寫分離系統,必須做好主從復制延遲的監控。

如果出現了復制延遲等性能問題,我們就應該着力分析瓶頸到底在哪里。除了對配置參數和硬件進行調優以外,一般在架構上存在幾種處理方法。第一,水平切分,常見的情況是對訂單歸檔,對於一個電商系統而言,商品和用戶是核心,訂單數據從某種意義上來說只是日志而已,當然也有一些系統層面的水平切分方案。第二,熱點隔離,如在秒殺情況下,很可能只有一到兩個商品參與,我們完全可以將對相關商品的庫存寫入等操作與其他商品隔離開來。當然這在應用層上要做的工作比較多。第三,異步寫入。對於事務要求不嚴格的寫入,如一些日志的寫入,可以采用先寫入隊列,然后再以一定速率寫入數據庫的方法降解壓力。第四,報表等只讀類應用可以獨立調用一個專用的從庫。

服務降級

在設計峰值系統時必須考慮當系統壓力劇增時,需要根據業務與流量情況,對某些服務或頁面進行有策略的降級,以釋放服務器資源保證核心業務的運行。服務降級一般有業務層降級和系統層降級兩種。

業務層降級,指的是對除核心主流程以外的功能,根據系統壓力情況進行有策略的關閉,從而達成服務降級的目的。例如,停止某些運算復雜的促銷配置、關閉某些頁面的訪問或寫入操作等。一般對於前台交易系統來說,業務層降級點的優先級排序是根據對轉化率的影響進行的。而對於后台作業系統,以商派的ERP為例,在峰值時會采用關閉數據條數顯示、實時報表查詢等非主業務流程的模塊或功能,全力保障訂單處理作業的順利運轉。

系統層降級,指的是通過對操作系統、Web服務器、數據庫等系統架構層面的配置進行調整,從而達成服務降級的目的。一般的方法有訪問限流、寫入限制、異步延遲持久化等。總體來說,系統層降級對用戶體驗的影響會比業務層降級大很多,但在執行上比較簡單,實現成本較低。注意,服務降級方案可能會在不同程度上影響用戶體驗、交易系統的轉化率及業務處理流程,因此,開發運維方需要事先與業務方或客戶方做好充分的溝通並經審核同意后,再進行控制點的埋點與開發,同時還應寫入峰值情況應對預案。

監控與運維

一個成功運行的電子商務峰值系統,三分靠研發,七分靠運維。而一個完善的監控系統則是運維的眼睛。通過監控到的指標變化,運維人員可以對系統資源進行人工或自動化調整,可以產生告警通知進行故障處理,也可以及時作出服務降級決策。常見的監控系統分為三類:系統性能監控、用戶體驗監控和業務實時監控。

系統性能監控,主要是對下列指標進行監控:服務器指標,如CPU、內存、磁盤等;數據庫指標,如QPS、主從復制延時、進程、慢查詢等。另外,根據采用的架構不同,還有消息隊列堆積監控等。通過對這一系列系統指標進行監控,可以發現運行健康狀態出現問題的服務與服務器,同時也可以評估系統的繁忙程度,以供及時處理。對於服務器指標監控,一般可以選用NagiosCacti進行,數據庫監控可以使用相關數據庫提供的監控工具或自行結合NagiosCacti進行少量的二次開發。

用戶體驗監控,主要是對業務關鍵流程進行監控,如對頁面訪問、用戶登錄流程、下單流程等流程的可用性進行監控,監控可以由Last mile最終客戶模擬或由各地IDC機房部署的測試腳本發起。用戶體驗監控對於及時發現一些從系統監控層上無法發現的問題或尚未列入監控的指標異常具有重大意義,如系統Bug、之前提到的主動同步延遲等。可以結合當前使用的監控工具進行一定程度的二次開發,市場上也有一些第三方提供的雲服務可供選擇。

業務實時監控,主要是指對業務數據進行監控,如PVUV、轉化率、下單量、支付量、發貨量和倉內作業效率數據,在給業務提供相關決策的同時,也可以用於輔助判斷系統問題。業務實時監控一般分為入侵型與非入侵型兩種。入侵型需要在程序的各個流程節點上進行埋點,相關動作被觸發后,通過消息隊列推送給監控界面進行展示;非入侵型一般通過分析網絡流量,匹配出相應的請求進行內容分析,從而判斷出相關目標事件的發生並進行統計與展示監控界面。入侵型監控系統一般需要進行定制開發,但實現邏輯簡單,技術難度較高;非入侵型監控系統開發難度較高,但部署配置簡單,同時由於無需在目標系統上進行二次開發,對目標系統不會產生任何壓力。

除了以上所討論的常見問題,在設計一個電商峰值系統的過程中,還有很多問題需要解決,如緩存的更新機制、可靠的消息隊列設計、自動化運維體系的建設等。但最關鍵的是要求我們電商系統架構師同時在技術和業務上達到精通的程度,才能設計出一個性能優良、成本合理的電商峰值系統。

作者徐喚春,上海商派軟件有限公司技術副總裁。有20余年的軟件行業經驗,初期從事專家系統、無線尋呼系統、電力行業系統的研究,並承擔多個重大項目的設計與研發工作。

文章來源:http://www.csdn.net/article/2014-11-11/2822574

 

1.4 當當網系統分級與海量信息動態發布實踐

摘要:當當網各種大中小型促銷活動常年不斷,且活動的業務模式不盡相同,因此要求系統具備很強的伸縮性。本文結合當當網多年實戰經驗,講述如何制定的系統伸縮性的設計原則和硬件常備策略,來應對各場景下的流量暴漲。

當當網自成立以來,內部技術體系的發展已經有15年左右的歷史了。系統架構也經歷了從高度集成的軟件向分布式、低耦合、SOA化系統的演進過程,形成全面支持網上零售業各種業態模式的系統架構,每天支撐着千萬級的PV訪問,承載了超過100億元人民幣的年營業額,2013年雙11峰值流量達到日常的10倍。

作為一個典型的自營與開放平台相結合的網上零售電子商務平台,當當網網上購物流程由多達上百個大小系統共同實現。當當網最終服務於消費者,良好的用戶體驗、錢物准確是立足的根本,因此對系統穩定性、可靠性、准確性有非常嚴格的要求。任何時候都能保證線上系統的穩定運行,是我們工作的第一優先級。電商系統的運行峰值通常出現在各類促銷、營銷活動期間,以及大量集中收訂的訂單帶來很大的生產和配送壓力時。

除了參加每年的雙11和雙12大促、每年的10月店慶、業內重要的慶典、兩次開學季圖書大促、換季服裝大促、常規的新品和尾品大促以外,當當網每個月至少會有一次公司級別大促,而各種中小型大促常年不斷。各種促銷活動均可以閃購、秒殺、大量SKU促銷等模式實現。網站流量的來源除了新老用戶的直接登錄以外,還包括多種站外引流方式如網址導航、聯盟、搜索引擎、各種線上線下媒介、短信、郵件、微信等通道。

因流量來源的不同,相應用戶的瀏覽、購物模式也大有不同。如很多促銷落地頁是當當網的,或者專題頁,那么我們可以在活動之前做非常有針對性的准備;有時用戶已提前准備好了購物清單,如雙11這樣的促銷中,訂單轉化率會比平時高,體現在訂單收訂和賣場流量不會成比例上漲——如訂單收訂上漲6倍,賣場流量可能只會漲3~4倍;而一些外部引流方式會帶來大量無效、垃圾流量,所以訂單轉化率會比正常流量低。

有的活動流量會對首頁有較大影響;有的活動會對購物車有較大影響,如閃購類的限時購買或復雜的促銷邏輯;有的活動會對當當網的倉儲、配送系統有較大影響,如當當網配送的訂單;有的活動會對開放平台有較大影響,如商家訂單。

因此,摸清業務模式和活動特點,是設計和運維高峰值電商系統,即高伸縮性系統的重中之重。但從另一個角度來說,在沒有動態彈性部署的前提下,過度的設計和服務器部署是一種浪費,特別是硬件非常有限的壽命會帶來每年巨大的成本攤銷。

當當網根據業務發展速度和業務運營規律,結合多年的經驗,制定的系統伸縮性的設計原則和硬件常備策略使各流程能夠直接應對日常5倍業務量的上漲。通過增加服務器的方式,能夠應對10倍業務量上漲。而如果要應對10倍以上的上漲,則需要提前做有針對性的系統優化。但無論當前承受的業務量是否超過了設計范圍,都不能影響設計范圍內業務量的正常處理。

設計和部署大流量、高並發系統的技術方案選擇比較多,業內有很多成功經驗和案例。但根據我們的經驗,設計高峰值的網上零售業電商應用系統通常要面對以下幾大難點。

1.    應用架構復雜,業務發展快,迭代速度快,各系統之間盤根錯節,歷史包袱重。不僅有牽一發而動全身的風險,更有邊緣case出錯影響主流程處理、耗盡過多資源的隱患。

2.    從前台到后台的業務流程長,用例多。在能承受的最大峰值上,存在短板效應。設計實現時要面面俱到。

3.    通常促銷活動的持續時間短而集中,前期推廣活動已經啟動,在活動期間,短暫的系統不可用,也會帶來慘重的銷售損失與負面影響,沒有亡羊補牢的機會。要確保系統的穩定性,平時的工作就要做足。

針對這幾大難點,有以下幾大應對策略。

1.    基於SOA架構理念,降低系統耦合性,接口定義清晰明確,保證獨立子系統的健壯性高,降低故障跨系統擴散風險,從而將伸縮性的困難逐步分解到各個系統。

2.    對系統進行分級,集中力量,突出重點系統。當當網從賣場到交易流程均屬於一級系統,這部分系統直接關乎用戶體驗和訂單量。在系統穩定性和可靠性等指標上,設計標准高於后台系統。

3.    優先考慮用異步處理代替同步處理,做好系統異常的降級方案,保證有限的合格服務。

在描述電商平台峰值系統的設計之前,通過圖1可簡單了解當當網電商平台的幾大組成系統:賣場系統,促銷、會員系統,商品管理系統,交易系統,訂單管理系統,倉儲與調撥系統,物流與配送系統,客服與退換貨系統等。

 

1  當當網電商平台架構

系統分級

對於電商網站,用戶體驗是第一位的,系統穩定運行是保證用戶良好體驗的基礎。在資源有限的條件下,采取對系統進行級別划分的方式,對高級別系統保持重點關注,在設計、部署、監控等方面確保高級別系統具備良好的伸縮性、健壯性和敏感度,能夠應對電商業務中不確定的極限峰值沖擊。

當當網基於可能對用戶產生影響的程度與敏感度,將所有應用系統分為三級,簡單描述如表1

 

1  應用系統等級划分標准

依此標准,當當網的一級系統主要包括賣場系統、商品詳情、價格系統、庫存系統、促銷系統、購物車、交易系統、支付系統、會員系統等。

二級系統則包括商品信息系統、訂單系統、ERP、倉儲系統、物流與干線運輸系統等。

三級系統主要是結算系統、報表系統,以及運營、活動管理類系統。

其中一級系統基本可分為兩類,第一類為面向用戶訪問的前端頁面,第二類為購買流程所涉及的系統。一級系統的關鍵指標是可用性,在設計和部署時都要高標准嚴要求,要求具備完善的容錯降級機制,日常保持較低的系統運行負載,配置高級別的監控告警流程,出現問題在要求的SLA標准內修復與解決。這兩類系統的核心業務功能定位不同,采用的技術也不同,前端頁面系統主要使用PHP語言,購買流程則主要由Java語言實現。

前端頁面系統是電商業務的流量入口,需解決的核心問題是保證大流量高並發情況下的快速展示可用,這方面業界已有較為成熟的解決方案,如CDN、緩存、靜態化、異步加載、與依賴的數據源解耦、同機部署、數據庫讀寫分離等。通過這樣的設計使前端無狀態頁面應用可以水平擴展,增加Web服務器即可提升系統能力。

為充分發揮系統資源潛力、提高性能,我們引入HHVMPHP代碼進行優化加速,經過性能測試驗證,取得了顯著效果,性能提升超過100%。現在當當網前端頁面系統具備支撐10倍流量沖擊的能力,面對超出極限的流量峰值,我們也有預案,主要采取延長緩存時效、本地靜態化方式,屏蔽峰值流量對后端系統的沖擊,並具備容錯機制,在后端非關鍵服務失效時優雅展示等。賣場系統作為生成各種活動專題頁面的工廠,支持通過配置將頁面組件靜態化,以滿足更高訪問量的要求。

購買流程是電商業務流程中至關重要的環節,一旦出現問題,將使前面的引流、促銷、搜索、推薦等營銷成果付諸東流,因此購物車、交易系統和支付系統必須確保用戶購買結算過程的高效穩定,並保證數據持久化的准確性和一致性。

購物車與交易系統邏輯復雜,依賴服務眾多,其中交易流程的實現依賴超過100個服務。我們梳理出核心業務流程,再根據與核心業務流程的關系,區分出對服務的依賴性強弱。弱依賴服務如積分、禮券、收藏夾等,通過較好的容錯和降級機制,在業務量達到峰值時,可通過服務降級維持核心業務流程的穩定運行。對於強依賴服務中數據變化較少的配置查詢類服務,則通過緩存數據來降低服務依賴關系,犧牲部分數據的及時性換取系統的健壯性。

交易型系統的業務,成功率是關鍵指標,可能因為分布式服務集群中部分實例異常或網絡問題導致調用強依賴的服務失敗,需要發起重試,為兼顧用戶體驗和減少對系統資源的占用,采用設置較短超時時間及重試其他服務節點方式更為合理。經過優化,購買流程的系統可用性指標達到了99.99%

二級系統多數為后台訂單與履約系統。在流量漏斗模型下,在一級系統內形成訂單后,訂單流轉到二級系統,二級系統面對的峰值壓力要小得多。

二級系統多采用異步方式進行系統交互,對於超出處理能力的業務數據,異步機制削峰填谷,使系統得以在可控的壓力下運行。系統資源占用維持在較高水位,既能充分利用系統資源,又可以保證較高的處理效能。當然,異步機制帶來的延遲問題也必須控制在合理范圍之內,在業務量驟增時可以容忍一定程度延遲。如果平時就經常出現延遲,則需要進行優化,或者重新進行容量規划,提高系統整體的吞吐能力。2014年為應對雙11及未來業務發展,當當網對訂單系統數據庫進行了擴容,規模達到之前的5倍,其他部分系統也進一步分庫分表,使之具備承載更高業務峰值的能力。

系統分級是根據不同系統的特點,結合公司業務戰略關注點進行的差異化處理。電商業務鏈貫穿多個系統,每一個環節都不容忽視。一級系統固然是核心優化的重點,二三級別系統的技術指標要求也同樣嚴格。

我們對每個系統的可用性都有嚴格要求,並將監控系統列為一級系統,時刻關注木桶理論中最短的那塊板子,我們的目標是打造一套性能均衡,沒有明顯短板,日常能夠應對5倍業務峰值壓力的電商系統平台。

解耦與SOA實踐

經過多年實踐,當當網逐步完成系統架構的SOA化改造,並通過SOA化,實現了服務解耦與高內聚,簡化了架構復雜度,這是主流零售型電商平台通常選擇的道路。基於分布式的服務使系統具備更強的伸縮性和擴展性,系統瓶頸更易定位和優化,滿足業務快速增長的需要。

SOA即面向服務的架構,在業界並沒有統一的標准,但有一些公認的設計原則:標准合約、松散耦合、服務抽象、可復用性、服務自治、無狀態性、可發現性、可組合性。

在實際應用過程中,根據系統情況以其中部分原則為側重點,不求全責備,簡單實用為上。

2012年起,當當網啟動一系列重點項目,首先對開放平台進行重構,使開放平台成為搭建在PIM、庫存、價格、促銷、訂單、TMS等主業務系統之上一套具備更靈活的擴展性的業務平台。

這次重構是當當網近年的重大架構調整之一,之后各主業務系統陸續實現業務平台化,支持多商家甚至是平台級跨商家的業務模式。開放平台將原有獨立管理的商家商品信息、訂單流程遷移至PIM系統和訂單系統進行統一管理,充分發揮服務的可復用性,減少重復邏輯的多點實現帶來的開發和維護成本。

商品信息是電商業務系統中的核心主數據,是促銷、價格、庫存、禮券、搜索等系統的基礎數據來源。PIM系統作為商品主數據系統,承擔着管理商品基礎數據、關系、品牌、類目和狀態等信息的職能,商品數據量在千萬級別。

PIM系統的SOA建設經過了兩個階段。第一階段主要是實現服務化,因服務設計粒度過細,發布的服務達到數百個,其他系統要完成一個業務功能可能需要調用多個PIM服務,增加了服務使用方的邏輯復雜度,也帶來了更多的網絡交互開銷,不能稱為SOA的最佳實踐。

為此,又進行了第二階段改造,將第一階段實現的服務定義為基礎服務,根據業務需要將其組合,提供粗粒度的對外服務,解決了之前的問題。粗粒度服務能夠提供獨立的業務功能,可能同時依賴於多個系統的基礎服務,當服務使用方因業務需要調用多個粗粒度服務時,可能會對同一個基礎服務發起多次訪問,產生疊加的系統壓力。我們經過分析認為,底層服務資源的消耗能夠簡化上層應用邏輯,對於系統架構層次的合理性更為有益,只要提高底層基礎服務的性能,上層服務能力將更具彈性。

遵循SOA的系統解耦有時會增加系統資源開銷,甚至降低部分服務性能指標,但可使系統架構更為清晰,增加服務復用性,具備更強的業務擴展性,提高開發測試效率,降低開發運維的人力成本,及時響應業務創新,使IT系統重現活力。

通過上述系統架構治理,當當網以很少的臨時性系統准備順利度過2013年雙11大促。

海量動態信息流的快速發布

當當網打造綜合品類電商平台,開放商家入駐,隨之而來的是商品數據量迅速突破千萬。商品信息是電商業務流程前端的重要數據,是進行營銷活動、生成訂單的基礎。商品信息在前台有多種展示頁面,大規模營銷活動期間運營人員需要進行大量操作設置,價格、庫存等也會更為頻繁地更新。目前庫存日更新量峰值超過1500SKU的變化;價格日更新數據量達500萬以上SKU,極限峰值超過1000萬,每秒可能超過1萬。數據同步及時性、一致性指標關乎用戶體驗和營銷活動執行效率,如此大量的數據,在各業務系統之間高效穩定傳輸,對系統架構提出了很大的挑戰。

當當網的商品數據有多個來源,自營實物商品來源於ERP系統,電子書來源於數字業務系統,商家商品來源於開放平台,最終這些商品的數據都由主業務系統中的PIM、庫存系統、價格系統集中統一管理,再發布到搜索系統、推薦系統、前端頁面展示等系統。為了對商品信息中的關鍵數據同步時效進行監控,當當網建立了啄木鳥監控系統,覆蓋了近20個信息流路徑數百個節點,對超出同步時限的環節自動報警,以便及時處理,避免發生嚴重的延遲。

商品的關鍵數據包括商品基本信息、庫存和價格,庫存和價格都依賴於商品基本信息,對於不同類型的數據,根據應用場景區別對待。平台化之后,每個商品都歸屬於一個商家,以商家ID為維度進行散列,將商品基本信息保存在數據庫中,支持水平擴展,可以滿足商品數據不斷增長的需要。對於歷史版本的商品信息,則遷移至歷史版本庫,作為訂單交易快照供用戶查詢。庫存數據在前端展示只關注是否有貨,並不需要將每一次庫存變化同步,在庫存變為0或從0變為正整數時觸發狀態同步,交易下單時實時查詢當前庫存即可,此種變數量為狀態的方式極大地減少了同步數據量,提高了數據一致性。

價格屬於高度敏感的數據,對於手機專享價等類型,業務運營有設置生效時間、失效時間的要求,為保證前端按照時間動態展示,我們將生效時間段數據也發布到前端系統,由使用方判斷當前有效價格。圖2中給出了主要信息流。

 

2  主要信息流示例

即便已經對不同類型的商品信息數據流進行了差異化處理,仍然不能排除短時間內會發生大量數據造成系統同步阻塞,影響正常業務運營操作的及時發布。極端情況下,超出系統處理能力還可能導致系統崩潰。為解決此類問題,我們采用批量、異步、分流、限流等手段進行處理。

批量、批次操作

限制API調用頻次的同時,我們提供批量API供商家對商品信息進行更新,批量更新方式減少了各環節交互次數,提高了系統吞吐量,更好地貼合營銷活動中批量處理的需求。在系統內部,批量方式能夠有效降低系統資源開銷,並能對頻繁更新的商品數據進行合並處理,提高處理速度,使數據更新及時准確。

增加異步處理,減少同步處理

信息流同步經過多個系統,每個系統處理邏輯和吞吐能力不同,采用同步機制可能導致上游系統將下游系統拖垮,因此采用異步機制最為穩妥。異步方式有兩點好處:一方面起到緩沖的作用,下游系統依據自身能力控制處理數據量,避免遭受超負荷的沖擊,保證系統穩定運行;另一方面實現系統隔離解耦,一旦下游系統出現異常,上游系統仍然能正常處理數據,不至於引發連鎖反應。

分流

不同的信息對處理時效的要求也不同,庫存、價格、商品上下架狀態同步及時性要求很高,而商品基本信息,如名稱、副標題、詳情則相對較低。拆分不同的同步路徑,對及時性要求高的數據配置更多的系統資源,既保障了敏感數據的及時性,又避免了數據積壓相互干擾。同理,針對三種不同的數據來源渠道(ERP、數字業務系統、開放平台),也可通過分流方式保證自營實物、電子書和商家商品信息的及時同步。

限流

多數的商品數據來源於商家,商家會通過一些第三方系統與當當網開放平台對接,調用API進行數據同步。一些不合理的同步機制設置會頻繁發起大量的數據同步請求,而多數請求屬於無效數據,這類數據難以識別,會浪費大量的系統資源,干擾有效數據的處理。我們在開放平台對每個商家調用API的頻次進行限制,根據商家商品數量合理分配,有效地抑制了無效數據的泛濫。

隨着多年雙11和集中促銷模式的考驗,電商系統的峰值設計理念和實踐已經慢慢趨於成熟,但仍然是所有電商類公司技術團隊的最重要任務之一。

當當網技術團隊經過多年的沉淀,積累了大量處理電商業務峰值的經驗。通過深入分析應用場景,對系統進行分級,SOA化完成系統解耦,並采用多種技術手段實現海量數據的高效處理發布,不斷提升系統吞吐能力,確保為用戶提供穩定友好的購物服務體驗,充分體現技術力量在產業中的重要作用。

作者李震平,當當網技術部副總裁,負責電子商務平台的研發與團隊管理工作。從2006年起加入電商行業,有多年實際研發與架構設計經驗。

史海峰,當當網架構師,負責電商平台架構設計、技術規范制定和技術預研推廣,參與重點項目的方案設計。

 

1.5 京東峰值系統設計

摘要:高流量、高並發情況下,如何保證整個系統的可靠性和穩定性,是眾多電商企業研發團隊都在思考的問題。為了盡量緩解峰值帶來的壓力,京東峰值系統的設計主要從性能提升、流量控制、災備降級、壓測預案四個角度來進行。

有別於社交網絡、搜索和游戲等網站,電商網站的用戶流量具有操作性強、隨時令變化等特點。在歐美國家,Black FridayCyber Monday標志着節假日消費的高峰。影響電商流量峰值的主要因素是搶購、促銷和惡意攻擊,尤其是京東618店慶和雙11等大規模的促銷活動。高流量、高並發情況下,如何保證整個系統的可靠性和穩定性,是眾多電商企業研發團隊都在思考的問題。

京東電商系統的設計是圍繞系統穩定性、可靠性、高並發和可擴展性為核心開展的。如何在峰值來臨時,保證用戶有平滑流暢的體驗,且系統不會出現異常呢?我們先來看看京東系統的一些特點(圖1)。

 

1  系統架構龐大復雜

京東的業務種類繁多,涉及SKU幾千萬種,這使得系統龐大,外部需要對接供應商、消費者和第三方商家三大板塊。內部系統包括了商品供應鏈中除商品設計和生產外的幾乎所有環節,包括登錄、交易、后台、供應鏈、倉配、客服等。所有這些涉及大小系統幾千個,造就了一個極其復雜龐大的體系。除此之外,京東系統交互強,各個功能模塊之間關聯性強,牽一發而動全身,做任何修改都需要慎之又慎。因此,一切優化方案都以保持系統穩定為前提。

為了在復雜的系統基礎之上,盡量緩解峰值帶來的壓力,京東峰值系統的設計主要從性能提升、流量控制、災備降級、壓測預案四個角度來進行。

性能提升

切分業務系統

我們先將整個業務體系拆分為幾個相對獨立的子系統如SSO、交易平台、POP平台、訂單下傳系統、WMS和倉儲配送(圖2)。每個子系統又可細分為若干部分,逐級簡化,直至可操作可優化的層級。例如,交易平台包括價格、購物車、結算、支付和訂單中心等;網站系統包括首頁、登錄、列表頻道、單品和搜索等。接下來,針對每個功能模塊的關鍵部分進行切分,有針對性地做性能優化。

 

2  業務切分方案

例如,交易的秒殺系統,原來是根植於普通交易系統之內的,缺點非常明顯。當流量突然增大時,不僅會導致秒殺系統反應遲鈍,而且會影響普通交易系統的正常運作。於是我們將其與其他業務系統物理分開,成為相對獨立的子系統。並且針對秒殺的特性,減少對后台存儲的依賴。同時優化中間層存儲機制,使得相對熱點分散部署。甚至支持單一SKU多點部署,從而大大提升了秒殺系統的吞吐量和可靠性。

分布式

分布式的交易系統是電商的未來。分布式系統解決兩大難題:提高用戶體驗和增強容錯能力。由於分布式系統設計時就會留有相當的流量增長空間,所以當一處數據中心飽和時,可以將其余的流量切入其他相對寬松的數據中心去,從而達到互為備份、互相支持的目的。與此同時,由於為提供用戶就近服務,所以減少了網絡延時,頁面反應速度加快了。舉一個例子,Google搜索是全球服務,歐亞美各地都有不同的IP提供服務。當其中的某一個IP出現故障時,Google能夠從容地將其服務切換至最近的IP,繼續搜索服務。對於電商來說,情況更復雜一些,需要同步的數據要求更精確,數據量較大,對延時的容忍度更低,建設周期也就更長。京東正在此方面着力改進,從只讀的系統入手,一步一步實現系統的分布式。

API服務化

在各個系統中,總是有很多相同的組件。前端的負載均衡自不必說,中間件的處理就是非常典型的例子。如何高效統一地管理這些組件,API服務化是我們的答案。最好由一個訓練有素的團隊集中管理這些組件並對外提供接口服務,將軟件的使用復雜性隱藏起來,調用的是簡單利索的API。讓專業人員去處理復雜邏輯,確保系統的可用性和擴展性,既能大大降低出錯概率,又能實現規模效益。

Redis是我們常用的緩存組件。過去都是由各個業務實現團隊進行分別維護,專業性不強,使用多有不當之處。后來我們進行了集中管理,統一定制開發新功能和升級,並通過API服務化提供給各級用戶。這樣不僅豐富了應用場景,還提升了性能和可靠性。

架構,代碼優化

一個合理的電商系統架構是與一家公司的研發水平和技術管理水平密不可分的,這直接決定了可支撐峰值流量的多少和未來能達到的高度。選取適合自身發展的框架,既能充分發揮其效能,又可節約資源。代碼優化也能提高效能,例如對於SQL語句的優化,能更好地利用索引;Java/C++邏輯的優化,減少了不必要的循環和復雜的操作;算法優化,使之更高效;功能實現邏輯的優化,變得更簡潔和清晰;等等。但代碼優化終究不能沖破極限,難以追求極致,適可為止為宜。

系統虛擬彈性化

當磁盤I/O不是瓶頸時,解決系統水平擴展就會變得容易許多。可以通過ZooKeeper或類ZooKeeper將軟件棧有機地串聯起來,並配以有效的性能監管。當事務處理成為瓶頸時,利用當今流行的虛擬化技術(如LXCVM)可以在沒有人為干預的狀況下自動進行彈性擴展。

 

1.6 “米粉節”背后的故事——小米網搶購系統開發實踐

摘要:今年4月的米粉節對小米網來說意義非凡,是其徹底重構后迎來的一次全面壓力測試,涉及網站前端、后台系統、倉儲物流、售后等各環節。高並發的負載能力、穩定性、准確性等已不是問題,靈活性與可運營性成為關鍵。

2014年的米粉節

201449日凌晨,我和同事們對小米網的搶購系統做了最后的檢查與演練。幾個小時后,小米網今年開年來最重要的一次大型活動米粉節就要開始了。

這次米粉節活動,是小米電商的成人禮,是一次重要的考試。小米網從網站前端、后台系統、倉儲物流、售后等各個環節,都將接受一次全面的壓力測試。

10點整,一波流量高峰即將到來,幾百萬用戶將准點擠入小米網的服務器。而首先迎接壓力沖擊的,就是擋在最前面的搶購系統。

而這個搶購系統是重新開發、剛剛上線不久的,這是它第一次接受這樣嚴峻的考驗。

系統能不能頂住壓力?能不能順暢正確地執行業務邏輯?這些問題不到搶購高峰那一刻,誰都不能百分百確定。

950分,流量已經爬升得很高了;10點整,搶購系統自動開啟,購物車中已經順利加入了搶購商品。

一兩分鍾后,熱門的搶購商品已經售罄自動停止搶購。搶購系統抗住了壓力。

我長舒一口氣,之前積累的壓力都消散了。我坐到角落的沙發里,默默回想搶購系統所經歷的那些驚心動魄的故事。這可真是一場很少人有機會經歷的探險呢。

搶購系統是怎樣誕生的

時間回到2011年底。小米公司在這一年816日首次發布了手機,立刻引起了市場轟動。隨后,在一天多的時間內預約了30萬台。之后的幾個月,這30萬台小米手機通過排號的方式依次發貨,到當年年底全部發完。

然后便是開放購買。最初的開放購買直接在小米的商城系統上進行,但我們那時候完全低估了搶購的威力。瞬間爆發的平常幾十倍流量迅速淹沒了小米網商城服務器,數據庫死鎖、網頁刷新超時,用戶購買體驗非常差。

市場需求不等人,一周后又要進行下一輪開放搶購。一場風暴就等在前方,而我們只有一周的時間了,整個開發部都承擔着巨大的壓力。

小米網可以采用的常規優化手段並不太多,增加帶寬、服務器、尋找代碼中的瓶頸點優化代碼。但是,小米公司只是一家剛剛成立一年多的小公司,沒有那么多的服務器和帶寬。而且,如果代碼中有瓶頸點,即使能增加一兩倍的服務器和帶寬,也一樣會被瞬間爆發的幾十倍負載所沖垮。而要優化商城的代碼,時間上已沒有可能。電商網站很復雜,說不定某個不起眼的次要功能,在高負載情況下就會成為瓶頸點拖垮整個網站。

這時開發組面臨一個選擇,是繼續在現有商城上優化,還是單獨搞一套搶購系統?我們決定冒險一試,我和幾個同事一起突擊開發一套獨立的搶購系統,希望能夠絕境逢生。

擺在我們面前的是一道似乎無解的難題,它要達到的目標如下:

·         只有一周時間,一周內完成設計、開發、測試、上線;

·         失敗的代價無法承受,系統必須順暢運行;

·         搶購結果必須可靠;

·         面對海量用戶的並發搶購,商品不能賣超;

·          一個用戶只能搶一台手機;

·         用戶體驗盡量好些。

設計方案就是多個限制條件下求得的解。時間、可靠性、成本,這是我們面臨的限制條件。要在那么短的時間內解決難題,必須選擇最簡單可靠的技術,必須是經過足夠驗證的技術,解決方案必須是最簡單的。

在高並發情況下,影響系統性能的一個關鍵因素是:數據的一致性要求。在前面所列的目標中,有兩項是關於數據一致性的:商品剩余數量、用戶是否已經搶購成功。如果要保證嚴格的數據一致性,那么在集群中需要一個中心服務器來存儲和操作這個值。這會造成性能的單點瓶頸。

在分布式系統設計中,有一個CAP原理。一致性、可用性、分區容忍性三個要素最多只能同時實現兩點,不可能三者兼顧。我們要面對極端的爆發流量負載,分區容忍性和可用性會非常重要,因此決定犧牲數據的強一致性要求。

做出這個重要的決定后,剩下的設計決定就自然而然地產生了:

1.    技術上要選擇最可靠的,因為團隊用PHP的居多,所以系統使用PHP開發;

2.    搶資格過程要最簡化,用戶只需點一個搶購按鈕,返回結果表示搶購成功或者已經售罄;

3.    對搶購請求的處理盡量簡化,將I/O操作控制到最少,減少每個請求的時間;

4.    盡量去除性能單點,將壓力分散,整體性能可以線性擴展;

5.    放棄數據強一致性要求,通過異步的方式處理數據。

最后的系統原理見后面的第一版搶購系統原理圖(圖1)。

 

1  第一版搶購系統原理圖

系統基本原理:在PHP服務器上,通過一個文件來表示商品是否售罄。如果文件存在即表示已經售罄。PHP程序接收用戶搶購請求后,查看用戶是否預約以及是否搶購過,然后檢查售罄標志文件是否存在。對預約用戶,如果未售罄並且用戶未搶購成功過,即返回搶購成功的結果,並記錄一條日志。日志通過異步的方式傳輸到中心控制節點,完成記數等操作。

最后,搶購成功用戶的列表異步導入商場系統,搶購成功的用戶在接下來的幾個小時內下單即可。這樣,流量高峰完全被搶購系統擋住,商城系統不需要面對高流量。

在這個分布式系統的設計中,對持久化數據的處理是影響性能的重要因素。我們沒有選擇傳統關系型數據庫,而是選用了Redis服務器。選用Redis基於下面幾個理由。

1.    首先需要保存的數據是典型的Key/Value對形式,每個UID對應一個字符串數據。傳統數據庫的復雜功能用不上,用KV庫正合適。

2.    Redis的數據是in-memory的,可以極大提高查詢效率。

3.    Redis具有足夠用的主從復制機制,以及靈活設定的持久化操作配置。這兩點正好是我們需要的。

在整個系統中,最頻繁的I/O操作,就是PHPRedis的讀寫操作。如果處理不好,Redis服務器將成為系統的性能瓶頸。

系統中對Redis的操作包含三種類型的操作:查詢是否有預約、是否搶購成功、寫入搶購成功狀態。為了提升整體的處理能力,可采用讀寫分離方式。

所有的讀操作通過從庫完成,所有的寫操作只通過控制端一個進程寫入主庫。

PHPRedis服務器的讀操作中,需要注意的是連接數的影響。如果PHP是通過短連接訪問Redis服務器的,則在高峰時有可能堵塞Redis服務器,造成雪崩效應。這一問題可以通過增加Redis從庫的數量來解決。

而對於Redis的寫操作,在我們的系統中並沒有壓力。因為系統是通過異步方式,收集PHP產生的日志,由一個管理端的進程來順序寫入Redis主庫。

另一個需要注意的點是Redis的持久化配置。用戶的預約信息全部存儲在Redis的進程內存中,它向磁盤保存一次,就會造成一次等待。嚴重的話會導致搶購高峰時系統前端無法響應。因此要盡量避免持久化操作。我們的做法是,所有用於讀取的從庫完全關閉持久化,一個用於備份的從庫打開持久化配置。同時使用日志作為應急恢復的保險措施。

整個系統使用了大約30台服務器,其中包括20PHP服務器,以及10Redis服務器。在接下來的搶購中,它順利地抗住了壓力。回想起當時的場景,真是非常的驚心動魄。

第二版搶購系統

經過了兩年多的發展,小米網已經越來越成熟。公司准備在20144月舉辦一次盛大的米粉節活動。這次持續一整天的購物狂歡節是小米網電商的一次成人禮。商城前端、庫存、物流、售后等環節都將經歷一次考驗。

對於搶購系統來說,最大的不同就是一天要經歷多輪搶購沖擊,而且有多種不同商品參與搶購。我們之前的搶購系統,是按照一周一次搶購來設計及優化的,根本無法支撐米粉節復雜的活動。而且經過一年多的修修補補,第一版搶購系統積累了很多的問題,正好趁此機會對它進行徹底重構。

第二版系統主要關注系統的靈活性與可運營性(圖2)。對於高並發的負載能力,穩定性、准確性這些要求,已經是基礎性的最低要求了。我希望將這個系統做得可靈活配置,支持各種商品各種條件組合,並且為將來的擴展打下良好的基礎。

 

2  第二版系統總體結構圖

在這一版中,搶購系統與商城系統依然隔離,兩個系統之間通過約定的數據結構交互,信息傳遞精簡。通過搶購系統確定一個用戶搶得購買資格后,用戶自動在商城系統中將商品加入購物車。

在之前第一版搶購系統中,我們后來使用Go語言開發了部分模塊,積累了一定的經驗。因此第二版系統的核心部分,我們決定使用Go語言進行開發。

我們可以讓Go程序常駐內存運行,各種配置以及狀態信息都可以保存在內存中,減少I/O操作開銷。對於商品數量信息,可以在進程內進行操作。不同商品可以分別保存到不同的服務器的Go進程中,以此來分散壓力,提升處理速度。

系統服務端主要分為兩層架構,即HTTP服務層和業務處理層。HTTP服務層用於維持用戶的訪問請求,業務處理層則用於進行具體的邏輯判斷。兩層之間的數據交互通過消息隊列來實現。

HTTP服務層主要功能如下:

1.    進行基本的URL正確性校驗;

2.    對惡意訪問的用戶進行過濾,攔截黃牛;

3.    提供用戶驗證碼;

4.    將正常訪問用戶數據放入相應商品隊列中;

5.    等待業務處理層返回的處理結果。

業務處理層主要功能如下:

1.    接收商品隊列中的數據;

2.    對用戶請求進行處理;

3.    將請求結果放入相應的返回隊列中。

用戶的搶購請求通過消息隊列,依次進入業務處理層的Go進程里,然后順序地處理請求,將搶購結果返回給前面的HTTP服務層。

商品剩余數量等信息,根據商品編號分別保存在業務層特定的服務器進程中。我們選擇保證商品數據的一致性,放棄了數據的分區容忍性。

這兩個模塊用於搶購過程中的請求處理,系統中還有相應的策略控制模塊,以及防刷和系統管理模塊等(圖3)。

 

3  第二版系統詳細結構圖

在第二版搶購系統的開發過程中,我們遇到了HTTPGo程序內存消耗過多的問題。

由於HTTP層主要用於維持住用戶的訪問請求,每個請求中的數據都會占用一定的內存空間,當大量的用戶進行訪問時就會導致內存使用量不斷上漲。當內存占用量達到一定程度(50%)時,Go中的GC機制會越來越慢,但仍然會有大量的用戶進行訪問,導致出現雪崩效應,內存不斷上漲,最終機器內存的使用率會達到90%以上甚至99%,導致服務不可用。

Go語言原生的HTTP包中會為每個請求分配8KB的內存,用於讀緩存和寫緩存。而在我們的服務場景中只有GET請求,服務需要的信息都包含在HTTP Header中,並沒有Body,實際上不需要如此大的內存進行存儲。

為了避免讀寫緩存的頻繁申請和銷毀,HTTP包建立了一個緩存池,但其長度只有4,因此在大量連接創建時,會大量申請內存,創建新對象。而當大量連接釋放時,又會導致很多對象內存無法回收到緩存池,增加了GC的壓力。

HTTP協議是構建在TCP協議之上的,Go的原生HTTP模塊中是沒有提供直接的接口關閉底層TCP連接的,而HTTP 1.1中對連接狀態默認使用keep-alive方式。這樣,在客戶端多次請求服務端時,可以復用一個TCP連接,避免頻繁建立和斷開連接,導致服務端一直等待讀取下一個請求而不釋放連接。但同樣在我們的服務場景中不存在TCP連接復用的需求。當一個用戶完成一個請求后,希望能夠盡快關閉連接。keep-alive方式導致已完成處理的用戶連接不能盡快關閉,連接無法釋放,導致連接數不斷增加,對服務端的內存和帶寬都有影響。

通過上面的分析,我們的解決辦法如下。

1.    在無法優化Go語言中GC機制時,要避免雪崩效應就要盡量避免服務占用的內存超過限制(50%),在處於這個限制內時,GC可以有效進行。可通過增加服務器的方式來分散內存壓力,並盡力優化服務占用的內存大小。同時Go 1.3也對其GC做了一定優化。

2.    我們為搶購這個特定服務場景定制了新的HTTP包,將TCP連接讀緩存大小改為1KB

3.    在定制的HTTP包中,將緩存池的大小改為100萬,避免讀寫緩存的頻繁申請和銷毀。

4.    當每個請求處理完成后,通過設置ResponseHeaderConnectionclose來主動關閉連接。

通過這樣的改進,我們的HTTP前端服務器最大穩定連接數可以超過一百萬。

第二版搶購系統順利完成了米粉節的考驗。

總結

技術方案需要依托具體的問題而存在。脫離了應用場景,無論多么酷炫的技術都失去了價值。搶購系統面臨的現實問題復雜多變,我們也依然在不斷地摸索改進

 

1.7 海爾電商峰值系統架構設計最佳實踐

摘要:本文重點介紹了海爾電商平台的架構方案,也用不少篇幅闡述面臨的場景和挑戰,以及在架構方案決策過程中的關注點。其實作為一個優秀的電商平台,提供極致的用戶體驗、讓技術最大化地創造價值,才是架構的終極目標。

多數電商平台都會經歷相似的過程,流量和業績每年以幾倍至十幾倍的速度增長,每年都要接受幾次大規模、全方位的系統檢閱,例如雙11、周年慶等購物狂歡節,期間流量和訂單可能是日常的十幾倍甚至幾十倍,產生的峰值對平台形成極其強烈的沖擊,對電商平台的架構帶來巨大的考驗。因此,對電商平台的規划和架構工作不僅要高瞻遠矚,而且要細致入微,否則將導致平台無法滿足高速增長的業務發展,細微處的失誤也可能造成嚴重后果,不僅影響業務指標的實現,還可能導致對系統進行重新架構,勞時費力又傷錢。

2012年開始,海爾進入了網絡化發展階段,企業平台化、用戶個性化和員工創客化的三化做法為電商的蓬勃發展提供了很好的土壤,也是海爾在面對互聯網轉型時的一個重點。海爾電商平台在發展過程中也同樣經歷了上述的問題。下面就拋磚引玉,為大家分享海爾電商平台應對電商峰值的架構設計經驗。

站在巨人肩膀上的SOA架構

隨着電商業務開展和業績增長,系統結構和邏輯變得越來越復雜。為應對業務規模和復雜性的增長,需要將系統按照細分專業領域拆分;為應對流量和交易的增長,需要將網站進行大量子站拆分。這種狀況下,SOA在保持清晰的系統結構和良好的邏輯組織方面提供了有力保障,為業務優化調整及新業務的開展帶來巨大收益。

通過服務封裝和嚴格分離,為電商平台實現高伸縮性打下堅實基礎。實現高伸縮性的主要工作集中在服務內部,對客戶端影響的評估和改造工作也變得非常清晰。這將大大降低了實現高伸縮性的難度、工作量和實施周期。

Dubbo是阿里提供的一個優秀的開源服務框架,在高並發情況下具有優秀的性能表現,海爾電商的SOA架構全面基於Dubbo服務框架。關於Dubbo框架的詳細介紹可以參考GitHub上的Dubbo項目文檔。下面對Dubbo框架工作機制進行簡單介紹。

如圖1所示,每個服務提供者啟動時都會注冊到注冊中心,並且通過長連接與注冊中心保持心跳檢測。這樣注冊中心就擁有一份完整、可用的服務提供者清單,某個服務提供者下線或由於故障中斷,注冊中心都能感知到並從清單中刪除這個提供者。消費者啟動時從注冊中心獲得服務提供者清單,並與提供者建立長連接,后續直接調用服務提供者,不再經過注冊中心,避免注冊中心成為瓶頸。每個消費者同樣與注冊中心保持長連接,這樣有新的提供者注冊或者某個提供者下線,都由注冊中心通知到每個消費者。消費者在調用服務提供者時支持各種負載均衡和故障容錯策略。監控中心則負責運行狀態統計,例如每分鍾的調用次數和平均耗時等。

 

1  Dubbo服務部署架構示意圖

Dubbo框架不僅實現了高性能、高可用性,而且使用方便,擴展性非常好。海爾電商所有服務都基於Dubbo框架開發,圖2是系統整體SOA架構情況。

 

2  海爾電商SOA架構示意圖

魚與熊掌兼得的產品服務架構

面臨的挑戰

產品的檢索和展示在電商平台中具有舉足輕重的地位,貫穿用戶瀏覽、購物整個過程,以及訂單交付全流程。產品服務需要為整個平台提供數據請求和檢索服務,而各品類的產品差異性非常大,這給產品服務設計帶來了巨大的挑戰。

·         負載權重高。電商平台中幾乎每一個前台頁面都與產品展示和檢索相關,產品服務的負載在整個平台中占比非常高,對產品服務的請求量可能達到整站流量的幾倍、幾十倍。在電商活動高峰期間,核心系統中首當其沖的便是產品服務。因此,產品服務的設計必須滿足高可用性,並且實現良好的性能和高伸縮性。

·         產品差異性大。不同品類的產品具有不同維度的屬性和規格參數,產品結構的設計必須具備足夠的通用性和靈活性,才能良好地滿足電商平台多品類運營的要求,以及在平台、品類擴展時可以提供快速的響應支持。

·         全方位檢索、排序。讓用戶方便快捷地在大量產品中找到自己滿意的產品,是電商平台用戶體驗和信息架構中非常關鍵的一點。除了關鍵詞搜索、按類目檢索瀏覽之外,還需要提供按常用屬性進行檢索。在深入優化用戶體驗時,可能會提出更復雜的檢索處理邏輯,例如組合屬性檢索,自動根據檢索結果反過濾掉無結果的類目和屬性,展示符合各個屬性條件的商品個數,以及實時地結合大數據分析結果添加更多自動化、智能化的策略等。

將頁面或者部分頁面的靜態化是一種非常有效的優化方式,可以極大地降低對后台服務和數據的請求。但靜態化帶來的最大弊端就是服務端喪失了控制力,使得一些深入的自動化、智能化策略難以應用。因此,我們希望通過提升服務端的性能和伸縮性,來避免靜態化的方案。

性能和伸縮性是電商平台的關鍵指標。為了保障系統性能和伸縮性,不少時候我們需要犧牲或者完全拒絕某些功能,或者降低系統的靈活性和擴展性等。在產品服務架構設計階段,我們努力思考和研究着一種可以魚和熊掌兼得的解決方案。

解決方案

如圖3所示,在數據庫層允許復雜的產品存儲結構設計,以細粒度、深度優化的關系模型充分實現產品數據模型的通用性、可擴展性。在數據模型設計時完全不用關心客戶端檢索查找的復雜性和性能問題。

 

3  產品服務邏輯架構示意圖

產品查詢引擎將復雜的數據存儲模型封裝成一個簡單的邏輯模型。這個邏輯模型實現的效果,完全等同於產品的所有屬性都存儲在同一張數據庫表中,邏輯模型的每個屬性對應數據庫表中的一個字段。在這個邏輯模型的基礎上實現了一個簡潔的DSL,供客戶端進行檢索查詢。客戶端工作在邏輯模型和DSL之上,檢索查詢簡單、靈活,同樣完全不用關心產品數據存儲模型的復雜性和性能問題。

產品查詢語言DSL

產品查詢語言DSL的語法類似SQL中的where條件語法,任何一個開發人員都很容易掌握。客戶端將DSL表達式傳給服務端,即可得到滿足條件的產品列表及相關屬性數據(圖4)。

 

4  查詢語言DSL工作原理

DSL還支持中文語法,更方便使用,尤其對於業務人員進行復雜的后台檢索查詢,或者為前台頁面及欄位設置產品展示的過濾條件等情況。

 

產品查詢引擎

5描述了查詢引擎的核心組件及關鍵的執行流、數據流。編譯器基於Antlr開發,職責是將DSL表達式編譯為語法樹,並完成一系列編譯優化操作。執行引擎使用語法樹逐個對產品進行匹配,得到符合條件的產品列表。智能排序引擎基於產品綜合競爭力評估模型,為結果集進行排序,實現最大化提升轉換率的目的。結果構造器則根據客戶端在調用服務時指定的要求,將客戶端所需屬性加載到結果集中。

 

5  查詢引擎工作機制

在服務啟動時將產品數據緩存到內存中,通過訂閱MQ消息隊列,在數據發生變化時刷新有變化的數據。

產品服務架構

產品服務分不同集群進行部署,面向Web應用和其他服務的集群在運行期間幾乎不會產生數據庫請求,因此不管網站訪問量和交易量多高,數據庫都不會產生壓力瓶頸。在系統峰值期間,只需為Web和服務添加服務器即可,實現了高伸縮目標。

效果

·         性能:最高峰值2.6億次/天,平均耗時60毫秒/次,后續對編譯器和執行引擎進行優化,性能還有更大的提升空間。

·         伸縮性:在一定條件下接近線性伸縮,所有使用產品服務的地方無須出於性能和系統壓力原因額外設計其他方案,直接調用產品服務即可。

·         通用性:不會因為電商平台性能和伸縮性要求而受到任何限制,可以像開發內部管理系統PDM一樣設計產品數據模型,並且直接用於其他在線服務和前台Web應用,盡可能達到通用靈活的目的。

·         擴展性:通過邏輯模型屏蔽了底層的數據模型,將數據模型的優化、擴展工作量以及影響范圍降低到最小限度,提升了電商平台中產品服務的可維護性和擴展性。

以查詢引擎為核心的產品服務是一個魚與熊掌兼得的架構設計案例,通用性、擴展性、伸縮性等在電商平台中相互制約、矛盾的一組核心架構目標全部得到滿足。

 

1.8 唯品會峰值系統架構演變

摘要:在唯品會,用戶來得越早,越能買到又便宜又好的東西,所以在大促一開始會涌入大量用戶,形成系統流量峰值。本文總結了唯品會419時日志平台遇到的問題和解決方案,同時根據實踐經驗,整理了在面對峰值前要做的准備。

唯品會每年最大力度的促銷活動在419日,就是419For One Night),意在告訴唯品會用戶只有這一晚有這么大的折扣力度(本文中用大促就指代419。唯品會是一個閃購網站,用戶來得越早,越能買到又便宜又好的東西,所以在大促的一開始,會涌入大量用戶,形成系統流量峰值。

本文總結了唯品會419時日志平台遇到的問題和解決方案,同時根據實踐經驗,整理了在面對峰值前要做的准備。

2013419

唯品會的日志平台,包括消息中間件、計算和數據可視化。前兩者和峰值系統相關度更大一些。在2013419時,我們使用Flume來收集日志,RabbitMQ作為傳輸日志的消息中間件,用StormRedis進行計算,然后通過腳本將Redis的數據寫入MySQL,前端從MySQL中獲取數據做數據可視化。架構如圖1所示。

 

1  2013年日志平台架構

在這次419之前,我們對這個系統並不是很有信心。一個原因是剛開始做這塊內容,很多工具都不夠成熟。另一個原因是在大促之前,我們還在開發新功能,既沒有穩定運行一段時間,也沒有做容量規划之類的事情。

最后的結果確實如此,4190點,大量用戶進入唯品會購物,系統計算開始出現延遲,最初是1分鍾,后面逐漸擴大到10分鍾,最后由於雪崩效應,整個集群垮了。在分布式系統中,雪崩效應指的是系統中一個小問題會逐漸擴大,最后造成整個集群宕機。前面這個例子,一開始的計算延遲是1分鍾,這在可以接受的范圍內,但因為這個延遲,系統需要付出更多的代價去計算,如此惡性循環,數據延遲會越來越大,最后導致整個集群宕機。

在大促之后,我們進行了全面分析,發現這個系統的瓶頸在於RabbitMQStorm

作為整個平台輸送數據的管道,RabbitMQ的性能直接決定了后端消費數據系統的消費能力。整個平台就像是大炮,大炮發射再快,輸送炮彈的速度跟不上都沒用。這次大促中,RabbitMQ的性能出了問題。我們需要處理的日志量是每秒15萬條左右,而我們使用RabbitMQ的環境下,每一台RabbitMQ服務器大約能達1.2萬條日志每秒,由4台機器組成RabbitMQ集群,所以當流量暴漲時,RabbitMQ服務器負載會變得很高,而produce/consume速度變慢。在當時的情況下,我們並不能判斷這個Queue的堵塞是由於下游的Storm消費得慢,還是RabbitMQ本身慢造成。

再看Storm。在分析Storm出問題的原因之前,先先介紹一下使用Storm計算的內容:一是根據用戶訪問日志計算PV/UV;二是根據Nginx日志計算各個域的訪問量、響應時間和4xx/5xx數。由於Storm在各個計算節點之間無法共享數據(不像Sparkbroadcast),我們只能借助Redis來做一個類似MapReduce中的Reduce功能。為了讓大家能深入了解,下面詳細介紹一下如何使用Storm計算這些數據。

PV

Redis中有不同的key,如b2c_pvmobile_pv,對Storm中得到的每條日志進行邏輯判斷決定是b2c還是mobile訪問,再使用Redisincr操作(incr[key],表示將key對應的value1,如果key不存在,則在這個操作前,會先置為0)。

UV

我們計算的是每5分鍾的UV,方法很簡單。在Redis中有一個DB專門用來計算UVStorm將每個用戶的cid(標識用戶唯一身份的idincrDB中,這樣能保證一個cid對應一個key。最后匯總通過Redis“keys *”來獲取DBkey的數目,這樣就獲取到了cid的數目。又因為我們計算的是5分鍾的UV,所以還需要一個crontab,每5分鍾將DB中的內容truncate掉。

計算Nginx日志

實際上,計算Nginx日志非常簡單,就是分割和計算。將一條Nginx日志分割后,就能知道這次訪問的狀態碼是什么,響應時間是多少。然后DB中會有不同的key,如domaincart,那么cart域的響應時間在Redis DB里的key就是cart_resp_time,訪問量就是cart_count2xx數量就是cart_2xx_count。根據從日志獲取的值,我們會使用Redisincrby來操作(incrbyincr類似,incrvalue1incrby可以指定增加的數字)。然后在計算metrics時,腳本先獲取當前的cart_count,然后sleep 1秒,再獲取一次cart_count,這兩個的差值是這1秒鍾內cart域的訪問量。同樣的方法,可以獲取這1秒的響應時間,與訪問量相除,就可以計算出這1秒的平均響應時間。

介紹完計算邏輯,可以了解到,Storm的處理邏輯非常簡單,主要工作就是分割日志操作Redis計數

為了判斷到底是RabbitMQ慢還是Storm慢,我們先將Storm停了,然后用一個Python腳本向Queue發送數據和消費Queue里的數據,這樣來減小ProducerConsumer性能對RabbitMQ的性能影響。這樣測試后發現,每台RabbitMQ的吞吐大概是1w條數據每秒,而且負載很高。后來,我們使用ErlangHiPE特性(即High Performance Erlang),將性能提升20%,大概達到1.2w條數據每秒。但仍然不能滿足我們的要求。我們要求達到15w msg/s,加上25%的冗余,此時需要15×(1+25%)/1.2≈16台服務器,比較多。再考慮到唯品會正處於快速增長期,目前是15w msg/s,很有可能明年就翻幾番。使用RabbitMQ似乎不太符合我們的需求,因為在可預見的將來,需要大量服務器來支撐。此外,RabbitMQ對服務器的CPU消耗非常大。

RabbitMQ的消費者除了Storm外,還有Elastic-SearchES)。使用ES來做日志的全文檢索,包括Nginx日志和PHP錯誤日志,因為Nginx日志的計算只能幫助運維人員和開發人員定位到某個域出問題,再深入地分析,就要從出錯時的日志入手了。我們的日志還會有一份全量流入HDFS,原本用日志的搜索直接從HDFS來獲取,但發現用Hive查詢速度非常慢,大約需要幾分鍾。ES是基於Solr的一個全文檢索引擎,有一個很好用的前端Kibana。在這次大促中,由於前端的RabbitMQ掛了,所以ES沒有受到很大的壓力。

1.9 1號店電商峰值與流式計算

摘要:1號店結合自己的業務需求,在力求降低成本的前提下,最終采納Storm計算框架來實現自己的分布式流計算平台。本文中詳細闡釋了這一過程中的最佳技術實踐。

京東618 1號店711,還有全民購物狂歡節雙11,電商促銷的浪潮此起彼伏。然而,在買家和賣家歡呼雀躍的同時,電商平台正在經歷着非常嚴峻的考驗。面對一天之內猶如洪水般的網購流量,哪怕出現幾分鍾的閃失,都可能造成眾多筆訂單的損失,以及無法挽回的銷售收入。時間就是金錢,在這一刻體現得淋漓盡致。如何設計電商峰值系統來更好地滿足客戶需求,如何在海量數據處理中實時發現有效信息並轉化為商機,成為眾多電商企業都在認真思考的問題。

電商峰值系統要滿足三面的要求:低時延,系統對數據的處理速度要快;高可用性,故障可及時恢復,對業務影響降到最小;易擴展性,可動態添加新的計算節點,不影響在線業務,甚至可以自動做出優化調整。

從這三個角度出發,Hadoop框架更適合於大數據批量處理。畢竟,它是先存儲再訪問,屬於一次寫入多次讀取的業務類型。然而電商行業的很多業務,強調訪問處理的實時性,包括電商搜索引擎、基於用戶購買行為的實時商品推薦和針對網站流量的監控及反作弊等功能。這些業務要求處理行為達到秒級甚至毫秒級的時延,從而促進了以Storm為代表的流式計算系統的推廣和應用。

1號店流式計算解決方案

1號店結合自己的業務需求,在力求降低成本的前提下,最終采納Storm計算框架來實現自己的分布式流計算平台。1號店實時數據處理的整體流程如圖1所示。

 

1  1號店分布式流計算系統

Tracker1號店獨自開發的數據記錄方案,它結合Flume構成網站的數據采集模塊,能在保證日志記錄效率和穩定性的同時,更好地支持橫向擴展,以應對日益龐大的數據量。我們采用Kafka作為前端消息數據緩沖,盡可能降低數據丟失率,同時能夠靈活滿足不同業務對消息處理並行性和有序性的偏好要求。Storm應用的計算結果,按照各自業務需求選擇持久化存儲或丟棄。

為了更進一步保證流式計算系統的穩定性,光有容錯處理是不夠的,我們還必須想方設法減少計算平台被過重負載壓垮的風險。Linux容器技術為我們的需求提供了極大便利。它以CGroup內核功能為基礎,可以支持對CPU、內存、塊設備讀寫和網絡流量等資源的隔離限制,而且此類限制可以細化到進程級別(CGroup是以進程組為基本工作單位的)。通過采用Linux容器技術,可以避免某些業務進程侵占過多系統資源,從而導致節點系統響應緩慢甚至完全癱瘓。

很遺憾,Storm自身還沒有支持CGroup資源隔離功能。目前的Storm on Yarn還是個概念性實現,因為YARNStorm的資源隔離,僅針對整個Storm集群所占用的資源,以實現和Hadoop批量計算框架在同一集群上的共存。而我們的客觀需求是希望能對Storm平台上Topology一級進行資源限制,對應到每個計算節點上,就是一種進程級別的資源隔離需求。最終的解決辦法是,我們獨立設計自己的CGroup資源管理框架,來實現對Storm Topology的資源隔離限制。在圖2所示的設計方案中,我們主要考慮以下幾點。

 

2  1號店Storm集群上的資源管理框架

更簡單的用戶體驗

1. 用戶不需掌握CGroup的復雜細節(層級、子系統、組概念及相關操作系統和文件系統知識)。

2. 僅需掌握三種操作:

·         創建/刪除某一類型的CGroup,目前支持cpumemorycpuset三種類型;

·         分配進程到指定的CGroup

3. 如上操作可以通過重新設計實現的客戶端指令(ycgClient)完成。

4. 用戶僅需在Storm UI上對Storm Topology指定優先級(該處優先級定義為進程所在的進程組可獲取資源的大小)。

5. 由守護進程(ycgManager)自動管理各計算節點的進程級優先級。

自動化方案降低手動管理成本

·         Storm Topology的優先級信息存儲在ZooKeeper集群中。

·         資源管理框架可以自適應異構機器結點的動態添加。

·         便於集群管理(機器配置信息會自動存儲在ZooKeeper中,包括邏輯CPU個數、內存和交換分區大小)。

能對Storm集群的Worker/Executer級別進行資源限制

這是目前Storm on Yarn做不到的。

模塊獨立於計算框架本身,方便安裝部署及回滾

適當的改進可以很方便地應用於其他框架平台中。

針對Storm UI不能滿足我們業務需求的問題,我們基於非Clojure語言重新設計實現了其UI模塊。之所以不采用Clojure語言及其Web框架,主要是考慮降低日后的學習和維護成本。在早期的使用中,我們發現原始的Storm UI有以下功能缺陷。

·         只能通過命令行提交Topology Jar包。

·         無法記錄Topology操作日志,給運維管理帶來不便。

·         缺少用戶權限控制。

通過重新設計Storm UI,以上問題得到解決。管理員可以操作Storm UI的用戶及其權限,也可以在UI上查看Topology的操作日志,對Storm應用進行有效跟蹤管理。未來我們會在UI上對Topology做更細致的實時監控。

隨着1號店越來越多的應用被部署在Storm平台上,實時計算的效益日趨明顯。2014年上半年部分業務每天產生的日志大約有2億多條,部署在Storm平台上的商品流量監控、個性化推薦和BI應用,都能做到個位數的秒級響應。同時,我們的日志流量在以極快的速度遞增。除此之外,我們還有安全日志分析、反欺詐和訂單監控等應用在有效運行。

總結

1號店作為一家成立時間較短的中小規模電商,業務增長十分迅速。我們意識到自己的實時計算平台在今后會有更大的壓力和考驗。在保證現有系統正常運行的同時,我們也在積極搜集業務部門的各種反饋,基於目前的平台和技術做進一步的調研和二次開發。如何提高系統峰值處理時的性能和可靠性,我們依然任重而道遠。

1.10      蘑菇街如何在雙11中創造99.99%的可用性

摘要:此次雙11蘑菇街的備戰思路是:首先,清晰的架構划分可以大大減輕穩定性工作量;其次,功夫要盡量在平時做足,避免總是出臨時解決方案;再次,普及穩定性思維,注意細節;最后,出現問題,先快速恢復再查找根源。

11購物節即將來臨,蘑菇街積極備戰各種大型促銷活動,為全國性的互聯網購物節貢獻自己的一份力量。保障這種大型促銷活動能正常有序地進行,確保99.99%以上的可用性,是我們需要面對的一個嚴峻考驗。因此,我們的工作主要依據以下幾個思路開展。

該做什么的就做什么

保障整個系統的可用性和穩定性,第一步需要做的就是,使整體架構清晰化、層次化。那么,對系統進行合理拆分,是最直觀的選擇。從業務和技術角度出發,遵循SRPSingle Responsibility Principle)原則,合理拆分系統中的各個模塊,明確每個模塊的職責。這樣可以方便快速定位和排查問題,甚至可以有針對性地對每個模塊進行優化。

拆分方式基本上分為兩種,路由拆分和物理拆分。所謂路由拆分,就是按照請求特征,將請求流量分攤到兩個或多個同質的集群里面;而物理拆分,就是在路由拆分的基礎上,按照業務和技術上的特征,將同質的集群進行徹底拆分,成為非同質集群。

下面以交易流程為例,來看一下如何操作拆分。交易流程主要包括購物車、下單、支付等幾個環節,具體的拆分結果,如圖1所示。

 

1  交易流程拆分結果 

經過分析,整個交易流程按照架構層次可以分解為展示層、業務層及外圍應用三塊內容,這三部分由於職責差異比較大,所以先按照物理拆分,讓層次清晰。

再來看展示層,由於存在一些共享的東西,如頁面元素等,做物理拆分,會引入額外的成本,所以路由拆分是不錯的選擇。

接着來看業務層。這一層是很容易按照角色和業務場景進行拆分的,例如,交易管理服務是給管理人員提供管理功能的,需要考慮權限、內控等問題;交易核心服務是給業務主流程提供主要業務功能,需要考慮可用性;交易查詢服務是讀取交易數據的主要途徑,需要考慮易用性;交易網關服務主要是對接外部支付渠道,需要考慮連通性。很明顯,這一層由於自身的差異性比較大,所以采用物理拆分是上上策。

最后來看外圍應用,其中包括后台管理、日志查詢、業務監控及交易超時控制等,這些應用基本上都是在底層系統平台(管理平台、日志平台、監控平台以及任務平台)進行二次開發而成的,所以天生就適合進行物理拆分。

從上面不難看出,拆分是一個細活,可以選擇的維度很多,拆分方式也比較講究。良好的拆分方案,會讓系統更加清晰明了,每個模塊該做什么的就做什么。這樣應對大型促銷活動時,可以游刃有余地按照模塊特征進行優化。

……

小結

本文講述了蘑菇街在確保可用性和穩定性實踐中的一些工作思路,但並不是說做好以上幾點,就能夠保證網站在大型促銷活動中的99.99%可用性和穩定性,只能算是在實踐過程中得到的一些經驗。

總結一下在可用性和穩定性工作中的一些感悟。首先,清晰的架構划分可以大大減輕穩定性工作量;其次,功夫要盡量在平時做足,避免總是出臨時解決方案;再次,普及穩定性思維,注意細節;最后,出現問題,先快速恢復再查找根源。  

作者姚明,蘑菇街架構支撐團隊負責人兼架構師,負責蘑菇街的應用框架、基礎服務、中間件產品、系統平台和安全體系等基礎架構建設。擅長領域為應用系統架構設計、中間件技術產品設計、系統性能調優和Web安全防范

1.11      履單流程的彈性架構——麥包包峰值架構實踐

摘要:履單流程也是電商系統中直接面對銷售高峰帶來的短時間內劇增的數據量的子系統之一,如何在流量驟增10倍甚至更多的情況下保證OMS的正常服務,是每一家電商密切關注和不斷改進的重點,也是本文分享的核心經驗。

OMS(訂單管理系統)是電商ERP系統中的核心模塊,其中的訂單履行流程(履單流程)是消費者購物過程中有直接感知的最后一段,關系到用戶體驗,其正確性和時效性必須得到保證。同時履單流程也是電商系統中直接面對銷售高峰帶來的短時間內劇增的數據量的子系統之一,如何在流量驟增10倍甚至更多的情況下保證OMS的正常服務,是每一家電商密切關注和不斷改進的重點。

與前端接單流程不同,履單流程無需提供秒級實時響應,但它要執行的工作不單是生成訂單保存入庫,而要協調ERP中諸多子系統、外部系統及人工處理,共同完成一個訂單的出庫發貨,因此面臨的問題和需要的解決方案都有所區別。

在麥包包,我們經歷了一小時接單峰值從千級到萬級再到十萬級的高速增長,雖然OMS中有中間表、分頁批處理等抗沖擊設計,但在一年比一年高的流量峰值沖擊下,仍不時出現阻塞甚至崩潰的跡象,讓人膽戰心驚。為解決這個問題,需要對整個履單流程所有環節進行分析,找出瓶頸和浪涌威脅,制定有針對性的解決方案,進行評估和測試,明確系統的峰值處理能力,保證在各種情況下的正確處理。

履單流程的流量治理同洪水治理道理相似,要找出高水位或者決堤的位置進行加固。加固的方法可以分為兩個方向:

·         疏通和拓寬河道——優化算法、合理並行;

·         蓄水限流——異步、緩沖、限量。

本文將結合麥包包的履單流程面對流量暴增問題時,需要研究的流程節點分析、執行效率優化、入口隔離和異步化、固定流控和彈性架構等方面進行討論。

關注點:一致性、可用性和峰值處理能力。

最低目標:流量不高於每小時10萬單情況下,能夠保證每個無須人工確認訂單30分鍾內提交揀貨;流量不高於每小時100萬單情況下,能保證每個訂單最慢在6小時內提交揀貨。

高級目標:流量高於每小時10萬單時能動態提升吞吐能力,在流量不高於15萬單情況下保持每個訂單30分鍾內提交揀貨。

在討論治理方案之前,我們需要將流程抽象和分解,進行深入分析。

流程節點分析

要保證系統在流量暴增的情況下正常提供服務,整個流程不能有任意一點產生阻塞。所謂阻塞點是直接或間接造成某個共享計算資源超負荷的點。電商OMS中,CPU和內存的密集計算一般不多,這個超負荷的計算資源多為DB Server。到底是哪一種類型的計算資源並不是最重要的,我們需要先找到引發或可能引發超負荷的原因,再找到其所在程序位置去解決。

履單流程從業務邏輯上一般分為前后銜接的多個步驟,我們將其稱為處理節點,我們要做的就是分析流程中各個處理節點,特別是以往產生過阻塞的節點。分析時除了一般性的代碼、數據結構的靜態分析和單元測試,對產生過阻塞的節點還可以從現場日志入手去分析。例如,對於DB Server超負荷的情況,要分析阻塞現場的SQL隊列,找到引起DB Server資源超載的主要幾條SQL,再順藤摸瓜找出觸發這些SQL的代碼位置和其所屬的處理節點。

麥包包的履單主流程包括訂單審核、支付確認、出庫單生成、快遞匹配等節點,簡化的流程如圖1所示。

 

1  履單邏輯流程

通過代碼和執行日志分析,我們發現訂單人工審核、物流匹配耗時較長,訂單的自動審核缺乏流量控制等問題。流程中節點耗時過長不僅會對整個流程的執行時間有直接影響,更重要的是當大量訂單涌入時可能堆積過多的數據庫慢查詢,造成數據庫並發過高、超負荷。人工訂單審核雖然不是自動流程的一環,但由於和自動流程訪問相同的數據庫,在面臨大量訂單時同樣也會拖慢數據庫性能,造成大量的鎖。

提交揀貨到提交發貨這一段屬於WMS的范圍,也需要持續優化,但這超出了本文的主題不在這里討論。

這些問題需要逐一解決,首先我們需要對單節點的性能進行優化。

基本處理能力優化(單節點優化)

流程由一個個處理節點組成,如果各節點本身還有優化的余地,那么整體分析就難以把握最優方向。因此在流程級優化之前應該先對各個節點進行優化,確保計算處理本身已足夠高效,也包括資源的合理使用和每個節點在架構上的可伸縮性。

流程整體調優前,首先要消除各個節點的執行效率瓶頸,做算法優化,提高並行效率,減輕或合理分布計算資源的占用。

以針對SOM(銷售訂單管理)模塊進行的優化為例,優化前SOM模塊的平均請求響應時間為1.89秒,優化后降低到了0.09秒。優化后單服務器每分鍾可響應請求667次,而優化前只有32次左右,在系統架構和硬件資源不變的前提下,提高了節點的處理能力,降低了資源的占用。

做單節點的優化,主要側重於邏輯優化、算法優化和代碼優化等。這個話題已被討論很多,基本原則如下。

·         優化算法,選擇合適高效的算法,降低不必要的遞歸、循環、多層循環嵌套等計算。用簡單的算法完成大部分情況,不要為少數特例而將算法復雜化。特例由特殊的分支處理。

·         避免申請過多不必要的內存開銷。

·         及時釋放資源,降低資源占用時間,包括內存、I/O、網絡和數據庫等。

·         善用緩存:緩存常用的、不易變化的;偶有變化,可以考慮緩存依賴機制。

·         慎用數據庫鎖。

·         恰當地使用事務,事務要細粒度。

·         選擇適當的通信方式:SocketRemotingWeb ServicesRESTSOAP)、WCF Named Pipes等,要特別注意長連接和短連接的恰當使用。

·         計算並行化。

·         降低系統或模塊之間的通信次數,例如工作流服務和數據庫服務。

·         降低系統或模塊之間的傳輸數據量,不必要傳輸的不傳或少傳。

·         異步計算,降低等待時間。

·         考慮延遲加載和提前加載兩種方式。

·         分離原則:分離業務模塊,如分離大I/O模塊、分離高耗內存模塊和分離高耗寬帶模塊。

·         統籌使用計算資源,如尋求內存計算、數據庫計算和網絡開銷三者之間的最佳平衡。

在單節點優化中,以上方法都可能用到。而對於履單流程來說,計算並行化和節點伸縮性也會起到比較重要的作用。

……

1.12      電商峰值監控經驗談

摘要:如何在第一時間了解出現的問題並及時解決問題呢?一套完整的應用性能管理解決方案在電商峰值架構中將發揮無比重要的作用。本文分享了應用性能管理提供商聽雲,多年積累的電商峰值架構監控經驗。

一年一度的11”購物狂歡節即將來臨,要確保用戶享受快、穩、炫的搶購體驗,技術工程師們需要解決瞬間高並發的諸多問題,如海量數據處理、網絡傳輸產生的延遲和負載均衡,等等。

那么,如何在第一時間了解出現的問題並及時解決問題呢?一套完整的應用性能管理解決方案在電商峰值架構中將發揮無比重要的作用,有了性能管理的保護傘,就可將宕機永遠留在襁褓中。

本文分享了應用性能管理提供商聽雲,多年積累的電商峰值架構監控經驗,希望能對大家有幫助。

監控內容

最底層是對服務器資源的監控,包括硬盤可用空間、CPU使用率、內存占用、I/O、網絡流量等指標。

第二層是對網絡鏈路層面的監控,其中包括內部網絡狀況的監控,例如集群之間的網絡連通性、路由情況,還包括外部用戶的網絡狀態監控,例如DNSCDN服務質量等指標。

第三層是應用層面的監控,包括Web應用容器、數據庫、NoSQL、手機App的指標,例如Cache命中率、JVM狀態是否正常、每秒的請求量(QPS)、請求響應時間、請求狀態、請求隊列長度、數據庫響應時間、慢SQL性能、MemcacheRedis服務狀態、App打開率、App交互性能、App崩潰等指標。

最頂層是業務層面的監控,包括關鍵業務的處理能力和業務邏輯的流暢程度等指標,例如單位時間的訂單數量、新客戶注冊數量、客戶投訴數量、關鍵業務的隊列排隊數量、用戶查詢購買某一商品的流暢度等。對不同電商來說,監控指標內容和數據來源完全不同。圖1中是需要監控的所有內容。監控內容存在短板效應,某一內容層面的監控缺失,均會引起電商的重大經濟損失。

 

1  監控內容

監控方法

構建監控平台通常有以下3種方式。

·         利用開源軟件和平台結合shell腳本搭建監控平台。

·         自行研發監控工具和監控平台。

·         購買第三方的監控服務。

無論采取哪種方式搭建的監控平台,通常都采用分布式架構。如果集中運算的話,通信和運算的成本會很高。因此,電商會采取在監測點分析監控數據的方法,先產生一個比較小的結果數據,然后匯總到一個集中的監控平台上進行二次運算。

由於監控內容涉及面廣泛,電商通常會根據不同的監控內容采用不同的監控途徑。

服務器資源的監控方法

除了使用操作系統自帶的基礎命令(如top free)采集數據以外,阿里、京東等資金雄厚且技術能力強的知名電商公司,開發並開源了一系列監控工具,例如Tsar是阿里巴巴開源的采集工具,主要用來收集服務器的系統信息(如CPUI/OMemTCP等)和應用層面的數據(如SquidHAProxyNginx等),用戶也可以根據需求編寫自己的采集模塊,集成到Tsar中即可使用,產生的數據輸出到遠程數據庫或者集成到NagiosCacti中即可顯示。

網絡鏈路層面的監控方法

監控內部網絡的狀態采取與監控服務器資源類似的方式,使用腳本調用操作系統自帶的命令(PingTracert等)或其他開源工具進行數據采集,數據集成到NagiosCacti中展示。

有兩種監控外部網絡狀態的方法可以得到用戶使用網站的體驗數據。一種方法是自行開發並運營監控網絡,此類方法適用於資金雄厚的公司,例如阿里開發了Alibench,並在全國征集志願者安裝這個工具,探測網站訪問是否正常並將探測到的數據上傳到服務器進行匯總分析。另一種方法是購買第三方服務,例如聽雲Network服務,以付費的方式招募會員,並在全球安裝監測節點。這兩種方法的技術原理相似,都是通過在全國或全球的終端用戶電腦上部署探測工具,探測工具內嵌IEChromeFirefox這些主流瀏覽器內核,獲取訪問網站過程中的DNS解析、TCP建立連接、頁面DOM解析和頁面渲染等過程的詳細數據。通過查看分類匯總的數據分析哪些用戶訪問網站時出現了錯誤或性能瓶頸,哪些CDN提供的加速效果更優秀,從哪些角度可以進一步優化網站。

應用層面的監控方法

常規針對應用層面的監控方法是,利用腳本對應用服務器產生的日志進行統計分析,或利用應用服務器自帶的統計分析命令和接口進行數據匯總。

Web應用容器層面通過HTTP請求訪問日志可以統計請求量(QPS)、請求響應時間、錯誤等信息,通過JVM命令查詢JVM狀態;在數據庫層面,開啟慢SQL查詢日志,使用數據庫相關命令統計慢SQL語句。

第三方APM服務廠商的應用性能管理服務,例如聽雲Server服務,采取自動跟蹤Web應用容器內HTTP請求的出入口和應用代碼函數方式,不僅可以采集應用運行時的QPS、請求響應時間、錯誤信息、SQL調用等信息,還可以采集到常規方法無法獲取的代碼級別的性能信息,進而分析應用的瓶頸所在。

對於近幾年興起的移動App而言,監控App應用需要研發人員嵌入第三方的SDK代碼。SDK代碼在App運行時統計用戶的交互行為、打開情況和崩潰信息,在一定時間段內匯總信息,提交到監控平台。

業務層面的監控方法

對關鍵業務處理能力的監控,通常采取研發人員預留API接口,使用腳本調用API接口獲取關鍵業務處理數據,並將數據集成到NagiosCacti中展示的方法。

業務邏輯流暢程度的監控需要購買第三方的業務流程監控功能,此類工具需要熟悉業務的人員錄制業務流程的腳本,並上傳到第三方監控平台。平台將流程腳本部署到第三方監控節點上,並自動回放流程腳本模擬用戶對流程的操作,最終平台會采集到每一步驟的性能和錯誤信息。

案例

2為某電商購物流程的監控曲線圖,監控流程為打開電商首頁,錄入商品名稱搜索,點擊搜索結果中一款商品打開商品頁,將商品加入購物車,點擊付款。

 

2  購物流程監控圖

33日購物流程可用性突然下降至65%左右,說明此時35%左右的用戶無法正常完成購物體驗。由於監控平台設置的報警閾值為90%,所以監控平台在監控到發生異常后5分鍾內發出了報警短信和報警郵件。電商運維人員接收到短信報警后通過查看詳細的監控數據定位問題並及時通知研發人員解決,問題於購物高峰期來臨之前被修復。

通過監控的瀏覽器拷屏數據發現,電商IT部門33日凌晨上線新改版的系統,由於兼容性測試不夠全面導致部分瀏覽器出現JavaScript錯誤,引起界面錯亂,造成購物流程無法正常完成(圖3)。

 

3  JavaScript錯誤,導致購物流程出問題

經過排查,程序員可以及時糾正這些問題,使電商網站尤其在關鍵業務上避免不必要的損失。

總結

通過前面的講述,我們可以看到,利用有效的監控手段,可以及時了解用戶訪問電商時出現的問題,極大地有助於電商企業的技術工程師快速定位出現問題的區域,並盡快給出解決方案。這樣可以極大提升電商網站的購物體驗,對於大促、秒殺等峰值場景更為重要。簡單一句話,在電商峰值架構中,監控無所不在

 

1.13      阿里11.11,技術與數據

摘要:用我們的視角觀察阿里第六年的雙十一,記錄雲計算與大數據的一次技術大閱兵。

20141111日是阿里雙十一的第六年。但卻是CSDN雲計算第一次參加雙十一現場活動。在我們看來,雙十一除了是電商的狂歡節日之外,也是雲計算與大數據的一次大閱兵。電視與網絡直播之外,我們更願意從自己的視角將更多技術展現篩選出來,分享給我們的技術小伙伴們!(今日CSDN大頭條是《鏖戰雙11,電商架構大起底11.11需要穩定高效的系統架構設計來提供有力支持,揭示了國內各大知名電商架構設計的最佳技術實踐。)

 

1110日杭州淘寶。飛機落地后,來不及辦理入住,直接沖入阿里數據大廳(媒體直播席)。而今年與往年最大的不同是,400多家媒體中,約1/4是外媒記者。

主持人介紹今年是雙十一的第六年,從2013年的2000套縮減到今年的500套技術預案,8次流量峰值的壓力測試平穩。今天所有數字都是實時的,未經任何加工的元數據。這是第一次將后台所有數據都直接對外公開。而所有數字都有美元顯示(方便外媒理解)。

21:30,阿里集團COO逍遙子說,移動端的無線接入在18:30以后開始快速增長,這是六年來的第一次。他認為,這是大部分用戶在下班后的回家途中,如公交車、地鐵等,已經開始雙十一的准備。針對之前業內的一些討論,他再次強調雙十一是所有人的。

21:35 有媒體問逍遙子對今年數字的預估?沒有明確回答,但他相信絕對會讓大家驚訝。

21:40,主持人在串場的時候,順便瀏覽了會前信息,有幾條不錯:

今年的天貓雙十一,活動頁面、商品排序都是由算法決定的。哪些商品能進入雙十一會場、出現在哪些用戶的頁面和什么位置,都有數據算法在背后支撐。 
據阿里巴巴集團在20143月披露的數據,阿里巴巴的數據中心已經攢下超100PB1PB=1024TB)經處理的數據。 
基於大數據的算法,可以讓流量更加個性化。每個人看到的雙十一頁面都不一樣,大數據讓推薦更加精准。 
基於大數據的分析,能夠預測下一階段的消費熱點,並給商家提出建議。

保障今年雙十一的大軍中,天貓事業部投入近2000名員工,阿里巴巴集團總投入超過11000名員工。天貓自身加上商家共投入近百萬的客服力量,菜鳥的14家物流快遞合作伙伴中共有125萬快遞員參與。

從技術方面來看,在歷經五年雙十一考驗后,阿里巴巴技術團隊已具備能力,將黑客攻擊、局部爆發性流量增長、機房空調故障等種種不確定因素變為可預估的風險。基於在雲計算領域長期的技術積累,阿里巴巴技術團隊還在今年雙十一之前,攻克了兩項世界級的創新難題--“服務器資源彈性部署數據中心異地雙活

阿里巴巴在會議報告廳搭建了數字大屏,提供七路實時信號,包括數據大盤、全球交易圖、百強縣交易圖、熱賣品牌榜,菜鳥物流雷達預警等。相比去年13米長、6米高,升級到16米長,6米高,屏幕面積近百平米,總重超7噸。

22:00 天貓推薦算法獲獎隊伍在這次雙十一中將有一次暗戰CSDN雲計算的讀者應該很有印象,8月的《學生強則國強,訪天貓推薦算法大賽Top 9團隊》就是我們對獲獎團隊的采訪。這次淘寶將會將雙十一的數據釋放一部分給這些團隊中的6位傑出同學,直接在后台進行算法PK,如果比天貓算法團隊在這次實戰中表現更為優秀(UV超過天貓團隊的15%),將獲得100萬獎金。天貓技術負責人李強表示,阿里11000名技術小二需要更多幫手,歡迎更多技術伙伴加入進來。

22:30 剁手舞挺有意思,大家都去看看。:)現場問答的獎品是搭載雲OS3.0的智能手機。

23:00 明星恭賀雙十一的視頻播放等。后台看到一些數據。0點將實時釋放數據。對了,去年的數據是:20131111日凌晨,一分鍾內有1370萬人涌入天貓,相當於大半個北京城的人都出來逛街。其中,34剁手黨在這一分鍾內搶到了心儀的寶貝,成交1.17億元。今年會是多少呢?

23:30 實時數據分析圖終於對外公開了。數據大盤、全球交易圖、百強縣交易圖、熱賣品牌榜,菜鳥物流雷達預警等都有。居中的主屏幕是交易額、無線成交占比(每5S刷新一次),其他部分是2分鍾刷新一次。先欣賞下。

 

23:58 是的,提前兩分鍾將切換。因為現在后台是10日的交易量。主持人反復強調觀測數據發生,也許會有突發情況,請記者們一定冷靜。

00:00  數據出來了。20141111日凌晨,3分鍾內成交超過10億元。美國成為TOP4的購買區。無線成交在60%以上。

 

113秒時的照片留念

00:11 11分鍾的時候,成交超過40億元。由於美國現在是白天工作時間,所以購買力增長強勁,最高排到TOP214分鍾,超過50億元。17分鍾,廣東快遞包裹量超過2萬。19分鍾,訂單數量2600萬個。超過170個國家參與到購物狂歡中。天貓雙十一大家電送貨入戶的第一單,在11日零時18分送達,廣東佛山一位買家購買的奧馬冰箱。

00:25 2013年產生了1.5億包裹量。今年雙十一,25分鍾時已經產生3000+萬包裹,現場記者均認為預計包裹量將遠超過去年。陸兆禧回復了記者關於銷售額、物流等問題。

00:37 38分鍾,突破100億。2013年,38分鍾50個億,1小時67億,今年50億只用了14分鍾,20分鍾就完成了去年1個小時的交易額!100億只用了38分鍾!贊。

00:45 今天媒體直播到1點。明日還是到凌晨1點。看到很多有價值的照片,明日上圖。

111118:00左右,特別約了阿里技術保障部的技術負責人,聊一聊備戰雙十一的技術故事。大家有關心的問題,歡迎留言。

02:00現場大屏確實沒有付款筆數的實時顯示。考慮到支付寶、天貓寶、余額寶和銀行對接系統的復雜性,也能理解。2點時,支付數據產生。第一分鍾83萬筆,第三分鍾410萬筆,第30分鍾4086萬筆,第一個小時,支付寶完成的付款筆數已經達到6283萬筆。

移動方面的數據確實令人驚艷!開場第1分鍾實現的移動支付筆數達到65萬筆。開場后的第一個小時,用戶通過手機完成的支付筆數則達到3504萬筆支付。

補充些有意思的背景資料:

支付寶首席架構師程立表示,每年的雙十一都是對中國支付系統的一個考驗。從今年雙十一第一個小時的情況來看,支付寶和各大銀行、天弘基金等合作伙伴在雙十一前充分的准備初步發揮了成效,整個支付系統穩定得經受了雙十一第一波交易洪峰的考驗。而跟往年相比,銀行對此次雙十一大促的重視程度空前。總行科技部位於北京的多家大行,即使在APEC放假期間也加班進行系統測試和優化。雙十一的前一天,建行,平安,興業,民生,中信等多家銀行的行長已趕到杭州督戰。

今年支付寶和各大銀行的合作變化在於:四大國有銀行和各家股份制大行都改變了以往分行各自對接的模式,開始余支付寶進行總對總對接,即銀行總行科技部與支付寶系統對接。這一模式變更的好處在於銀行科技部技術力量可以集中投入,同時減少交易鏈路消耗,提升系統處理能力及穩定性。

官方發布的數據顯示,雙十一第一個小時的支付中,快捷支付占到所有支付金額的46%,在所有渠道中占比最高;緊隨其后的天貓寶占到所有支付金額的16%,余額寶支付占到15%,賬戶余額占14%。而傳統的網銀支付,所有銀行的網銀等其他渠道相加只占到了9%。天貓寶、余額寶及余額對於支撐整個雙十一的支付系統,緩解銀行支付渠道壓力起到了至關重要的作用。

05:00 baba股票創新高, 市值觸及3000億美元。

07:00 7小時36分零6秒,2014天貓1111購物狂歡節無線成交額達100億元!(移動端)數字還在跳躍。這個時候如果有機器人輪崗,會很棒。

10:00  2013年,聚石塔處理了75%的雙十一訂單。今年,構建在阿里雲基礎上的聚石塔將處理超95%雙十一訂單。在系統擴容、壓測之外,與第三方服務商的ERP軟件,如訂單管理、客戶關系管理、店鋪運營等協作也是重點。有朋友說,還提供了訂單全鏈路功能,幫助商家實時監控數據,從用戶拍下訂單、系統收到訂單,到配送、簽收完成交易,每一個環節都可用數據大屏進行監控。

12:00 截止十二點整,天貓1111購物狂歡節已有12家商家成交額過億元!42家商家成交過5000萬。菜鳥生成的訂單和去年全天持平。值得紀念的是,11:49突破52.9億美元(超過去年美國感恩節購物季的所有金額)

 

13:23 359+億元,無線占比45.2%25分鍾的時候,已經360億元了。去年全天是362億元,已經無線接近了。

13:31 超過362億元,超越去年雙十一戰績。期待已久的雙十一技術總負責人劉振飛,螞蟻金服CTO魯肅和菜鳥負責人14:00左右將來到直播現場。

 

13:50  回味了幾組數據:

2009年雙十一銷售額5200萬元;
2010
年雙十一總銷售額9.36億元;
2011
年,這一數字是52億元;
2012
,實現191億成交額;
2013
年,實現362億元。

主持人說14:00時候,阿里聯手所有伙伴送出一個大彩蛋?!哦,大數據分析告訴大家,14:00以后進入平穩階段,增幅很窄,為了提供更多機會,所有賣光產品再來一次,相當於將雙十一分成上下兩場。是否有效果,一會數字說話。

14:00  振飛已經連續負責6屆雙十一技術保障,他說:本次雙十一交易能力達到每秒8萬筆的上限;支付能力在峰值能力突破每秒 3.8萬筆。在手機客戶端上提升用戶體驗花費很大力氣,成立無線小組,從移動網絡、手機、網絡優化進行了全方位的優化。支付體驗也比較流暢,無論是支付寶還是銀行支付,都能推薦用戶比較適合的通道,便於搶貨。更有創新的是,阿里歷史上第一次打通了交易平台和支付平台,8次演練中遇到很多問題都得到了解決。所以今年高峰到來,我們淡定迎接了挑戰。對於今年重點關注的海外客戶,阿里特別在海外部署了更多的CDN,提升海外購物體驗。

對於本次阿里雲和大數據技術在雙十一中的作用,振飛強調了五點:

1. 通過基於阿里雲的聚合塔,承擔了95%雙十一訂單。
2.為中小金融機構提供服務是聚寶盆(阿里雲金融服務),幫助更多用戶使用金融服務。
3.基於阿里雲的余額寶,成為支付的核心。
4.跑到飛天5K上的自主研發的ODPS,為天貓雙十一的商品個性化推薦提供了技術支持。
5.凌晨切換到自研的核心數據庫OceanBase上,經歷了考驗。以此為起點,支付寶數據庫將取代國外技術,全面切換到OceanBase上。

14:50 螞蟻金服魯肅表示,支付寶在今年雙十一的交易峰值已經達到285萬筆/分鍾,相比去年雙十一期間79萬筆/分鍾的交易峰值,今年系統的支撐能力達到了去年3倍以上。他將成歸功於:

1.每年大促扎實的基礎之外,今年以來,支付寶在系統和技術上再次進行了升級。建立在雲計算和大數據平台上,自研的雲支付系統在雙十一之前正式封頂,實現了全分布、全冗余、高彈性、低成本的海量交易與數據處理架構。相比上一代的支付寶系統架構,雲支付架構可以支持十億筆以上的每日支付處理能力,具備更高的服務質量、安全性與穩定性,更低的系統成本。
2.
眾多的銀行合作伙伴也同支付寶一道在雙十一之前把系統的支付能力提升到了去年的2倍以上。為順利迎接雙十一,支付寶和眾多銀行一道前后進行了10次以上高強度、高仿真的系統壓力測試。當然,由於峰值壓力的巨大,仍然有部分銀行遭遇了擁堵瓶頸。(1111日凌晨的交易高峰期,系統出現小范圍的短暫擁堵,影響到淘寶、天貓和一些外部商戶的交易成功率,但隨着交易高峰期的結束,很快整個系統就恢復了正常,對於給大家帶來的一些不便,他對此深表歉意。)
3. 10
次以上的測試,其中大部分是攜手振飛團隊完成的,最后一次已經完全可以達到8w的上限。去年5月份,在去掉了最后一台小型機之后OceanBase表現非常出乎意料,完全支撐了雙十一的壓力。

15:30 菜鳥物流的數據在整體分析中是很重要的一環。從零點到現在累計產生物流訂單量是1.86億筆(186,074,242)。如一些朋友所言,今年雙十一在縣級市場起量很快,這意味着,壓力都在物流環節。

16:00 國際市場是今年新的增長點。目前已有206個國家和地區成交,在享受中國雙十一。運輸/物流很重要。速賣通平台,多數國內用戶並不關注,但他是淘寶海外的代言者。這些數據分析卻很有意思,目前來看,甚至格陵蘭島和智利都有下單。1116點速賣通平台開始促銷,數據變化能夠明顯表現這些。目前TOP消費國家及地區的是,中國香港、美國、中國台北、澳大利亞、加拿大、新加坡、澳門、日本、馬來西亞和英國。

 

出口之外,進口同樣重要。目前國內消費者購買海外商品越來越多。大出口,大進口的轉折點到來了。天貓國際的體驗就要和國內淘寶等完全一致。面對政策監管的需要,堅持數據運營很重要。

17:00 獨家采訪阿里技術保障部資深總監周明。他說從10月份預演和壓測,第六次才全部通過。技術上,他重點分享了服務器資源彈性部署和數據中心異地雙活。尤其是后者,從2013年初啟動,直到近期才正式完成,剛好趕上雙十一。而同時做到數據庫,保數據的一致性,解決距離帶來訪問延遲的超大體量電商網站數據中心異地雙活,目前全球只有阿里巴巴已完成部署。詳細內容近期發布。

19:20交易額突破462億元。俄羅斯數據快速上升。無線突破200億元。

19:25  阿里巴巴集團董事局執行副主席蔡崇信極為低調,鮮少在媒體中露面,他的出現引發大家的關注。他分享了最初加入阿里的原因,並談到阿里的快速發展離不開人,即使到現在也很缺人才。談到投資,能增加用戶粘性的創新企業會是收購目標。

20:00  大家電和手機在今年雙十一中表現出色,TOP5分別為海爾、美的、海信、樂視TV、格力;小米、華為、魅族、蘋果、三星。20:39時,訂單量已經突破2.3億個,成交額487+億元。

21:10 突破500億元。經過下午平穩增長后,開始迎來第二個成交額的洪峰。訂單量達到2.4+億。下午2點,依照大數據技術分析所產生的第二波活動,從時間軸的變化趨勢可以看出,略有影響,

 

22:30  215個國家及地區在通過天貓上參加雙十一活動。海外用戶購買產品排行,第一名手機,第二名連衣裙,第三名假發。成交額已經533億元。

22:36 馬雲穿着一件綠色上衣出現了,昨天在指揮室是紅色上衣。他說並不太關注數字,而最擔心的是明天的物流。今年是為國際化做嘗試,是為未來3-5年國際化做准備。等到雙十一十周年的時候,相信全世界都將為年輕人的創新而自豪。他再次對所有記者說,希望支付寶能在A股上市。

 

22:50按照去年的傳統,最后時刻將關閉實時數據。留給大家十余分鍾的想象空間,然后才公布結果。剛剛馬雲說,即使是雙十一技術總負責人振飛也沒有權利碰這些數字,他也是如此。所以,這些數字都是最真實的。

23:15 主持人說淘寶最主流的人群是80-90,隨着這一代的成長,目前TOP20榜單中有大家電、家居、母嬰用品等。小米突破15億元,位於單店之首。25分時,成交額554億元。從時間和成長曲線折率來看,也許最終600億左右。

23:40  561億。停止實時數據顯示。20分鍾之后,出最終結果。

0:02  最終數據為571億。美元93億。無線占比42.6%2.78億訂單。

 

直播結束。留下的思考還有很多。技術無極限,創新無邊界!

http://www.cnblogs.com/fang-beny/p/4210117.html

文章來源:http://www.csdn.net/article/2014-11-11/2822571


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com