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

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

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

商品系統也在高可用、高併發的持續衝擊下，經歷了多個架構版本的演進。最初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階段應對業務系統體系建設。每一個階段儘量使用合適、簡單的設計，防止過度設計產生更多的複雜度問題。

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