京東達達核心系統架構：從短平快到體系化的設計精要

商品系統是電商系統最基礎、最核心的系統之一，商品資料遍布所有業務，首頁、門店頁、購物車、訂單、結算、售后、庫存、價格等，都離不開商品，商品資訊要穩定提供至到家供應鏈的每個節點，所以必須要有一套穩定的、高性能的商品服務體系支撐，

隨著京東到家商品業務的快速發展，業務從單一轉變為多元化，系統功能設計上也從最初的大而全的功能支持，向微功能、領域化演變，

商品系統也在高可用、高并發的持續沖擊下，經歷了多個架構版本的演進，最初1.0版本，采用合適簡單的設計思路，滿足了業務快速迭代上線；隨著業務量級的快速增長，針對高可用、高性能的提升，演進出了2.0版本，隨后業務復雜度的提升，導致了系統復雜度的提升，為了解決系統復雜度帶來的問題，孕育出了3.0商品體系領域建設，

到家商品系統創建之初，為了貼合業務的快速發展，設計并且上線了到家商品1.0系統，商品系統服務本著大而全的思想，用一套服務提供給上游業務方聚合的商品資料，無論是B端業務還是C端業務均耦合在一起，在應對業務快速迭代上線、節省開發成本上充分體現出了簡單的優勢，

隨著業務量級的增加，最初設計的劣勢也突顯了出來，主要體現在以下幾點：

針對上述問題，商品系統從高可用、高性能的出發點進行了架構2.0演進；

商品系統經歷了1.0快速迭代的階段后，線上流量也隨著業務的增長翻倍，B/C端服務的高耦合導致了商品服務的波動大，而且監控的不全面也導致了不能及時發現系統例外，

為了提高商品系統服務的高可用，商品系統制定了以下迭代方案，

1）AP原則 + 最終一致性思路

商品系統服務通過高可用的演進后，為我們提升商品服務的性能爭取了時間，由于1.0版本商品C端服務的降級查詢、以及快取Redis擊穿等問題，對商品系統的性能影響非常大，

例如：在促銷期間，高并發的場景下經常會因為降級查詢性能損耗->回應執行緒等待->執行緒池等待佇列打滿->拒絕策略，繼而引發商品的整體服務性能變慢，

為了提高商品系統服務的性能，商品系統制訂了以下迭代方案，

1）C端去MongoDB依賴

商品1.0版本，C端的請求未命中redis快取，則會降級查詢Mongodb資料庫并把資料回寫到redis中，單次請求在商品系統內部經歷了多次互動，且部分邏輯是與用戶行為無關的比如反寫redis，同時存在著比較嚴重的快取穿透的風險，商品服務端API性能上波動較大，風險也相對較高，

商品C端讀服務移除了降級查詢Mongodb的操作，且在B端處理了對Redis快取的寫操作，移除Mongodb依賴之后，商品C端讀服務能力性能得到了極大改善，

2）Redis持久化快取

商品系統經過C端查詢去降級的改造后，Redis集群存盤的KV，由之前的1個月過期時間，轉換為持久化KV存盤，

去掉Redis的KV過期時間，關鍵問題在于如何保證MongoDb資料庫和Redis集群的資料一致性，B端商品資訊修改 通過異步任務的方式，將資料持久化重繪到redis快取中，C端請求Redis未命中的KV則視為不存在，不僅減少了商品系統內部請求的互動次數，而且有效防止了快取穿透問題，最終降低了服務端回應時間，

3）資料異步處理服務

商品最初的B/C/異步任務 耦合在一起，B/C服務經歷拆分后各自耦合了異步任務，當商品在修改資訊、圖片、屬性、狀態業務的時候，會異步回寫Redis快取來確保MongDb和Redis快取KV資料的最終一致性，但是大量的異步任務會占用服務資源，從而拖慢B/C服務性能，

所以商品系統搭建了一套獨立的資料異步處理服務，包含了異步任務以及訊息佇列，承載了商品B/C端服務所有的異步寫、回寫等資料操作，

拆分出的異步任務平臺，不僅保障了異步任務功能的完整性，而且根除了異步任務大量寫的情況下造成的B/C服務性能波動，

4）記憶體快取ehcache

商品服務存在很多字典資料，比如類目字典、商家分類字典，這些字典往往都是商家維度的大key，而且商家維度的key hash到分片相對集中，大流量的情況下容易出現熱點key的問題，導致某幾個分片輸入輸出緩沖區溢位，影響整個redis集群，

商品系統引入了ehcache記憶體快取，通過客戶端服務器記憶體存盤這類資料，不僅解決了大key、熱key 的問題 ，而且減少了與redis中間件的網路請求互動，請求回應速度大幅提升，

商品系統經過高性能、高可用的系統演進后，商品系統穩定高可用，在后續的大促流量驗證下表現出色，

隨著商品業務的迭代、以及系統的復雜度的增加，業務耦合度高、系統擴展困難、維護成本高的問題突顯出來，

商品業務由最初是線性的，隨著業務的復雜度提升，商品的業務由線性逐漸轉變為非線性，

例如：商家在建品后，由于操作不當，維護錯了商品的資訊，導致了例外品類商品資料產生，需要想辦法實時監控、處理資料，

又例如：商家入駐到家平臺，想把自己的商品快速同步至到家，我們如何提供一個快而全的建品體系供商家使用，

隨著需求復雜度的提高，帶動了商品系統的復雜度提高，我們在業務開發、擴展、維護的成本也隨之提高，

而且系統復雜度提升也帶來了以下幾個問題：

為了提高系統擴展性、減少業務開發周期、節約維護成本、降低系統風險，在保障商品系統服務的穩定、高可用的前提下，開始啟動了商品系統的3.0版本架構演進：商品體系領域建設，

首先要明確商品業務的需求點，然后根據不同業務的需求點，從聚合的業務上劃分出領域，基于業務領域對系統進行垂直拆分，用分而治之的理念進行商品體系的建設，繼而拆分并獨立部署以下幾個業務領域系統，

到家獨有的UPC模板系統，提供給商家一鍵建品的商品模板以及對商家的標品進行規范，更好的賦能商家建品，

通過大資料分析，根據商家型別、經營范圍等 補充、提供商家缺失的商品清單，協助商家進行拓寬商品，

根據到家商品規則，治理商品的各項基本資訊，規范正確資料，制定商品規范，

針對商品用戶端和手機端進行了商品數量的限購活動支持，協助商家維護單品的限購，

商品上的類目屬性、特殊屬性等邊緣屬性系統的拆分，

商品體系領域劃分后，我們接下來要考慮如何在原有系統的基礎上，把系統拆分出去，

商品系統拆分主要面臨以下幾個問題：從哪開始入手拆分？資料按照什么維度拆分？服務按照什么維度拆分？怎么保障拆分中的系統穩定？

針對上述問題，我們進行了以下幾個點的操作：

1）自上而下邏輯分層

首先，選擇邏輯分層，目的在于隔離關注點-每個層中的組件只處理本層的邏輯，業務層中只需要處理業務邏輯，這樣我們在擴展某層時，其他層是不受影響的，通過這種方式可以支撐系統在某層上快速擴展，

其次，在原有層級上進行拆分，會對商品原有的邏輯功能造成很多不確定性的影響，新增加的業務聚合層，可以起到對上聚合入口、對下拆分方法的作用，自上而下的結構化分解極大程度上保證了系統升級迭代的風險可控，同時保持有更好的節奏進行后續的業務拆分；

2）自下而上方法分解

①方法分解：

經過自上而下邏輯分層后，所有的業務方法全部抽取到business層進行聚合，接下來就是自下而上方法邏輯拆，保持原有service方法邏輯不變，并行一套全新的serivce層級并且保證方法遵循單一職責原則，這個程序耗費很多的時間和精力，所以盡量按照業務聚合層來決定拆分方向的優先級（優先次要業務），避免和正常業務需求開發的沖突，解耦本身就是一個小步慢跑的程序，不可能一步到位，拆分出的方法一定經過充分的測驗驗證，確保前后業務邏輯沒發生改變，

②方法切換開關：

在business聚合層增加Zookeeper開關，用來切換新老方法呼叫，新方法如果有問題隨時切換到老方法上，保障線上穩定，在線上充分穩定一段時間后，可以在后續的上線中去掉方法切換開關以及廢棄的老方法，

3）業務領域拆分

在邏輯分層的基礎上，按照商品業務進行垂直拆分，拆分出品牌、屬性、分類、資訊、圖片等業務模塊，對業務模塊進行了解耦合，此時的業務以及代碼層級結構已經很清晰了，可以根據模塊按照優先級進行系統微服務領域拆分，

4）Redis快取拆分

商品系統資料存盤在一個Redis集群中，在持續高并發請求下，Redis的輸入、輸出緩沖區流量會觸達峰值，導致服務端、客戶端連接中斷，從而影響讀服務的穩定，雖然可以通過橫向擴容分片來解決燃眉之急，但是隨著資料量級的不斷增長，Redis單集群的風險也越來越大，

商品基于Redis集群里不同的資料KV，拆分出了主資訊KV、詳情KV、屬性KV等獨立的Redis集群，并且通過異步任務增量更新Redis集群資料，

5）微服務架構演進-面向服務

根據業務領域,拆分出獨立Redis快取集群后，緊接著按照業務領域拆分服務,拆出了主資訊系統服務、圖片系統服務、圖文系統服務、屬性系統服務等，

拆出的業務服務獨立部署，根據自身業務功能點分配合理的機器資源，服務體系之間垂直隔離，提高了服務整體的可用性、可伸縮性，解決了因為某個模塊導致的整體服務不可用的問題，

商品系統體系化建設正在持續完善中，展望未來，到家商品系統在智能化、自動化、服務化的建設上，以及和演算法、大資料領域的互動上，還有很多可拓展的方向，

比如：

上述舉例，我們有以下幾個思路：

京東到家商品系統架構的每次演進，都是貼合業務的發展，目的都是解決業務系統復雜度帶來的各種問題，1.0階段應對業務系統的快速迭代，2.0階段應對業務系統的穩定、高可用，3.0階段應對業務系統體系建設，每一個階段盡量使用合適、簡單的設計，防止過度設計產生更多的復雜度問題，

本著架構是頂層設計，并且貼合業務的思想，在系統優化設計的道路上，保持合適、簡單原則的本心，以及持續可演進的方向，對到家商品系統進行不斷的迭代和優化，在未來的日子里，還會遇到更多的挑戰，更多的業務場景，更多未發現的隱患，相信沒有最好的設計，只有最貼合業務的設計！