蘇寧易購11.11：商品詳情繫統架構設計

商品詳情繫統介紹

基本介紹

商品詳情繫統是一個展現商品基本信息、參數等詳情的系統，是商品購買的入口。它是電商平臺中訪問量最大的系統之一，蘇寧易購大促期間PV量和UV量很大，這麼大的訪問量對系統的併發能力要求高。在業務上它與周邊系統的關係是高耦合。依賴商品詳情繫統的的系統特別多，好比：促銷系統、推薦系統、大聚惠、等衆多營銷系統、還有主數據系統、購物車、收藏夾等，業務複雜度高對系統設計提出更多的要求。

業務特色

1. 重點在於數據展現
2. 頁面信息豐富，如：商品詳情、商家列表、推薦、排行榜等
3. 部分數據時效要求高，如：價格、庫存等
4. 業務上依賴的系統多

商品詳情繫統三要素

1. 展現

產品上須要設計好頁面區分展現的內容

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

2. 數據處理

數據所有來源於其它系統，在數據上分爲：

基本數據，外部系統傳過來直接就可使用的數據

聚合數據，須要加工才能使用的數據

3. 服務依賴

經過MQ解耦，異構數據

解決好以上三個問題就解決了此係統核心問題。

系統邏輯架構

商品詳情繫統在設計上分紅前、中、後三層結構

1. 前臺負責展現，作爲VIEW層不處理業務邏輯，負責渲染。
2. 中臺負責業務邏輯處理，提供數據給前臺，同時還會對外部系統提供服務
3. 後臺負責主數據管理，作爲數據管理層處理商品主數據、參數、品牌、供應商等，同時部份內容開放給運營進行維護、管理和異常處理等。

前臺設計

頁面設計：

1. 動靜分離

JavaScript、CSS統一放到公共的靜態服務器上，徹底獨立的子域名，防止髒Cookie問題和動態域名中無用Cookie問題，經過文件版本號解決系統新版和舊版本之間衝突問題。

全部圖片由獨立的分佈式圖片系統管理，對原圖進行不一樣規格的無損裁減和壓縮。

2. 異步加載和懶加載

商品價格、營銷活動信息、庫存等動態數據經過異步加載

非首屏數據作懶加載處理，提升首屏加載時間，好比評價、商品詳情等內容

3. 多級緩存策略

a. 瀏覽器本地緩存

協商緩存，對於某些時效要求較高的資源經過Last-modified控制數據。作到StatusCode=304

強緩存，JS、CSS等靜態資源或者一些頁面碎片僞靜態數據經過Expires、Cache-Control(http1.1支持)設置作到強緩存，在不強制刷新的狀況下能夠作到200(from cache)

b. CDN緩存

CDN分兩條線有自營CDN和合做商的CDN，圖片、靜態資源與僞靜態數據分

別放在不到的CDN上

c. Varnish緩存

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

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

d. 精準緩存

精準緩存失效用於促銷活動準時展現的場景，基於Varnish緩存，經過精準控制緩存有效期實現緩存精準失效保證促銷活動準時切換。

組件邏輯設計：

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

後臺設計

商品數據統一處理設計

商品詳情繫統商品主數據經過MQ消息來源於外部系統，好比：商品基本信息、參數、參數模版、品牌、品類等。咱們設計時把共性抽出來分紅三部分：

1. 接受MQ消息並持久化經過Listener
2. 解析報文
3. 業務處理上簡化爲add、update、delete三個動做
4. 異常組件以觀察者模式實現，記錄處理失敗的MQ消息並對消息進行截取，並供下次再反向執行(一條MQ消息中會有一到多條參數、品牌，因此這裏用截取)

SOA服務治理

解耦分兩塊，系統交互間的解耦和商品詳情繫統組件間的解耦以及業務流程的解耦

系統間的解耦經過SOA服務治理來解決，可是因爲業務的特殊性在服務治理和性能以及一些其它因素的權衡中，咱們還選擇了一種共享Redis的方式來解決解耦

商品詳情繫統組件間解耦以及業務流程的解耦

架構演變

1.0時代中規中矩，移動端徹底移值PC的作法

咱們使用中規中矩的部署方式Varnish+Apache+JBoss。

這種架構在針對中小系統沒有什麼問題，但像商品詳情繫統這種訪問量巨大的系統會顯的有點吃力。移動端對性能的要求更高。

2.0時代PC和移動端服務分離，移動端服務合併，性能優化

a. 服務分離與服務合併

PC和移動端的服務分離，之前是同一個接口支持多端，如今是每端都有獨立的應用層服務，原子層服務共享。

移動端處理器和內存性能上的限制，採用服務的合併，且移動端用Nginx+Lua。

b. 公共服務

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

c．分佈式文件系統

商品詳情頁在回源過程當中壓力很大，基於其不可降級，咱們提出了把商品詳情頁作爲一個靜態頁放到分佈式文件系統，當DB和Redis壓力過大，直接調取分佈式文件系統中數據

3.0時代重點優化移動端性能，接口合併顆粒度更細，增長聚合服務層

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

1. 用Nginx+Lua作爲總體的接入層
2. 在Nginx接入層 加入三層緩存
3. 只有聚合信息纔會調用服務層，減小依賴關係
4. 服務層數據經過Worker推送和刷新緩存，這親服務層徹底和DB隔離
5. 移動端鏈接複用、鏈路複用、防劫持SDK開發等

商品詳情繫統數據流結構

上面介紹了商品詳情繫統前、中、後三層邏輯架構以及各層的設計方法，還介紹了部署架構演變，下面是商品詳情繫統數據流程結構的

1.0版本.

這個結構有兩個問題：

數據異構結果沒有和前端展現關聯起來，數據變動不能在前端及時展現

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

2.0版本：

把前端分紅了三部分：

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

數據異構後會以MQ形式通知基礎服務，並會刷新緩存，這種結構後前端與數據層無直接依賴。

回源方案

回源是緩存中最頭痛的問題，隨着系統業務複雜度的上升，很難從總體上把控各類業務數據在回源時給一個系統帶來的壓力，若是回源處理不端在極端狀況下會致使DB壓力瞬間上升，DB不可用或者鏈接數滿了等問題，會發生之前相似JVM GC回收時的「stop-the-world」問題。咱們回源從被動更新緩存數據更改成主動推送緩存數據從根本上解決這問題。

數據變動經過listener推送緩存至varnish

多端融合

組織架構融合

原來PC端、移動端、TV端產品、開發、測試是分中心分部門，爲真正作到多端融合，進行組織架構融合，產品、開發、測試合併到一箇中心，統一協調。合併後工做效率變高，產品質量提高，進行小團隊作戰。

展現分離邏輯融合分離

展現分離是指在結合公司業務特性、產品自身特性以及降耦合指導思想進行PC、WAP、APP端(IOS、ANDROID)、TV端的展現端進行分離處理。

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

展現層分端獨立部署

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

分佈式存儲

數據庫

1. 商品詳情繫統數據庫用Mysql，採用主從加讀寫分離結構，注意：主從不在同一個物理機上，也不在同一組路由器中。應用層中業務上對時效性要求高的數據在寫庫中操做，業務上對於時效性要求不高數據在讀庫中操做。主從結構保證在主庫出現故障好比巖機自動切換到從庫。讀庫經過LVS作負載均衡作到高可用。
2. DalClient組件支持對數據庫的分庫分表，同時支持橫向擴展。

分佈式Redis緩存

1. 應用層邏輯優先從Reids中獲取業務數據，若是Redis中沒有，再從DB中獲取。Redis採用sharding方案，每一個sharding由一個master和一個salve組成，再經過sentinel保證高可用。當master出現不故障，好比網絡跳動，sentinel會自動把salve切換爲master，這個切換是毫秒級的。master和salve經過主動和被動兩種方式來同步，作到最終一致性，符合CAP理論演變過的BASE理論。
2. 借鑑JAVA GC中對內存分代思路解決Redis緩存過時產生的驚羣現象。