商品，黃金交易流程最基礎、最核心的環節，無商品不電商。商品資料無處不在，商家（採銷、供應商）釋出管理、供應商下采購單、倉儲配送、促銷、搜尋、商詳頁展現、購物支付、財務結算、售後服務等，都離不開商品。商品資訊要準確傳導於京東整個供應鏈的各節點，必須要有一套穩健、可靠的商品服務體系支撐。
原本並沒有統一的商品服務及儲存。DBA搭建了一套包含若干層級的SqlServer資料庫複製結構，各系統從各級從庫讀取資料。複製延遲嚴重的時候，超過12小時，從庫還沒有更新，嚴重影響使用者體驗。寫入口不止一個，獲取到寫賬號就可以寫入。erp商品管理系統、POP商品系統、BIP甚至也開發了一個商品管理系統，都在寫同一個庫的同一套表，資料一致性無法得到保障。在那個階段京東的訂單量、使用者量相對較少，基於資料庫的架構一定程度上也能支撐日常流量，但是無法應對大型促銷活動。
在此背景下，2012年3月商品組從網站組獨立出來，孫歌臨危受命組建團隊，啟動商品技術架構升級專案。京東618年中狂歡購物節，系統（特別是0點）會承受平時無法比擬的壓力。2012年之前的大促都會出現系統問題系統經常出現問題，甚至圖書搶購活動時直接系統當機。基於資料庫提供讀服務的架構，顯然已經無法支撐業務前行，升級改造勢在必行。12年初NoSQL還是新鮮事物，交易架構師龔傑開始實踐Redis，他在一封郵件中介紹自主封裝的客戶端以及API。商品團隊開始基於redis記憶體資料庫搭建商品讀服務，並對開源Jedis做了深度封裝，擴充套件了ShardedJedisPool，實現了更加細粒度的多分片連線池管理，並且將一個請求中命中到同一個分片的redis命令由序列改成pipeline並行執行，效能提升較大。
架構1.0 讀服務化
由Redis儲存全量商品資料，作為記憶體資料庫使用。商品資訊變動時增量更新，一主多備模式容災，同時全量重新整理程式作為最後保障，一旦Redis中資料全部丟失，可以將商品庫中資料恢復到Redis。
交易系統直面使用者，為保證使用者選品、下單結算的順暢，提升使用者體驗。交易系統對高效能、高可用的商品讀服務需求最迫切。此時架構升級採取了一種“輕模式”，所謂輕是指儘量減少外部系統的改造，這樣更利於工作的快速推進。首先在通知模式上，各種商品系統寫入Sqlserver主庫後，通過HttpHTTP服務通知Rcat
-server（採取儘量做的策略，能通知就通知到，有異常也不去重試，這種策略對相關係統的改造最小）。Rcat-server的職責就是接收通知，之後查詢主庫中的商品資訊，將其更新到Redis中。因為寫入系統是儘量做，不保證成功的模式，因此需要補償機制去彌補遺漏。非同步Worker會定期掃描資料庫，把當日更新的，從重新整理到Redis中。
V1.0版架構非常不完美，只是讀服務這個點進行了改造，但是卻在當年618中完美的完成了任務。618當天像往年一樣，研發工程師售後守候在運維同學周圍，時刻準備著！整個過程波瀾不驚，只有過個別應用過載重啟，整體非常順利扛過了大流量的考驗。有了這個經驗，研發工程師們開始將Rcat（應用名稱，商品讀服務）推廣，依賴Sqlserver從庫的系統都逐步切換到讀服務上。
架構2.0 全面服務化
POP商品系統和自營商品系統都是寫入Oracle，在通過非同步worker將資料寫會Sqlserver。京東商品的獨特之處在於最初是自採自銷的自營類商品，有自己的商品模型和對應的erp管理系統。後續有了POP開放平臺，該平臺的商品模型和系統是獨立搭建的，適應於第三方商家的商品釋出管理。而所有下游的系統（單品、搜尋、訂單生產、倉庫等）都是基於最初Sqlserver自營skuSKU模型做的系統設計。所以POP商品有自己的Oracle儲存，也必須京東經過一步非同步程式轉化，寫到Sqlserver商品庫中。而自營商品系統在2011年架構升級時，計劃由.Net+Sqlserver的技術體系升級外Java+Oracle技術體系。
孫歌作為研發負責人，基於技術前瞻性和成本考慮，果斷決策放棄既昂貴又沒有DBA團隊良好支援的Oracle資料庫。轉而直接基於SqlServer實現商品的全面服務化，相比其他系統的去O足足早了一年。當時的整體思路是先實現服務化，再進行儲存升級（Mysql叢集），最終完成徹底的技術架構升級。全面服務化過程：
1). 全面讀服務體系:
將下游系統讀取的資訊重新整理到Redis中，由讀服務Rcat統一支援根據skuId查詢的需求。對於檢索需求，例如根據分類id查詢SkuSKU列表，搭建Solr索引服務。基於各系統的需求收集已經當前SQL的分析，搭建了讀服務體系，並逐步推廣，去掉各系統對Sqlserver資料庫的讀取依賴。
2).寫服務化
接管所有商品寫操作，提供商品相關的基本讀寫服務，建立商品主資料中心,服務於自營商品管理、POP平臺、圖書音像商品管理等系統。京東起家於3C自營產品，
SKU化管理。後發展的POP平臺，是商品化釋出管理。寫服務必須相容兩套模型，平滑過渡。研發工程師最終設計為統一到商品-skuSKU模型，自營商品與SkuSKU一對一，而POP商品與SkuSKU是一對多。自營商品每釋出一個商品有且僅有一個SKUSku，pop商家釋出一個商品可以有多個SkuSKU。自營商品溝通通過後期的顏色尺碼繫結，實現銷售關係捆綁。這樣展現給使用者的效果是一樣的，同時對於京東採銷、POP商家都可以按各自的習慣去操作商品。
寫服務設計時架構師尤鳳凱充分考慮了擴充套件性、可複用性，實現了模組可配置化。基於商品介紹、擴充套件屬性、規格引數、特殊屬性等基礎元件，可靈活組配不同的業務流程。使用了京東自主研發的SAF中介軟體，其支援負載均衡、自動故障切換、流量控制、黑白名單等特性，並且在效能方面表現優異。
3).去O：去掉自營商品系統的Oracle，直接寫Sqlserver降低延遲，縮短商家釋出到展現給終端使用者的時間。
4).非同步引擎：建立下發服務系統，統一化訊息通知網站、WMS等下游系統。
最初的商品變動時，只需要通知WMS系統，
因為採購入庫時，倉庫需要核實商品資訊。隨著整個京東服務化程式的推進，搜尋、單品頁等系統都希望得到通知。因此規劃了下發服務，在商品資訊變動後，非同步通知這些系統。將商品資訊入庫後，同步寫”操作日誌”到Redis佇列，再由worker非同步從Redis中取日誌，拿到變動變更的skuSKU，組裝資訊化發MQ訊息出去。此時的訊息採取通用化設計，例如基本資訊MQ、特殊屬性MQ等。
5).儲存升級：商品主資料儲存由Sqlserver單庫，升級為MySQL叢集，並進行垂直、水平劃分,
分庫解決單庫吞吐量瓶頸，分表控制單表資料量。自主研發資料中介軟體，可以實現主庫的路由、從庫的負載均衡、故障的切換等，統一負責資料訪問，使得底層儲存規則對應用層透明。結合當前資料總量及增長率，預計3年後達到的資料量，做儲存容量規劃，並且做了Pre-Sharding方式，方便後續擴容。對於非片鍵外的查詢，使用二級路由或者搜尋服務來解決。
隨著商品及SKU數量顯著增長、TPS逐步走高。寫服務、下發服務耦合的弊端越來越突出顯現。如1-2圖中紅色線條形成的環狀所示，寫服務和下發服務是相互影響的。假設寫Redis變慢，會影響整體寫入效能；如果DB遇到瓶頸，反過來又回會影響到下發服務，回查DB變慢，下發服務處理變慢。因此寫服務經常會出現抖動，寫變慢、下發延遲。
架構3.0平臺化、精準化
2015年中開始，架構師李帥啟動3.0架構升級，其理念是解耦、簡化。架構越簡單越好，沒接觸過的人新人很快可以上手；架構也必須鬆耦合的，寫、下發、讀都可以各自做升級，相互不影響，逐步提升整體效能。
用Jingobus基於從庫日誌識別商品資訊變動，併傳送通知、重新整理redis叢集。非同步引擎訊息可配置化，商品屬性的組合對應訊息佇列。例如：搜尋關注skuSKU狀態變化，那麼只有skuSKU的上下櫃狀態變化時，才會傳送訊息，訊息體中只包含skuSKU編號及狀態。可配置化的任務引擎，新需求響應快、開發接近零成本；實現了按需傳送，給消費方減壓（例如：給wms的訊息量降低80%+）；並且寫系統解耦，整體穩定性增強。在推廣過程中，還進行跨部門技術協作，共同升級技術架構。例如網站單品頁資料異構升級專案，降低50%+介面互動，節約上百臺Docker。
商品服務作為超0級系統
，必須具有高可用性。任何影響到訂單的系統故障都必須在三分鐘內解決，有了統一切換平臺，執行預案是可以很快的。因此發現問題並警報至關重要。在研發負責人趙湘建的引領下，商品組啟動秒級監控平臺的研發。記憶體級監控資訊收集、合併、延遲秒級。並且實現了秒級監控的平臺化，可將監控能力輸出到其他系統。
期間商品讀服務也在持續進行著升級。因為skuSKU數量大（數十億）且持續增長（周增長率約105%），Redis儲存叢集規模也大。讀服務為其他眾多系統提供商品資料的查詢服務，訪問量很大，特別是在618，雙11期間，所以需要多組Redis叢集分擔流量。NIO的Redis客戶端，降低了連線數量；後續為解決多組Redis叢集流量均衡問題，對NIO版本的客戶端做了擴充套件，實現了多分片連線統一管理，使其負載均衡，並能當某一分片當機的情況下，自動從叢集中剔除，恢復後自動加入叢集中，達到故障自動轉移與恢復的目的。不僅提高了叢集整體的吞吐量，而且提升了可靠性。
同時因為商品數量增長很快，Redis叢集的規模也成倍增加，為減少資源的利用，設計三級快取功能，將最熱資料放應用記憶體中，快取時間較短；熱資料放在規模較小的Redis叢集中，全量資料放到規模較大的叢集中，這樣全量資料的Redis叢集OPS較少，可以減少部署組數，從而減少資源利用。
圖1-3 商品架構V3.0
京東商品系統在業務創新、資料智慧化、效能及穩定性提升方面，將持續努力提升，努力實踐讓技術改變生活的願景。
本文轉載自：http://www.dalbll.com/Group/Topic/ArchitecturedDesign/5121