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

来源:https://www.cnblogs.com/88223100/archive/2023/01/26/JD-Dada-core-system-architecture_from-simple-to-systematic-design-essence.html
-Advertisement-
Play Games

商品系統是電商系統最基礎、最核心的系統之一。商品數據遍佈所有業務,首頁、門店頁、購物車、訂單、結算、售後、庫存、價格等,都離不開商品。商品信息要穩定提供至到家供應鏈的每個節點,所以必須要有一套穩定的、高性能的商品服務體系支撐。 隨著京東到家商品業務的快速發展,業務從單一轉變為多元化,系統功能設... ...


 

前言

 

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

 

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

 

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

 

一、到家商品架構初始模型1.0

合適、簡單原則設計思想

 

1、商品系統雛形

 

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

 

圖片

 

 

2、遇到的問題

 

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

 

  • 線上B/C端業務耦合在一起,導致線上讀/寫業務相互影響,特別是大促期間大量修改商品導致C端服務不穩定,只能通過不斷橫向擴容來提高穩定性,繼而導致了嚴重的資源浪費;

  • 服務端性能波動較大;

  • 簡易的緩存架構,在高併發下Redis緩存擊穿問題;

  • 監控不全面,無法及時預警;

 

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

 

二、到家商品架構-2.0

高可用、高性能架構模式演進

 

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

 

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

 

  • AP原則 + 最終一致性思路

  • B/C服務分離

  • 異地多活、雙機架構

  • Sentinel限流

  • 監控平臺

 

1、高可用演進

 

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

 

為了提高商品C端讀服務的高可用,採用了AP原則 + 最終一致性的設計思路,引入了分散式緩存Redis集群提高讀服務可用性,並通過非同步消息保證數據的最終一致性。

 

AP原則貼合商品系統C端服務的業務場景,比如:因為網路延遲等問題,資料庫沒有及時同步數據至Redis緩存,導致當前讀取的商品數據和資料庫的數據不一致,這種短暫的不一致,在業務上是可以接受的。

 

引入分散式Redis集群後,商品C端讀服務能力不僅提高了可用性,而且在性能上表現也非常出色。

 

圖片

 

 

2)B/C服務分離

 

商家會通過對接開放平臺介面,定期修改商品的信息、圖片等屬性。例如:我們在一次大促中遇到商家集中修改商品信息,結果寫服務占用了大量的系統資源,導致了讀服務可用受損。

 

為了提高商品服務B/C端各自的可用性,獨立部署了B/C端服務,分別對外提供服務。B/C服務拆分後,商品系統在後續的各種大促中,B/C服務各自表現平穩,極大提升了商品服務的可用性。商家後續寫操作,商品系統再也沒有出現過讀服務受損的情況。

 

圖片

 

 

3)異地多活、雙機架構

 

①異地多活

 

到家商品服務docker所在的物理機機房,採用了異地多活的方式進行部署,機房分佈在多個不同地區,遵循“雞蛋不要放在一個籃子里”原則。在一個機房出現問題的時候,還有另外兩個機房提供服務,極大提高了商品系統應對黑天鵝事件的處理的可伸縮性。

 

圖片

 

 

②雙機架構

 

作為商品核心讀服務的支撐中間件Redis集群,使用了主-從模式, 並且主分片和從分片分屬不同的機房,在主分片異常的時候主從自動切換。

 

Mongodb採用了1主2備的方式進行數據備份,主庫異常可通過功能變數名稱快速切換主備節點,整個切換過程平滑無感知。

 

圖片

 

 

4)Sentinel限流

 

商品讀服務引入了Sentinel流控組件,可以通過Zookeeper根據調用源實時配置不同的流控策略,在極端流量出現後,可以對非核心的調用源進行限流、熔斷,為線上擴容爭取足夠的時間,避免了突如其來的異常流量導致商品整體服務不可用,提升了商品讀服務的可用性。

 

商品服務通過配置方法名以及調用來源,對邊緣業務調用、方法進行定向限流。在極限情況下,通過犧牲邊緣業務的可用,起到保障核心方法的高可用的目的。

 

圖片

 

 

5)監控平臺

 

商品服務採用了京東的監控報警平臺。商品介面API,可以通過UMP監控不同時間段性能分佈,實時統計TP99、TP999、AVG、MAX等維度指標。可以監控伺服器docker的系統、網路、磁碟、容器等指標,並且通過設定報警閾值實時通知指定負責人。

 

圖片

 

 

圖片

 

 

2、高性能演進

 

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

 

例如:在促銷期間,高併發的場景下經常會因為降級查詢性能損耗->響應線程等待->線程池等待隊列打滿->拒絕策略,繼而引發商品的整體服務性能變慢。

 

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

 

  • C端查詢去MongoDb依賴

  • Redis持久化緩存

  • 數據非同步處理服務

  • 記憶體緩存ehcache

 

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

商品體系領域建設

 

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

 

例如:商家在建品後,由於操作不當,維護錯了商品的信息,導致了異常品類商品數據產生,需要想辦法實時監控、處理數據。

 

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

 

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

 

1、業務複雜度提升帶來的問題

 

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

 

  • 系統錯誤隔離性差,可用性差,任何一個模塊的錯誤可能導致整個系統的宕機;

  • 可伸縮性差,擴容只能對整個應用擴容,無法做到對整個功能點進行擴容;

  • 所有的服務共用一套體系,某個方法的流量穿透會導致所有的服務不可用;

 

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

 

2、商品體系建設

 

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

 

  • 標庫系統

 

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

 

  • 拓品系統

 

通過大數據分析,根據商家類型、經營範圍等 補充、提供商家缺失的商品清單,協助商家進行拓寬商品。

 

  • 治理系統

 

根據到家商品規則,治理商品的各項基本信息,規範正確數據,制定商品規範。

 

  • 限購系統

 

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

 

  • 屬性系統

 

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

 

圖片

 

 

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

 

商品系統拆分主要面臨以下幾個問題:從哪開始入手拆分?數據按照什麼維度拆分?服務按照什麼維度拆分?怎麼保障拆分中的系統穩定?

 

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

 

  • 自上而下邏輯分層

  • 自下而上方法分解

  • 業務領域拆分

  • Redis緩存拆分

 

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階段應對業務系統體系建設。每一個階段儘量使用合適、簡單的設計,防止過度設計產生更多的複雜度問題。

 

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

 

作者丨孫岩

本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/JD-Dada-core-system-architecture_from-simple-to-systematic-design-essence.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 前言 Proteus 新建工程雖然不難,但對於電子小白來說可能便成了學習路上的絆腳石,本篇我將逐步講解如何在 Proteus 中新建工程。 最新版 Proteus 8.15 最新版 Proteus 8.15 現已發佈,我為此編寫了詳細的圖文安裝教程並配有安裝包,需要安裝的朋友請跳轉進行安裝。 Pro ...
  • 前言 Proteus 是世界上唯一將電路模擬軟體、PCB設計軟體和虛擬模型模擬軟體三合一的設計平臺。 Proteus 8.15 現已發佈,本篇將帶領大家安裝此版本。 介紹 Proteus Proteus 軟體是英國 Lab Center Electronics 公司出版的 EDA 工具軟體。它不僅具 ...
  • 一道貪心演算法不是很明顯的題目,其實一般的遞推也可以做。 大體思路:肯定優先購買單價最低的奶農的牛奶,那麼就需要先根據牛奶單價進行排序,這裡用結構體會更好一點。之後在從前往後一個一個枚舉,直至購買的牛奶數量達到要求即可。 話不多說,上代碼: 1 #include<bits/stdc++.h> 2 us ...
  • 2023-01-24 一、NoSQL資料庫 1、NoSQL資料庫的簡介 NoSQL(NoSQL=Not Only SQL),即“不僅僅是SQL”,泛指非關係型的資料庫。NosQL不依賴業務邏輯方式存儲,而以簡單的key-value模式存儲。因此大大的增加了資料庫的擴展能力。 (1)不遵循SQL標準 ...
  • 前言 最近群里遇到獲取Route名為空的問題,當時沒在意。。。 直到自己在監控頁面啟動耗時,需要確定當前頁面是哪個從而方便標記它載入的耗時時,遇到同樣 route.settings.name 為空問題,模擬場景如下: 在 main.dart 頁面中點擊 + 按鈕跳轉到 TestPage2 頁面。 M ...
  • Lspatch的使用。xp模塊可以使用戶獲得應用原本所沒有的功能。使用模塊需要修改應用。Lspatch實現了無需Root修改應用。 ...
  • 前端面試題學習-HTML-個人總結 這是看別人總結的基礎上再度總結的,總結的鏈接如下 鏈接 1. DOCTYPE 的作用? 告知瀏覽器解析器用何標準解析文檔,若不指定則按相容模式進行解析(向後相容模擬老瀏覽器)。 IE5.5 引入的概念。 HTML5 之後無需指定,因為在之前的都是基於 SGML 的 ...
  • JavaScript 中有兩種類型轉換:隱式類型轉換和顯式類型轉換。 隱式類型轉換指 JavaScript 在運行時自動將一種類型轉換為另一種類型。例如,在數學運算中,JavaScript 會將字元串轉換為數字。 顯式類型轉換指在代碼中使用內置函數或全局對象將一種類型顯式地轉換為另一種類型。例如,使 ...
一周排行
    -Advertisement-
    Play Games
  • 下麵是一個標準的IDistributedCache用例: public class SomeService(IDistributedCache cache) { public async Task<SomeInformation> GetSomeInformationAsync (string na ...
  • 這個庫提供了在啟動期間實例化已註冊的單例,而不是在首次使用它時實例化。 單例通常在首次使用時創建,這可能會導致響應傳入請求的延遲高於平時。在註冊時創建實例有助於防止第一次Request請求的SLA 以往我們要在註冊的時候實例單例可能會這樣寫: //註冊: services.AddSingleton< ...
  • 最近公司的很多項目都要改單點登錄了,不過大部分都還沒敲定,目前立刻要做的就只有一個比較老的項目 先改一個試試手,主要目標就是最短最快實現功能 首先因為要保留原登錄方式,所以頁面上的改動就是在原來登錄頁面下加一個SSO登錄入口 用超鏈接寫的入口,頁面改造後如下圖: 其中超鏈接的 href="Staff ...
  • Like運算符很好用,特別是它所提供的其中*、?這兩種通配符,在Windows文件系統和各類項目中運用非常廣泛。 但Like運算符僅在VB中支持,在C#中,如何實現呢? 以下是關於LikeString的四種實現方式,其中第四種為Regex正則表達式實現,且在.NET Standard 2.0及以上平... ...
  • 一:背景 1. 講故事 前些天有位朋友找到我,說他們的程式記憶體會偶發性暴漲,自己分析了下是非托管記憶體問題,讓我幫忙看下怎麼回事?哈哈,看到這個dump我還是非常有興趣的,居然還有這種游戲幣自助機類型的程式,下次去大玩家看看他們出幣的機器後端是不是C#寫的?由於dump是linux上的程式,剛好win ...
  • 前言 大家好,我是老馬。很高興遇到你。 我們為 java 開發者實現了 java 版本的 nginx https://github.com/houbb/nginx4j 如果你想知道 servlet 如何處理的,可以參考我的另一個項目: 手寫從零實現簡易版 tomcat minicat 手寫 ngin ...
  • 上一次的介紹,主要圍繞如何統一去捕獲異常,以及為每一種異常添加自己的Mapper實現,並且我們知道,當在ExceptionMapper中返回非200的Response,不支持application/json的響應類型,而是寫死的text/plain類型。 Filter為二方包異常手動捕獲 參考:ht ...
  • 大家好,我是R哥。 今天分享一個爽飛了的面試輔導 case: 這個杭州兄弟空窗期 1 個月+,面試了 6 家公司 0 Offer,不知道問題出在哪,難道是杭州的 IT 崩盤了麽? 報名面試輔導後,經過一個多月的輔導打磨,現在成功入職某上市公司,漲薪 30%+,955 工作制,不咋加班,還不捲。 其他 ...
  • 引入依賴 <!--Freemarker wls--> <dependency> <groupId>org.freemarker</groupId> <artifactId>freemarker</artifactId> <version>2.3.30</version> </dependency> ...
  • 你應如何運行程式 互動式命令模式 開始一個互動式會話 一般是在操作系統命令行下輸入python,且不帶任何參數 系統路徑 如果沒有設置系統的PATH環境變數來包括Python的安裝路徑,可能需要機器上Python可執行文件的完整路徑來代替python 運行的位置:代碼位置 不要輸入的內容:提示符和註 ...