商品詳情系統(tǒng)介紹

基本介紹

商品詳情系統(tǒng)是一個展示商品基本信息、參數(shù)等詳情的系統(tǒng)，是商品購買的入口。它是電商平臺中訪問量最大的系統(tǒng)之一，蘇寧易購大促期間PV量和UV量很大，這么大的訪問量對系統(tǒng)的并發(fā)能力要求高。在業(yè)務(wù)上它與周邊系統(tǒng)的關(guān)系是高耦合。依賴商品詳情系統(tǒng)的的系統(tǒng)特別多，比如：促銷系統(tǒng)、推薦系統(tǒng)、大聚惠、等眾多營銷系統(tǒng)、還有主數(shù)據(jù)系統(tǒng)、購物車、收藏夾等，業(yè)務(wù)復(fù)雜度高對系統(tǒng)設(shè)計提出更多的要求。

業(yè)務(wù)特點

重點在于數(shù)據(jù)展示

頁面信息豐富，如：商品詳情、商家列表、推薦、排行榜等

部分數(shù)據(jù)時效要求高，如：價格、庫存等

業(yè)務(wù)上依賴的系統(tǒng)多

商品詳情系統(tǒng)三要素

1. 展示

產(chǎn)品上需要設(shè)計好頁面區(qū)分展示的內(nèi)容

技術(shù)上主要是頁面緩存設(shè)計、前端頁面模版和JAVA程序的解耦

2. 數(shù)據(jù)處理

數(shù)據(jù)全部來源于其它系統(tǒng)，在數(shù)據(jù)上分為：

基本數(shù)據(jù)，外部系統(tǒng)傳過來直接就可以使用的數(shù)據(jù)

聚合數(shù)據(jù)，需要加工才能使用的數(shù)據(jù)

3. 服務(wù)依賴

通過MQ解耦，異構(gòu)數(shù)據(jù)

解決好以上三個問題就解決了此系統(tǒng)核心問題。

系統(tǒng)邏輯架構(gòu)

商品詳情系統(tǒng)在設(shè)計上分成前、中、后三層結(jié)構(gòu)

前臺負責展示，做為VIEW層不處理業(yè)務(wù)邏輯，負責渲染。

中臺負責業(yè)務(wù)邏輯處理，提供數(shù)據(jù)給前臺，同時還會對外部系統(tǒng)提供服務(wù)

后臺負責主數(shù)據(jù)管理，做為數(shù)據(jù)管理層處理商品主數(shù)據(jù)、參數(shù)、品牌、供應(yīng)商等，同時部分內(nèi)容開放給運營進行維護、管理和異常處理等。

前臺設(shè)計

頁面設(shè)計：

1.?動靜分離

JavaScript、CSS統(tǒng)一放到公共的靜態(tài)服務(wù)器上，完全獨立的子域名，防止臟Cookie問題和動態(tài)域名中無用Cookie問題，通過文件版本號解決系統(tǒng)新版和舊版本之間沖突問題。

所有圖片由獨立的分布式圖片系統(tǒng)管理，對原圖進行不同規(guī)格的無損裁減和壓縮。

2.?異步加載和懶加載

商品價格、營銷活動信息、庫存等動態(tài)數(shù)據(jù)通過異步加載

非首屏數(shù)據(jù)做懶加載處理，提高首屏加載時間，比如評價、商品詳情等內(nèi)容

3.?多級緩存策略

a. 瀏覽器本地緩存

協(xié)商緩存，對于某些時效要求較高的資源通過Last-modified控制數(shù)據(jù)。做到StatusCode=304

強緩存，JS、CSS等靜態(tài)資源或者一些頁面碎片偽靜態(tài)數(shù)據(jù)通過Expires、Cache-Control(http1.1支持)設(shè)置做到強緩存，在不強制刷新的情況下可以做到200(from cache)

b. CDN緩存

CDN分兩條線有自營CDN和合作商的CDN，圖片、靜態(tài)資源與偽靜態(tài)數(shù)據(jù)分

別放在不到的CDN上

c. Varnish緩存

Varnish在設(shè)計上負載使用輪詢方式，不使用URL HASH策略，用空間換時間的策略， 從而避免熱數(shù)據(jù)問題，也支持橫向擴展。

Varnish 緩存和CDN緩存在失效時間錯開，從而避免同時失效回源壓力過大。

d. 精準緩存

精準緩存失效用于促銷活動準時展示的場景，基于Varnish緩存，通過精準控制緩存有效期實現(xiàn)緩存精準失效保證促銷活動準時切換。

組件邏輯設(shè)計：

商品詳情系統(tǒng)中的購買按鈕和加入購物車會因商品不同走不同的流程。如：大聚惠商品、定金團商品、預(yù)售商品等因促銷方式不同，走不同的業(yè)務(wù)處理流程。促銷模式變化多端，可能每個月都會有變化，通常的面向接口編程和加上工廠方法或者依賴管理框架Spring也很難做到真正的解耦，雖然這樣做已經(jīng)符合開閉原則。我們通過觀察者模式很好的解決了這個問題。讓前端的頁面模版和JAVA應(yīng)用程序之間真正的解耦。

后臺設(shè)計

商品數(shù)據(jù)統(tǒng)一處理設(shè)計

商品詳情系統(tǒng)商品主數(shù)據(jù)通過MQ消息來源于外部系統(tǒng)，比如：商品基本信息、參數(shù)、參數(shù)模版、品牌、品類等。我們設(shè)計時把共性抽出來分成三部分：

接受MQ消息并持久化通過Listener

解析報文

業(yè)務(wù)處理上簡化為add、update、delete三個動作

異常組件以觀察者模式實現(xiàn)，記錄處理失敗的MQ消息并對消息進行截取，并供下次再反向執(zhí)行(一條MQ消息中會有一到多條參數(shù)、品牌，所以這里用截取)

SOA服務(wù)治理

解耦分兩塊，系統(tǒng)交互間的解耦和商品詳情系統(tǒng)組件間的解耦以及業(yè)務(wù)流程的解耦

系統(tǒng)間的解耦通過SOA服務(wù)治理來解決，但是由于業(yè)務(wù)的特殊性在服務(wù)治理和性能以及一些其它因素的權(quán)衡中，我們還選擇了一種共享Redis的方式來解決解耦

商品詳情系統(tǒng)組件間解耦以及業(yè)務(wù)流程的解耦

架構(gòu)演變

1.0時代中規(guī)中矩，移動端完全移值PC的做法

我們使用中規(guī)中矩的部署方式Varnish+Apache+JBoss。

這種架構(gòu)在針對中小系統(tǒng)沒有什么問題，但像商品詳情系統(tǒng)這種訪問量巨大的系統(tǒng)會顯的有點吃力。移動端對性能的要求更高。

2.0時代PC和移動端服務(wù)分離，移動端服務(wù)合并，性能優(yōu)化

a. 服務(wù)分離與服務(wù)合并

PC和移動端的服務(wù)分離，以前是同一個接口支持多端，現(xiàn)在是每端都有獨立的應(yīng)用層服務(wù)，原子層服務(wù)共享。

移動端處理器和內(nèi)存性能上的限制，采用服務(wù)的合并，且移動端用Nginx+Lua。

b. 公共服務(wù)

提出了一個公共服務(wù)，公共服務(wù)用來接受PC、WAP、APP公共的異步請求的服務(wù)。

c．分布式文件系統(tǒng)

商品詳情頁在回源過程中壓力很大，基于其不可降級，我們提出了把商品詳情頁做為一個靜態(tài)頁放到分布式文件系統(tǒng)，當DB和Redis壓力過大，直接調(diào)取分布式文件系統(tǒng)中數(shù)據(jù)

3.0時代重點優(yōu)化移動端性能，接口合并顆粒度更細，增加聚合服務(wù)層

多端都使用Nginx+Lua，Nginx?的異步非阻塞型事件處理機制資源消耗少，并發(fā)能力高。

用Nginx+Lua做為整體的接入層

在Nginx接入層 加入三層緩存

只有聚合信息才會調(diào)用服務(wù)層，減少依賴關(guān)系

服務(wù)層數(shù)據(jù)通過Worker推送和刷新緩存，這親服務(wù)層完全和DB隔離

移動端連接復(fù)用、鏈路復(fù)用、防劫持SDK開發(fā)等

商品詳情系統(tǒng)數(shù)據(jù)流結(jié)構(gòu)

上面介紹了商品詳情系統(tǒng)前、中、后三層邏輯架構(gòu)以及各層的設(shè)計方法，還介紹了部署架構(gòu)演變，下面是商品詳情系統(tǒng)數(shù)據(jù)流程結(jié)構(gòu)的

1.0版本.

這個結(jié)構(gòu)有兩個問題：

數(shù)據(jù)異構(gòu)結(jié)果沒有和前端展示關(guān)聯(lián)起來，數(shù)據(jù)變更不能在前端及時展示

還是沒有解決前端接口依賴問題

2.0版本：

把前端分成了三部分：

基礎(chǔ)信息組件 不需要加工的消息、聚合信息組件(需要組合消息或者計算才能提供服務(wù)的)、實時數(shù)據(jù)組件處理對外部的依賴

數(shù)據(jù)異構(gòu)后會以MQ形式通知基礎(chǔ)服務(wù)，并會刷新緩存，這種結(jié)構(gòu)后前端與數(shù)據(jù)層無直接依賴。

回源方案

回源是緩存中最頭痛的問題，隨著系統(tǒng)業(yè)務(wù)復(fù)雜度的上升，很難從整體上把控各種業(yè)務(wù)數(shù)據(jù)在回源時給一個系統(tǒng)帶來的壓力，如果回源處理不端在極端情況下會導(dǎo)致DB壓力瞬間上升，DB不可用或者連接數(shù)滿了等問題，會發(fā)生以前類似JVM GC回收時的“stop-the-world”問題。我們回源從被動更新緩存數(shù)據(jù)更改為主動推送緩存數(shù)據(jù)從根本上解決這問題。

數(shù)據(jù)變更通過listener推送緩存至varnish

多端融合

組織架構(gòu)融合

原來PC端、移動端、TV端產(chǎn)品、開發(fā)、測試是分中心分部門，為真正做到多端融合，進行組織架構(gòu)融合，產(chǎn)品、開發(fā)、測試合并到一個中心，統(tǒng)一協(xié)調(diào)。合并后工作效率變高，產(chǎn)品質(zhì)量提升，進行小團隊做戰(zhàn)。

展示分離邏輯融合分離

展示分離是指在結(jié)合公司業(yè)務(wù)特性、產(chǎn)品自身特性以及降耦合指導(dǎo)思想進行PC、WAP、APP端(IOS、ANDROID)、TV端的展示端進行分離處理。

邏輯融合分離是指在原子服務(wù)層進行融合共享，從服務(wù)單一職責原則出發(fā)在不同端分別提供獨立的服務(wù)并加上各自特性，做到接口可擴展性和服務(wù)隔離。真正做到一包部署多端使用互不影響，在業(yè)務(wù)可擴展性和可維護性上做到成本最低。

展示層分端獨立部署

在物理層為了避免多端進行資源競爭、相互干擾進行獨立部署

分布式存儲

數(shù)據(jù)庫

商品詳情系統(tǒng)數(shù)據(jù)庫用Mysql，采用主從加讀寫分離結(jié)構(gòu)，注意：主從不在同一個物理機上，也不在同一組路由器中。應(yīng)用層中業(yè)務(wù)上對時效性要求高的數(shù)據(jù)在寫庫中操作，業(yè)務(wù)上對于時效性要求不高數(shù)據(jù)在讀庫中操作。主從結(jié)構(gòu)保證在主庫出現(xiàn)故障比如巖機自動切換到從庫。讀庫通過LVS做負載均衡做到高可用。

DalClient組件支持對數(shù)據(jù)庫的分庫分表，同時支持橫向擴展。

分布式Redis緩存

應(yīng)用層邏輯優(yōu)先從Reids中獲取業(yè)務(wù)數(shù)據(jù)，如果Redis中沒有，再從DB中獲取。Redis采用sharding方案，每個sharding由一個master和一個salve組成，再通過sentinel保證高可用。當master出現(xiàn)不故障，比如網(wǎng)絡(luò)跳動，sentinel會自動把salve切換為master，這個切換是毫秒級的。master和salve通過主動和被動兩種方式來同步，做到最終一致性，符合CAP理論演變過的BASE理論。

借鑒JAVA GC中對內(nèi)存分代思路解決Redis緩存過期產(chǎn)生的驚群現(xiàn)象。

轉(zhuǎn)載于:https://www.cnblogs.com/WeiGe/p/5923105.html

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的苏宁易购11.11：商品详情系统架构设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。