海爾電商峯值系統架構設計最佳實踐（轉）
摘要：本文重點介紹了海爾電商平臺的架構方案，也用很多篇幅闡述面臨的場景和挑戰，以及在架構方案決策過程當中的關注點。其實做爲一個優秀的電商平臺，提供極致的用戶體驗、讓技術最大化地創造價值，纔是架構的終極目標。數據庫
多數電商平臺都會經歷類似的過程，流量和業績每一年以幾倍至十幾倍的速度增加，每一年都要接受幾回大規模、全方位的系統檢閱，例如雙十一、週年慶等購物狂歡節，期間流量和訂單多是平常的十幾倍甚至幾十倍，產生的峯值對平臺造成極其強烈的衝擊，對電商平臺的架構帶來巨大的考驗。所以，對電商平臺的規劃和架構工做不只要高瞻遠矚，並且要細緻入微，不然將致使平臺沒法知足高速增加的業務發展，細微處的失誤也可能形成嚴重後果，不只影響業務指標的實現，還可能致使對系統進行從新架構，勞時費力又傷錢。緩存
從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應用，儘量達到通用靈活的目的。
- 擴展性：經過邏輯模型屏蔽了底層的數據模型，將數據模型的優化、擴展工做量以及影響範圍下降到最小限度，提高了電商平臺中產品服務的可維護性和擴展性。
以查詢引擎爲核心的產品服務是一個魚與熊掌兼得的架構設計案例，通用性、擴展性、伸縮性等在電商平臺中相互制約、矛盾的一組核心架構目標所有獲得知足。