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

[[286570]] 

圖片來自 Pexels

拼購砍價團平臺化轉型的戰略契機

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

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

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

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

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

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

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

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

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

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

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

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

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

砍價團平臺業務架構設計

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

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

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

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

通過實現高度的可配置與定制化，進而轉型成為為全產業提供玩法定制服務的玩法平臺。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

砍價團平臺技術架構設計

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

 

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

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

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

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

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

②前臺服務模塊：前臺服務框架層業務模塊，本模塊在業務上與前臺用戶層重合，區別在于本模塊完全由服務框架層模塊調度實現，主要負責分流一部分來自內網其他系統的訪問請求。

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

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

④中臺模塊：中臺定時任務模塊，本模塊主要負責處理來自統一調度平臺的定時任務調度請求，如過期團處理，過期訂單處理等，實現對數據層的定時維護，保持數據時效性，避免產生數據冗余。

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

 

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

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

同時由于 BGS 系統采用雙機房部署策略，因此回源請求會根據特定分撥策略被調度到兩個不同的機房。

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

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

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

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

砍價團平臺的數據層設計

 

圖 3：砍價團平臺的數據層設計

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

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

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

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

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

此外額外整庫設計也可以在中間件與分庫出現問題時承接數據庫降級操作，保證業務的持續可用性。

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

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

砍價團平臺的緩存設計

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

 

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

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

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

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

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

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

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

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

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

高可用系統的鍛造及大促保障

系統的架構設計無外乎滿足兩方面的要求：

• 盡可能滿足系統所承接的業務需求
• 盡可能提高系統的抗壓能力

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

在實現系統的高可用性層面，BGS 系統采用了以下幾種應對策略：

雙機房多活部署

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

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

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

負載層的流量調度以系統維度進行切分，不同系統可根據實際情況配置分撥策略。

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

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

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

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

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

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

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

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

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

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

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

由于單機房宕機的情況本身過于極端，而在生產環境模擬單機房宕機的風險過高，因此蘇寧開發了一套專門用于模擬單機房宕機的故障注入系統。

該系統通過短時間內封閉機器特定的出入端口來實現對機器故障的模擬。主要涉及對應用，緩存，數據庫層面的故障模擬。

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

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

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

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

高并發場景下的鏈路優化

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

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

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

對此改進思路如下：

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

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

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

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

核心鏈路拆分解耦

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

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

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

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

結語

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

當系統足夠復雜，那么決定系統整體效能的往往是結構性層面的因素，各個模塊和單元之間良好的協調關系是系統穩健運作的保證。

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

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

因此，明確自身業務需求，選擇適合的方案，才是系統設計的要義。

作者：王翔

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

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