【51CTO.com原創(chuàng)稿件】蘇寧拼購 808 的火爆見證了砍價團的成功，作為一種新興的購物營銷玩法，砍價團展現(xiàn)出了巨大的商業(yè)潛力。不同于傳統(tǒng)購物流程的單一模式，砍價團凝練了購物玩法和社群營銷的精髓。

[[286570]] 

圖片來自 Pexels

拼購砍價團平臺化轉型的戰(zhàn)略契機

傳統(tǒng)購物模式的劣勢在于購物體驗單一，更多的都只是選品→下單→支付的標準化流程， 另一方面則在于無法打通購物與社交的壁壘，實現(xiàn)兩者的巧妙融合。

而砍價團模式則在這兩個方向施以重彩：

• 通過分享，幫砍流程使得購物充滿趣味性和互動性，優(yōu)化用戶體驗的同時也增加了用戶粘性。
• 借助于微信龐大的用戶基數(shù)實現(xiàn)了產(chǎn)品在熟人社群中的快速傳播，達成了良好的營銷效果。

而熟人社群的傳播也有利于精準遴選出更多對標用戶，充分挖掘用戶價值，正是這兩把利刃，造就了砍價團模式的成功。

蘇寧拼購 808 的成功同時也成為了進一步摸索砍價團發(fā)展模式的契機。

當前的砍價團仍然從屬于拼購玩法，能夠參與砍價的商品也局限于蘇寧拼購的部分商品，更多的聚集在日用，快消等低成本商品，3C，家電等相對較少。

此外，砍價團玩法也可以與蘇寧 O2O 模式深度嫁接，不僅僅局限于線上商品，同時也可以將線下門店納入到砍價團版圖之中，充分發(fā)揮蘇寧的供應鏈優(yōu)勢，甚至連同置業(yè)，文創(chuàng)，乃至虛擬商品都可以和砍價團玩法深度融合。

線上與線下的齊頭并進勢必能為砍價團帶來新一輪的爆發(fā)式增長。

筆者認為，砍價團的鋪展離不開四個要素：

• 足夠有趣的玩法
• 精準的目標用戶群篩選
• 良好的社交傳播渠道
• 優(yōu)質(zhì)的商品供應鏈

一方面可以通過主站引流，微信分享的方式實現(xiàn)用戶群的拓展，另一方面砍價團也應該在選品方面進一步拓寬范圍，給予用戶更多的可選擇性。

如果僅僅局限于蘇寧拼購本身，那么除了商品范圍的局限外，也無法吸引更多的優(yōu)質(zhì)商家入駐。

因此，砍價團亟待完成從玩法到通用性平臺的戰(zhàn)略轉型，砍價團平臺化戰(zhàn)略，便由此應運而生。

砍價團平臺業(yè)務架構設計

從一種玩法到一個平臺，這種從單元到體系的躍遷背后是一種戰(zhàn)略思路的成型。

砍價團平臺本身帶有一定的商業(yè)試探性質(zhì)，一旦這種模式確定可行，便可迅速推而廣之。除了砍價團之外，也可以吸收更多的優(yōu)秀營銷玩法。

這就要求砍價團平臺應當具備通用性。既然面向蘇寧的全產(chǎn)業(yè)提供服務，那么就勢必要兼收并蓄，不僅僅是主站商品，線下門店商品，同時也要考慮置業(yè)，文創(chuàng)等產(chǎn)業(yè)模塊。

在砍價團平臺的業(yè)務設計上，要充分考慮不同類型商品的統(tǒng)一管理，同時也要為其他可能的營銷玩法預留空間，而不僅僅是局限于砍價團。

通過實現(xiàn)高度的可配置與定制化，進而轉型成為為全產(chǎn)業(yè)提供玩法定制服務的玩法平臺。

在業(yè)務架構上，砍價團平臺不能僅僅是復刻拼購原有的業(yè)務邏輯，而應當更具兼容性地做出相應業(yè)務架構改造。

比如對于團模式的設計而言，砍價團實質(zhì)上并非傳統(tǒng)的開團——參團模式，而更類似于單買模式，只不過引入了分享和幫砍流程。

因此對于老的成團模式，就需要廢棄諸如“團滿校驗”，“參團流程”等冗余邏輯，而只需要記錄幫砍人數(shù)與幫砍金額等信息即可。

而在活動設計層面，考慮到未來可能引入新的玩法，也應當在設計上具備充分的拓展性。

除了保留諸如活動編碼，活動類型，起止時間等基本信息字段之外，也需要考慮到通過預留字段，拆分基本信息表和擴展信息表等方式為新玩法的引入留下空間。

就砍價團平臺的設計初衷而言，其旨在于提供一套能夠兼容各種購物玩法的中臺式服務。

因而在玩法設計上應當提供具備通用性的接入模板，由業(yè)務方自由定制自身的玩法模式。這就需要對各種玩法所具備的共性要素進行精準抽繹，實現(xiàn)高度可配。

就前端而言，因為不同的玩法模式在用戶側展示的內(nèi)容也有所差別，前端設計就需要足夠靈活。

前端在開發(fā)過程中，應當在滿足業(yè)務功能的基礎上盡可能制定統(tǒng)一的開發(fā)標準，對于復用性較高的模塊封裝為組件，便于實現(xiàn)前端頁面的可定制化。

就服務端而言，在服務組件的設計上要對業(yè)務模塊進行細致拆分，避免業(yè)務之間的過度耦合，為新模塊的引入，新玩法的配置留下空間。

在功能層面，要盡可能實現(xiàn)業(yè)務組件的原子性，除非涉及核心業(yè)務模塊，否則不同功能之間應當盡可能解耦，便于功能的橫向拓展。

比如對于活動閥值，玩法規(guī)則等一些通用性要素，其應該盡可能避免從代碼層面去實現(xiàn)，而是通過蘇寧統(tǒng)一配置平臺加以配置。

當承接新的玩法需求時，只需要在統(tǒng)一配置平臺進行相應的配置即可，而無需進行代碼層面的改動。

百尺之臺，不可止日畢功，砍價團平臺化戰(zhàn)略只能在試探和摸索中徐徐圖之。不畏浮云遮望眼，風物長宜放眼量。試看前路，雖有坎坷，卻亦是坦途。

砍價團平臺技術架構設計

砍價團平臺的架構縱向拆分

 

圖 1：砍價團平臺架構縱向拆分

在砍價團平臺系統(tǒng)設計上，首先需要在業(yè)務層面進行邏輯解耦，砍價團平臺(Bargain System，簡稱 BGS)在業(yè)務上可以主要拆分為四大模塊，分別部署在不同的服務器集群上，不同的集群之間共享服務層的原子服務，并通過分布式遠程調(diào)用框架協(xié)同工作。

①前臺用戶模塊：前臺業(yè)務模塊，主要負責處理來自用戶的業(yè)務請求，負荷最重同時也是最為核心的業(yè)務模塊。

在硬件配置上要充分考慮本模塊的機器配置能否應對龐大的的流量載荷，同時應當著重考慮本模塊的容災能力設計。

本模塊主要處理活動，砍價玩法，物品，交易等服務，每種服務都由粒度更小的組件來實現(xiàn)，如砍價玩法下面又包含了規(guī)則，風控，金額，明細等專門業(yè)務組件。

②前臺服務模塊：前臺服務框架層業(yè)務模塊，本模塊在業(yè)務上與前臺用戶層重合，區(qū)別在于本模塊完全由服務框架層模塊調(diào)度實現(xiàn)，主要負責分流一部分來自內(nèi)網(wǎng)其他系統(tǒng)的訪問請求。

如此設計的優(yōu)勢在于能夠從流量層面對內(nèi)外網(wǎng)的訪問進行解耦，隔離部署不僅更便于精準配置機器資源，同時也能有效提高前臺模塊的抗風險能力，便于損害管控。

③后臺模塊：后臺業(yè)務模塊，本模塊主要用于運維管理人員的日常數(shù)據(jù)維護，除了對活動信息的管理外，本模塊還可以實現(xiàn)對玩法，規(guī)則等的高度可配置化，以便兼容更為豐富的購物玩法。

④中臺模塊：中臺定時任務模塊，本模塊主要負責處理來自統(tǒng)一調(diào)度平臺的定時任務調(diào)度請求，如過期團處理，過期訂單處理等，實現(xiàn)對數(shù)據(jù)層的定時維護，保持數(shù)據(jù)時效性，避免產(chǎn)生數(shù)據(jù)冗余。

砍價團平臺的架構橫向拆分

 

圖 2：砍價團平臺架構橫向拆分

①網(wǎng)絡層：為了應對來自用戶的巨大流量壓力，蘇寧在網(wǎng)絡層采取了緩存設計，來自用戶的靜態(tài)資源訪問請求一部分會由全局負載均衡器直接響應，以此減輕后端服務器的負載。

同時由于 BGS 系統(tǒng)采用雙機房部署策略，因此回源請求會根據(jù)特定分撥策略被調(diào)度到兩個不同的機房。

②負載層：對于進入后端服務器的請求，首先會由蘇寧應用防火墻進行初步甄別。

防火墻除了負責對外網(wǎng)攻擊，非法請求，垃圾請求進行攔截過濾之外，同時也負責在某些高并發(fā)場景下。

當流量超過閥值時進行流量控制，減輕后端服務器的壓力，防止服務器引流量過高而宕機。

③應用層：穿過防火墻的請求由后端負載集群進一步分發(fā)到應用服務器進行相關的業(yè)務處理和落庫操作，并響應給用戶。

砍價團平臺的數(shù)據(jù)層設計

 

圖 3：砍價團平臺的數(shù)據(jù)層設計

在數(shù)據(jù)層的設計上，考慮到 BGS 可能面對的巨大業(yè)務量，采取了數(shù)據(jù)庫分庫中間件技術。對一些業(yè)務量較大的表進行分庫分表部署，進而提高數(shù)據(jù)讀寫效率。

比如對于團信息相關表，通過特定的算法將數(shù)據(jù)均勻鋪展在多個分表中，而分表根據(jù)特定的取模算法分別部署在四個分庫中。

分庫中間件會根據(jù)訪問請求的分片字段將請求分發(fā)到相應的分庫，而無需代碼層面的額外改動。

對于不帶分片字段的請求，分庫中間件可能需要對分庫進行遍歷，從而降低查詢效率，因此 BGS 系統(tǒng)采取了額外的整庫設計。

四個分庫的數(shù)據(jù)通過數(shù)據(jù)遷移同步到單個整庫中，對于不帶分片字段或其他有特殊業(yè)務要求的查詢請求，不經(jīng)過中間件直接調(diào)度到整庫，從而提高查詢效率。

此外額外整庫設計也可以在中間件與分庫出現(xiàn)問題時承接數(shù)據(jù)庫降級操作，保證業(yè)務的持續(xù)可用性。

由于數(shù)據(jù)遷移存在一定的同步延時，因此整庫更適合處理對時效性要求較低的查詢請求，對于寫庫請求和高時效性查詢請求，則需要對業(yè)務進行進一步的評估。

此外， 中間件+數(shù)據(jù)庫的設計也更加易于后期數(shù)據(jù)庫的橫向擴展，避免系統(tǒng)因為數(shù)據(jù)層的瓶頸而限制整個系統(tǒng)的并發(fā)處理能力。

砍價團平臺的緩存設計

由于 BGS 系統(tǒng)可能面臨的高并發(fā)情況，因此在數(shù)據(jù)層面除了中間件+數(shù)據(jù)庫的設計之外，同時采用了 Redis 緩存來預處理一部分讀寫請求，減少對數(shù)據(jù)庫的訪問。

 

圖 4：砍價團平臺緩存設計

以庫存扣減場景為例，對于一些熱銷商品，或者活動搶購商品，可能會在短時間內(nèi)面臨極高的并發(fā)壓力。

因此有必要設計預操作步驟，一方面緩沖到數(shù)據(jù)庫的直接壓力，另一方面保證緩存與 DB 的數(shù)據(jù)一致性。

當用戶下單或支付成功后，優(yōu)先操作 Redis 中的數(shù)據(jù)。Redis 中的數(shù)據(jù)定時同步給 DB，同步周期可以根據(jù)業(yè)務需求進行配置。

對 DB 和 Redis 的操作放置在分布式一致性框架中，當某一步驟失敗時進行回滾，避免數(shù)據(jù)不一致的情況出現(xiàn)。

同時 Redis 和 Sentinel 組成高可用集群，在某臺 Redis 宕機時自動實現(xiàn)主從切換，保證緩存服務的高可用性，防止大量緩存穿透引發(fā)數(shù)據(jù)庫雪崩效應。

但是這種設計有一種特殊的場景需要加以考慮，那就是在涉及諸如搶購，秒殺等高并發(fā)場景時，對于 Redis 中一些時效性較高的數(shù)據(jù)(如庫存)，如果其過期時間較短，可能存在過期之前最后一個同步周期內(nèi)的數(shù)據(jù)在沒有同步到數(shù)據(jù)庫之前就失效的情況，進而造成部分數(shù)據(jù)緩存和 DB 不一致，引發(fā)活動超賣。

對于這種特殊場景存在兩種技術解決方案：

• 縮短數(shù)據(jù)同步周期，減少數(shù)據(jù)不一致狀況的發(fā)生，但是這種方案會使得數(shù)據(jù)庫壓力增大，同時也無法完全解決數(shù)據(jù)不一致的情況。
• 預先設置足夠的緩存失效時間，杜絕在活動有效期內(nèi)數(shù)據(jù)失效，雖然這種方案會增大對 Redis 空間的占用，但是在技術層面風險更小，更適合應對風險較高的場景。

高可用系統(tǒng)的鍛造及大促保障

系統(tǒng)的架構設計無外乎滿足兩方面的要求：

• 盡可能滿足系統(tǒng)所承接的業(yè)務需求
• 盡可能提高系統(tǒng)的抗壓能力

砍價團平臺作為核心系統(tǒng)之一，良好的抗壓能力是必不可少的，這就為 BGS 系統(tǒng)在整體設計層面提出了更高的要求。

在實現(xiàn)系統(tǒng)的高可用性層面，BGS 系統(tǒng)采用了以下幾種應對策略：

雙機房多活部署

對于業(yè)務價值較高的系統(tǒng)，多活部署幾乎是一個必然的選擇。BGS 系統(tǒng)采用雙機房部署策略，對用戶請求進行分流，規(guī)避單點部署策略在意外因素下宕機的風險，保證業(yè)務的持續(xù)可用性。

在網(wǎng)絡層，由全局負載均衡器對用戶請求按一定的分片規(guī)則進行劃撥，調(diào)度到 A，B 兩個機房;在負載層，會根據(jù)相應的分撥策略對流量進行二次劃撥。

當網(wǎng)絡層與負載層的流量切分策略一致時，則不會進行額外的流量劃撥;當不一致時，負載層會進行補償性的流量二次撥分，最終實際的流量調(diào)撥情況將遵循負載層的撥分策略。

負載層的流量調(diào)度以系統(tǒng)維度進行切分，不同系統(tǒng)可根據(jù)實際情況配置分撥策略。

除了對流量進行補償，負載層還可以承擔在網(wǎng)絡層調(diào)撥策略失效后的替代性方案，保證不會因為網(wǎng)絡層面的調(diào)撥失效而導致單機房負載壓力過大。

在應用層，對于系統(tǒng)之間的調(diào)用請求，則集中在主機房進行處理。除此之外，鑒于數(shù)據(jù)層面的強一致性要求，系統(tǒng)間調(diào)用可以進行接口級別的策略控制，來對一些寫操作進行單機房調(diào)度，確保數(shù)據(jù)的單機房寫庫。

在數(shù)據(jù)層面，為了保證數(shù)據(jù)的強一致性，采用競爭型策略，以保證主備庫數(shù)據(jù)一致性。

主庫寫入的數(shù)據(jù)會同步遷移到備庫進行溫備，以確保主機房宕機時仍可切換到備機房數(shù)據(jù)庫，保證業(yè)務的可用性。

單機房宕機情況下的降級方案

當發(fā)生單機房故障時(以主機房宕機為例)：

• 在網(wǎng)絡層面，由全局負載均衡器統(tǒng)一控制將所有回源請求分撥到備機房。
• 在負載層面，對主機房的請求進行補償性調(diào)度，撥分到備機房。確保沒有請求訪問主機房。
• 在應用層面，將分布式統(tǒng)一服務框架以及數(shù)據(jù)隊列等系統(tǒng)間的調(diào)用接口調(diào)撥到備機房處理。
• 在數(shù)據(jù)層面，通過切換數(shù)據(jù)庫中間件將數(shù)據(jù)讀寫操作調(diào)度到備機房。

而對于備機房宕機的情況，只需要完成網(wǎng)絡層和負載層的流量切換即可，毋需應用層和數(shù)據(jù)層的操作。

單機房宕機情況下降級的擬真演練

系統(tǒng)架構設計雖然側重于對系統(tǒng)結構層面的把握，但是同樣不可忽視技術性細節(jié)和具體的實踐操作。

看似完美的設計方案在實際的生產(chǎn)操作中總是會面臨各種考驗，某些細節(jié)上的齟齬往往會釀成意想不到的后果。因此，再完美的設計方案也必須經(jīng)過實戰(zhàn)的檢驗。

由于單機房宕機的情況本身過于極端，而在生產(chǎn)環(huán)境模擬單機房宕機的風險過高，因此蘇寧開發(fā)了一套專門用于模擬單機房宕機的故障注入系統(tǒng)。

該系統(tǒng)通過短時間內(nèi)封閉機器特定的出入端口來實現(xiàn)對機器故障的模擬。主要涉及對應用，緩存，數(shù)據(jù)庫層面的故障模擬。

故障系統(tǒng)本身具有高度可配置性，用戶可以根據(jù)所需要模擬的場景配置不同的故障注入任務。

每個故障注入任務都有默認的自愈時間，當超過自愈時間后會自動恢復端口狀態(tài)，防止模擬故障時間過長引發(fā)事故。

對單機房宕機場景的模擬可以大致分為應用層宕機，緩存單庫宕機，緩存集群宕機，數(shù)據(jù)庫單庫宕機，數(shù)據(jù)庫集群宕機，單系統(tǒng)完全宕機等六個場景，基本可以覆蓋單機房宕機的所有情形。

在混沌系統(tǒng)的加持下，就可以對系統(tǒng)多活降級方案進行全覆蓋測試，從而保證多活降級策略在生產(chǎn)場景下的可用性。

高并發(fā)場景下的鏈路優(yōu)化

對于涉及高并發(fā)場景的系統(tǒng)而言，多活部署僅僅是一種應對極端情況的兜底策略，而單純的橫向擴容也難免會因為邊際遞減效應的收束而無法滿足業(yè)務需求。

當結構層面的優(yōu)化無法進一步提升系統(tǒng)效能的時候，就需要深入到業(yè)務流程中進行鏈路級別的優(yōu)化。

以砍價團下單支付流程為例，本鏈路涉及到和多個中臺系統(tǒng)的信息交互，鏈路較為冗長，在高并發(fā)場景下可能拖累系統(tǒng)效能。

對此改進思路如下：

• 對于下單支付的前置校驗操作，如下單資格，庫存等，在并發(fā)量很高的情況下配置降級，在用戶下單前取消資格校驗操作。
• 在生成訂單鏈路中，涉及到和中臺的交互，采取異步化處理的方式，中臺處理完畢后將結果反饋給砍價團平臺系統(tǒng)即可，進而減少用戶的等待時間。

而相應的這一改造思路也可以移植到一些對時效性要求較低的場景中。

如果系統(tǒng)本身只在特定的時間點面臨高并發(fā)場景，那么可以選擇專門開辟一個高并發(fā)代碼分支，在面臨大促，節(jié)日活動時用高并發(fā)分支取代常規(guī)分支即可。

這樣可以避免因為不定期的各種活動而頻繁對代碼進行改造，進而減輕了代碼層面的業(yè)務風險。

核心鏈路拆分解耦

鏈路級別的優(yōu)化除了代碼層面的異步化改造外，也可以對核心鏈路進行分流，將不同的鏈路流量引流到不同的集群上，拆分系統(tǒng)壓力。

比如對于展示與購物鏈路，其所面臨的流量壓力存在顯著差別，展示鏈路 TPS 要遠高于購物鏈路 TPS。

因此在架構設計上，可以分別將代碼部署在兩個集群上，通過不同的域名對展示鏈路和購物鏈路進行分流。

同時對于域名配置降級開關，如果支付鏈路集群故障，可以通過修改配置將支付鏈路的流量回流到展示鏈路進行處理，從而進一步提高系統(tǒng)的容災能力。

結語

筆者以為，對于承載復雜業(yè)務的系統(tǒng)而言，其受木桶效應的影響尤甚，因此要盡量平衡系統(tǒng)的各個要素，不可偏廢。

當系統(tǒng)足夠復雜，那么決定系統(tǒng)整體效能的往往是結構性層面的因素，各個模塊和單元之間良好的協(xié)調(diào)關系是系統(tǒng)穩(wěn)健運作的保證。

而系統(tǒng)的設計也應該以滿足自身業(yè)務為第一要義，盡可能精簡一些不必要部分。

雖然理論上龐大的系統(tǒng)集群具有更強的容災能力，但是過高的維護成本也會成為系統(tǒng)的拖累。

因此，明確自身業(yè)務需求，選擇適合的方案，才是系統(tǒng)設計的要義。

作者：王翔

簡介：蘇寧科技集團消費者平臺研發(fā)中心開發(fā)部工程師，畢業(yè)于安徽大學電子信息工程專業(yè)，目前致力于蘇寧拼購服務端開發(fā)，架構設計優(yōu)化工作，主要負責拼購系統(tǒng)多活方案設計及搭建，拼購系統(tǒng)架構拆分及優(yōu)化設計，服務端系統(tǒng)開發(fā)等工作。

【51CTO原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為51CTO.com】