2019年京東到家優惠券系統的挑戰及演進.pdf

《2019年京東到家優惠券系統的挑戰及演進.pdf》由會員分享，可在線閱讀，更多相關《2019年京東到家優惠券系統的挑戰及演進.pdf（44頁珍藏版）》請在三個皮匠報告上搜索。

1、京東到家優惠券系統的挑戰及演進目錄1.優惠券業務體系介紹2.優惠券系統的架構演進3.系統重構升級的經驗總結優惠券業務體系介紹促銷的種類是多種多樣的，常見的有：單品促銷（秒殺，直降，第2件n折，買贈等）訂單促銷（滿減，滿折，階梯滿減/滿折，捆綁等）還有今天我們重點介紹的優惠券促銷。優惠券促銷與單品促銷和訂單促銷有什么優勢呢？首先，容易傳播；其次，玩法多變；最后，方便精細化運營；關于容易傳播，這得從大家日常獲取信息的渠道說起，短信/網絡/多媒體等，大家獲取促銷信息的大多也是基于這幾種渠道。短信定向發券非常適合用戶的拉新和留存；關于玩法多變，下單返券，游戲發券，各種裂變（砍價券，分享有禮）等等，稍后

2、還會詳細介紹。關于運營管理，補貼預算可控制，訂單轉化率可預估可量化，可以實現精細化運營；一個快速發展的企業，在業務步入穩定期后，大部分服務迭代的頻次會越來越低，但營銷相關的系統感知到這一點應該是最晚的，產品差異化不大的前提下，營銷可能就是制勝的關鍵，甚至成為核心競爭力。優惠券促銷貫穿整個訂單履約過程，首頁的活動樓層，大牌福利，門店主頁促銷信息，購物車領券，下單后的分享領券，訂單完成后的下單返禮等。優惠券業務體系介紹優惠券業務體系介紹優惠券業務體系介紹優惠券業務體系介紹優惠券系統的架構演進V1.0優惠券系統的架構演進-V1.0V1.0初創典型的分布式服務架構，基本滿足了初期的效率優先,快速響應的

3、業務需求。優惠券系統的架構演進-V1.0V1.0初創面臨的挑戰V1.0初創技術的演進已經趕不上業務的迭代速度了,系統在負重前行,舉幾個典型的場景:1.優惠券結構定義不統一,前期優惠券是沒有抽象的獨立存在,大都是單張的領取和使用,但隨著業務的需求發展我們需要發券包,這就促使我們再優惠券之上,做了活動的抽象.既可以領活動券包也可以領單張券,但老的活動類型可能就不會遵循新的結構,這對后續的優惠券管理帶來了挑戰.(考慮兩套流程)2.不同的活動類型都有一套自己的管理流程,核心流程沒有復用，如果要在創建優惠券時需要接入預算池這樣的需求，就需要修改所有活動類型的創建過程.(領券和用券也存在此類煙囪問題)3.

4、優惠券的領券規則和使用規則是揉在一起的,系統學習成本和復雜度非常高;另外規則的存儲設計是每一種規則都是獨立的表;而優惠券的規則又是易變的,這就導致了規則變更,就需要從底層的數據結構到應用流程都需要修改調整(豎煙囪),嚴重的影響了業務的產出效率和系統層面的穩定性;面臨的挑戰可用性高并發可擴展性效率優先快速響應V1.0初創投入產出比下滑系統無法支撐新的業務bug率上升單點和性能瓶頸頻現面臨的挑戰數據結構和代碼腐壞 底層數據結構定義混亂;業務模塊的可重用性、移植性變差,例如領券服務存在多組實現(新人領券,商城領券等);典型的樹煙囪型的模式來支撐業務;數據庫成為瓶頸 有效性校驗,發券,用券,查券等業務

5、共享服務和數據庫資源,任何一方有抖動都會影響其它業務,比如發券高峰期可能會影響用券功能,典型場景是定向推送發券效率快了,可能會引起數據庫負載增高,影響依賴數據庫操作的其它功能,發券效率慢了,又不能在規定的時間內將券發送到用戶賬戶的矛盾;需求阻塞 設計上的不規范和技術在老系統上負重前行,外加新的更復雜的玩法規則迭代,產研測的產出比降低;商家和運營端管理優惠券在檢索和統計上的部分需求難以支撐;比如模糊搜索,用券統計等;V1.0初創優惠券系統的架構演進V2.0優惠券系統的架構演進-V2.0V2.0迭代拆分 服務 模塊 存儲合并 流程 結構解耦 重構 消息 任務冗余 服務 數據容錯 冗余 限流 重試

6、降級 隔離 回滾方法論業務隔離+流程拆分+并行|異步+服務冪等+異常重試優惠券系統的架構演進-V2.0V2.0迭代v2.0基于業務隔離+流程拆分+并行/異步，結合服務冪等行設計和異常重試機制來解決功能耦合，單點瓶頸和性能等問題。拆分服務:按照用戶:B端/C端按照職責:查詢/檢索統計(es)按照流程:同步-異步(worker)拆分模塊:定向推送從普通領券中拆分出來/領券規則和用券規則拆分拆分存儲:數據庫分庫,數據表分表流程合并:底層統一券展示/券領取/券使用等流程實現；結構合并:比如易變的新玩法,限制規則使用統一的數據結構進行落地而非新增表或字段解決;重構解耦:模塊功能拆分,使其單一;復雜易變得

7、場景,優化設計模式;消息解耦:核心節點使用消息進行異步處理,比如領券/用券任務解耦:券到賬消息提醒/用戶券過期狀態變更/券過期狀態變更/冗余數據計算等服務冗余:多分組跨機房進行服務部署數據冗余:按照業務場景冗余數據冗余:容錯的前提很大部分取決于服務和數據的冗余;限流:分布式鎖,防止并發;方法上有限流;重試:領券/用券通過消息的重試機制落地,worker本身就支持重試機制降級:數據庫/緩存/es數據互備隔離:宏觀上,服務/存儲.微觀上,開關/熔斷回滾:領券資格/用券失敗優惠券系統的架構演進-V2.0V2.0迭代優惠券系統的架構演進-V2.0V2.0迭代優惠券系統的架構演進-V2.0V2.0迭代優

8、惠券系統的架構演進-V2.0V2.0迭代優惠券系統的架構演進-V2.0V2.0迭代面臨的挑戰可維護性需求并行策略易變效率優先快速響應V2.0迭代營銷策略多變業務需求排隊團隊人手不夠需求排期沖突面臨的挑戰加人不是萬能的 一個版本的迭代周期內需求越多,溝通,協調的成本越大,相應不可控的因素越多,失敗風險就越大;向進度落后的項目中添加人手,只會使進度更加落后;不是所有需求都可以并行 有時候需求實現是有重疊的,并行也是有限度的;打個比方,蓋一棟樓的周期大約100天,如果提供50倍的人力,是沒有辦法在2天內完工的.腐壞的代碼誰來清理 隨著需求迭代次數的增多,廢棄或重合的代碼,將越積越多,這與前期投入的人

9、和迭代次數成比例的,優化與人,需求的矛盾凸顯;V2.0演進面臨挑戰優惠券系統的架構演進V3.0優惠券系統的架構演進-V3.0V3.0演進方法論-對外賦能基于微服務組件化，對外賦能的思想，對系統進行重組。即按照優惠券功能職責進行橫向拆分:優惠券基礎服務+營銷策略服務同時基于業務,對優惠券管理和應用服務進行更細粒度的垂直拆分;面臨的挑戰及架構演進-V3.0V3.0演進新增核心層的優惠券基礎組件服務,以及應用層新抽象出來的營銷策略服務營銷索引服務用來解決券購,以及基于商品查找優惠券等需求;V3.0演進面臨的挑戰及架構演進-V3.0基礎服務營銷策略產品運營業務方系統基礎服務(組件化服務):提供最基礎的

10、服務能力.比如:優惠券管理/打標/領券/用券/查券等;其核心是只維護優惠券的通用限制規則(領券/用券);營銷策略:將優惠券玩法規則進行系統層面的剝離和拆分,以組件化服務為基礎,構建獨立的符合各自場景下的營銷規則.比如:游戲獎勵券,小程序-砍價券,開通會員送券,下單返券等;其核心是維護發券策略和領取規則(非通用限制規則);業務方系統:有自己的開發團隊,想讓自己的業務形成閉環,可以直接依賴優惠券提供的組件化服務實現自己的優惠券運營邏輯;產品和運營:重心由面向規則/流量向產品/運營傾斜;優惠券系統的架構演進-V3.0V3.0演進下單返禮廣告砍價地推游戲定向推送分享有禮V+會員營銷策略業務方A業務方B

11、目前營銷策略服務邏輯實現上有兩部分:一部分是優惠券團隊維護的相對通用的營銷玩法的實現,比如:定向推送,優惠碼換券等,或者沒有明確業務方的玩法,比如:游戲發券,廣告發券等.一部分是由擁有開發能力且業務層面想形成閉環的業務方來實現,比如:小程序團隊的砍價券,留存團隊的下單返禮和V+會員券,增長團隊的地推券和分享有禮等;優惠券系統的架構演進-V3.0V3.0演進系統重構升級的經驗總結服務高可用面臨的挑戰-系統要求伸縮性擴展性可用性高并發安全性可維護性容災性可維護性系統要求面臨的挑戰-高可用高可用優化存儲網絡服務器網絡在規定的時間內獲得正確的響應結果.存儲2網絡1服務器1網絡1存儲1網絡2服務器2網絡

12、2策略 冗余(宏觀)隔離(微觀)分類 存儲 服務器 網絡方向 高性能 高吞吐服務 監控 預警 限流 熔斷 降級優惠券領券高可用實踐99.999%(5個9)一年故障不超過5分鐘99.99%(4個9)一年故障不超過53分鐘99.9%(3個9)一年故障不超過8小時46分鐘99%(2個9)一年故障不超過3.65天面臨的挑戰-高性能高性能優化小數據:拆分/冗余/轉換/算法/壓縮少IO:RPC/長連接/讀文件短流程:緩存/異步/并行/快速失敗縮減計算:結構化/有序/解壓/代碼優化數據結構:索引/布隆過濾器面臨的挑戰-緩存實踐面臨的挑戰-業務示例面臨的挑戰-高吞吐高吞吐優化在單位時間內提供的產量（或服務量）

13、.公式:QPS（TPS）=并發數/平均響應時間高性能響應時間 參照高性能并發數 服務開啟合適線程數 保持無狀態,可擴展 建立合適的連接數(數據庫,TCP)適當使用線程池 無單點瓶頸 快速失敗系統重構升級的經驗總結優惠券重構升級重構指引數據結構重構全量同步表新增表合并表拆分表調整增量同步程序自檢服務雙寫DataBusCanalTable:60老數據庫Table:30新數據庫服務升級過程結果驗證:流量復制/切換開關配置異步線程策略模式切面攔截程序自檢異常監控灰度上線重構升級遇到的坑-控制風險問題舉例減少人員流動中間臨時借調或轉走:會打亂項目節奏,嚴重影響工期和質量;避免能力不足實現延期或評審不通過

14、,成為流程阻塞點.嚴重時需要有人重寫;切記周期太長周期長,不可控因素就會增多.質量保障和管理難度系數增大;保證及時反饋團隊內要有固定的進度和風險反饋機制;別在錯誤的道路上越走也遠;注意分工協作分工上主要根據能力來定,重構不是試驗場;明確獎懲制度服務于團隊管理,使臨時借調的人也同樣有責任和動力;功能拆分留存業務功能的關鍵設計在設計文檔中得到簡明的解釋和記錄;重構升級遇到的坑問題舉例廢棄的業務邏輯要及時清理垃圾代碼對業務無意,卻會分散你的注意力;謹慎數據庫自增主鍵做業務分庫分表,數據異構的情況;(couponId/consumerCode)表結構要有操作時間戳字段增量數據異構成為可能不要提前買單-避免過度設計領取優惠券(單張/券包/預占/釋放/兌換)不要忽略細節對系統的影響日志打印/對象序列化合理使用緩存分組/分片/數據壓縮/序列化/過期策略/批量操作等重構不是結束而是新的開始讓營地比你來時更干凈。