摘要：本文重點介紹了海爾電商平臺的架構方案，也用不少篇幅闡述面臨的場景和挑戰，以及在架構方案決策過程中的關注點。其實作爲一個優秀的電商平臺，提供極致的用戶體驗、讓技術最大化地創造價值，纔是架構的終極目標。
多數電商平臺都會經歷相似的過程，流量和業績每年以幾倍至十幾倍的速度增長，每年都要接受幾次大規模、全方位的系統檢閱，例如雙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應用，儘可能達到通用靈活的目的。
- 擴展性：通過邏輯模型屏蔽了底層的數據模型，將數據模型的優化、擴展工作量以及影響範圍降低到最小限度，提升了電商平臺中產品服務的可維護性和擴展性。
以查詢引擎爲核心的產品服務是一個魚與熊掌兼得的架構設計案例，通用性、擴展性、伸縮性等在電商平臺中相互制約、矛盾的一組核心架構目標全部得到滿足。
作者劉志斌，海爾電商首席架構師，資深技術控，10多年專注於供應鏈和電商領域，曾先後在麥考林和麥包包任職架構師。