轉載字?聊聊架構?微信公眾號
蘇寧集團業(yè)務涉獵非常廣，主要包括：蘇寧易購，蘇寧金融，蘇寧體育，蘇寧文創(chuàng)，蘇寧置業(yè)，蘇寧門店等業(yè)務領域。本文所闡述的是從 2015 年至今，蘇寧金融營銷系統(tǒng)的發(fā)展歷程。蘇寧金融營銷系統(tǒng)不僅支撐了蘇寧金融營銷業(yè)務，也支撐了蘇寧易購，蘇寧體育，蘇寧門店等部分營銷業(yè)務。
一切源頭：業(yè)務發(fā)展
2015 年至今，為了適應蘇寧集團的發(fā)展，蘇寧金融營銷業(yè)務方陸續(xù)提出了很多目標。
可以總結為五大功能目標：
建立營銷活動全流程的閉環(huán)管控。
現(xiàn)有的滿減，立減，返券等促銷形式遠不夠，支持更多的營銷形式。
實現(xiàn)營銷活動數(shù)據(jù)可視化。
實現(xiàn)從活動申請、預算、結算、到效果評估的自動化。
與蘇寧易購，蘇寧體育，蘇寧門店等進行深度配合。
為了適應業(yè)務的發(fā)展，解決業(yè)務的需求，我們團隊開啟了蘇寧金融營銷系統(tǒng)重構之路。
混沌時代：蘇寧金融營銷系統(tǒng)架構 V1.0
2015 年，系統(tǒng)架構 V1.0 時代，蘇寧金融營銷系統(tǒng)包括：促銷服務、電子券服務、任務服務。
促銷服務：提供促銷活動查詢、扣減、管理、規(guī)則處理、活動配置等功能。
電子券服務：提供電子券管理、查詢、使用、退券、規(guī)則處理、活動配置等功能。
任務服務：提供判斷用戶是否滿足任務的規(guī)則，且事后發(fā)放營銷福利的功能。
經(jīng)過梳理上述系統(tǒng)的上下文，應用架構，核心功能。針對架構方面分析出如下問題：
1. 職責不清晰。
當時系統(tǒng)架構，電子券服務與促銷服務，互相調用，兩者的上下游系統(tǒng)基本一致。其實電子券服務和促銷服務都是一種營銷“實體”，它們只需要具備“實體”管理的基本功能，而且相對獨立，各自為政。
2. 缺乏統(tǒng)一的活動管理。
當時系統(tǒng)架構，電子券服務和促銷服務都包含活動管理和配置，并且分散管理。
這種情況下，無法滿足活動全流程閉環(huán)管控，活動申請、預算控制等需求。
3. 缺乏營銷數(shù)據(jù)分析。
當時系統(tǒng)架構，所有的營銷行為數(shù)據(jù)都未記錄，或者是分散記錄。
這種情況下，無法滿足營銷數(shù)據(jù)可視化，活動效果數(shù)據(jù)分析等需求。
規(guī)則引擎引發(fā)的“血案”。
規(guī)則引擎及規(guī)則資格校驗是一個計算資源消耗非常大的功能。營銷前臺、促銷服務、電子券、任務服務都包含此功能。隨著活動形式的持續(xù)增長，消耗的計算資源也持續(xù)上升。多個系統(tǒng)同時申請資源，導致資源的浪費。尤其是 818、1111 大促期間。資源申請需要與資源管理部進行博弈，有時會引發(fā)‘血案’。
大刀闊斧：蘇寧金融營銷系統(tǒng)架構 V2.0
對癥下藥
2015 年至今，針對系統(tǒng)架構問題，系統(tǒng)不斷的迭代，我們采用了很多針對性的解決方法。
1. 分工明確化。
電子券服務和促銷服務作為一種營銷“實體”，它們只需要具備“實體”管理的基本功能，而且相對獨立。在它們的上層抽出一個統(tǒng)一營銷服務，統(tǒng)一的對外服務。
2. 建設統(tǒng)一活動中心。
建設統(tǒng)一活動中心，包括：營銷活動管理、營銷活動審批、預算管控、促銷狀態(tài)管理、促銷結算等。滿足活動全流程閉環(huán)管控，活動申請、預算控制等需求。
3. 建設營銷數(shù)據(jù)中心。
建設營銷數(shù)據(jù)中心，包括：營銷行為數(shù)據(jù)都采集，存儲，分析，報表。滿足營銷數(shù)據(jù)可視化，活動效果數(shù)據(jù)分析等需求。
4. 拆分出規(guī)則引擎。
獨立的規(guī)則引擎系統(tǒng)，承載上游所有促銷形式的規(guī)則計算，節(jié)省資源。
整體“藥方”
現(xiàn)在，蘇寧金融營銷系統(tǒng)架構 V2.0 時代，總體架構圖如下，蘇寧金融營銷系統(tǒng)以整體的形式一致對外服務，不再是“單干”。
圖 1：整體系統(tǒng)架構 V2.0
核心系統(tǒng)包括：營銷統(tǒng)一服務、促銷服務、電子券服務、任務服務、商品詳情頁促銷前置服務、營銷規(guī)則引擎、營銷規(guī)則資格校驗、營銷活動中心、營銷數(shù)據(jù)中心。
營銷統(tǒng)一服務：促銷查詢、扣減；電子券查詢、使用、退券等統(tǒng)一對外服務。
促銷服務：提供促銷活動查詢、扣減等功能。
電子券服務：提供電子券管理、查詢、使用、退券等功能。
任務服務：提供判斷用戶是否滿足任務的規(guī)則，且事后發(fā)放營銷福利的功能。
商品詳情頁促銷前置服務：應對流量較高的商品詳情頁、搜索等頁面提供的促銷查詢服務。
營銷規(guī)則引擎：提供促銷、電子券、任務等規(guī)則引擎處理服務
營銷規(guī)則資格校驗：提供促銷、電子券、任務等規(guī)則資格校驗服務
營銷活動中心：包括營銷活動管理、營銷活動審批、預算管控、促銷狀態(tài)管理、促銷結算、規(guī)則分發(fā)、促銷活動下發(fā)。
部分系統(tǒng)上下文如下：
圖 2：統(tǒng)一營銷服務系統(tǒng)上下文 V2.0
圖 3: 任務服務系統(tǒng)上下文 V2.0
圖 4: 商品詳情頁促銷前置服務系統(tǒng)上下文 V2.0
各個突破：解決問題的方法論
自蘇寧金融營銷系統(tǒng)建立以來，尤其是 2015 年開始至今，業(yè)務迅猛發(fā)展，團隊在實際系統(tǒng)運行過程中，遇到了不少麻煩，但我們的小伙伴堅忍不拔，各個突破，讓系統(tǒng)穩(wěn)定的度過每個大促節(jié)點。
1. 用戶流量上升，活動種類增加，導致規(guī)則引擎與資格校驗性能下降
2015 年，同一時間同時生效的營銷活動已經(jīng)接近 300 個。由于蘇寧集團業(yè)務復雜，涉及線上，線下。因此，業(yè)務的活動種類訴求會越來越多。另一方面，蘇寧金融與蘇寧易購合作之后，用戶訪問量爆發(fā)性增長，業(yè)務及產(chǎn)品層面上，越來越重視用戶體驗。
2015 年，蘇寧金融營銷系統(tǒng)架構 V1.0 時代，未對營銷場景做細致的區(qū)分，導致每次匹配相關規(guī)則是全量匹配，全量匹配結束后的資格校驗也是全量校驗，導致單人次請求后，系統(tǒng)過濾規(guī)則數(shù)據(jù)量較大，并且校驗次數(shù)增多，特別是大促中活動增加的情況，單次用戶請求，規(guī)則校驗平均需要執(zhí)行大約 1000 次以上方能匹配到用戶實際能夠享受的營銷活動信息。
圖 5：營銷活動規(guī)則校驗流程 V1.0
另外，規(guī)則引擎和資格校驗服務未獨立，促銷服務、電子券服務、任務服務只能不斷通過橫向擴容，提高系統(tǒng)并發(fā)能力。顯然這樣做，一方面資源浪費，另一方面當活動種類增加后，單機的計算耗時上升，橫向擴容能夠提升的并發(fā)能力有限。
現(xiàn)在，蘇寧金融營銷系統(tǒng)架構 V2.0 時代，統(tǒng)一活動中心配置營銷活動，且區(qū)分實時營銷、事后營銷（任務），同時區(qū)分線上活動、線下活動、全渠道活動。規(guī)則服務在接收營銷活動配置后根據(jù)相關配置來生成不同的規(guī)則文件，以此減少規(guī)則匹配中的數(shù)據(jù)量問題，并且根據(jù)不同類型和渠道分開存儲資格校驗數(shù)據(jù)。統(tǒng)一營銷服務和任務服務統(tǒng)一對外服務，請求數(shù)據(jù)區(qū)分系統(tǒng)、及區(qū)分線上、線下活動，降低規(guī)則匹配和資格校驗的復雜度。
當然在系統(tǒng)架構層面上，還有規(guī)則服務獨立。規(guī)則服務的資源擴容，完全根據(jù)規(guī)則的性能需求。
圖 6：營銷活動規(guī)則校驗流程 V2.0
2. 活動總數(shù)的校驗存在數(shù)據(jù)熱點問題
2016 年，蘇寧金融營銷系統(tǒng)架構 V1.0 時代，有些活動允許所有會員參與，但有總次數(shù)、金額限制。這種類型的活動，每次用戶請求必須校驗，為了避免數(shù)據(jù)不一致性，總次數(shù)、金額需要集中存儲，根據(jù) key= 活動 ID 存儲到某臺緩存設備，一旦活動訪問流量比較大，那么就會導致緩存熱點問題。還有些配置了月次數(shù)、金額；周次數(shù)、金額；日次數(shù)、金額的活動，均會出現(xiàn)緩存熱點問題。
現(xiàn)在，蘇寧金融營銷系統(tǒng)架構 V2.0 時代，緩存設備申請一主兩從多組方式，并且設置 slave 參與讀模式減少讀取熱點，而且通過類型及渠道的緩存分組，提高系統(tǒng)整體的緩存服務能力。
圖 7：數(shù)據(jù)熱點解決方案 V2.0
3. 面向會員的 6 個唯一資格校驗問題
2016 年，蘇寧金融營銷系統(tǒng)架構 V1.0 時代，參與營銷活動的會員的唯一校驗，活動參與次數(shù)限定到個人。手機號、帳號、設備、身份證、銀行卡、銀行綁定手機號。
針對此種校驗，單次請求數(shù)據(jù) 6 個唯一條件都需要一一進行判斷，這樣就對同一個活動增加了跟緩存交互次數(shù)。活動越多、應用跟緩存交互次數(shù)越多，耗時就越長，系統(tǒng)性能必然降低。同時為了保證相關唯一校驗的可靠性，系統(tǒng)在處理中還對唯一數(shù)據(jù)入庫處理，增加了系統(tǒng)負擔。
現(xiàn)在，系統(tǒng)架構 V2.0 時代，通過合并請求，同一個活動相關的唯一性查詢進行合并，減少跟緩存的請求次數(shù)，且應用的緩存采用持久化策略。
4. 活動存儲數(shù)據(jù)已經(jīng)約 1 億
2017 年，蘇寧金融營銷系統(tǒng)架構 V1.0 時代，做了分表處理，由于營銷活動較多，用戶使用較多。促銷活動雖然做了歷史數(shù)據(jù)規(guī)整處理，但仍然存在單表數(shù)據(jù)量過大問題，導致對表操作產(chǎn)出性能瓶頸；尤其是撤銷支付功能。撤銷支付功能為了能取消用戶占用資格，還需要對用戶占用的資格數(shù)據(jù)進行回退，那么撤銷操作會涉及歷史表，而歷史表數(shù)據(jù)量非常大，已經(jīng)約 1 億，因此影響到整體的性能。
現(xiàn)在，蘇寧金融營銷系統(tǒng)架構 V2.0 時代，活動業(yè)務數(shù)據(jù)進行業(yè)務分庫分表操作（大約分為 10 個庫，約 2000 張表），通過這樣的分配減少單表數(shù)據(jù)量，提高數(shù)據(jù)庫并發(fā)處理能力。
圖 8：數(shù)據(jù)存儲分片方案 V2.0
底盤扎實：完善的基礎設施
2015 年至今，蘇寧金融營銷系統(tǒng)重構，居于微服務架構思路。對于微服務架構，有人認為是銀彈，有人認為是焦油坑。
認為是焦油坑的人，一般都陷入微服務架構的幾個坑，第一，服務數(shù)量太多，團結效率下降；第二，調用鏈路太長，性能下降；第三，調用鏈太長，問題定位困難；第四，沒有自動化支持，無法快速交付。總之，基礎設施不健全。
幸運的是，對于蘇寧金融團隊來說，微服務架構被認為是銀彈。這得歸功于蘇寧金融研發(fā)團隊小伙伴們，提供了完整的基礎設施，公共組件，基礎服務，中間件；解決了微服務的坑。
簡單介紹下蘇寧具備的微服務基礎設施：
自動化測試：蛙測
自動化部署（持續(xù)交付）：蘇寧開放云
配置中心：SCM
接口框架: 魔客平臺
API 網(wǎng)關：金融一站式網(wǎng)關
服務發(fā)現(xiàn)、服務路由、服務容錯、服務調用：RSF
服務監(jiān)控：穆加、紫金大盤
服務跟蹤：穆加
服務安全：金融開放平臺
展望未來
2017 年 -2018 年初蘇寧提出了數(shù)據(jù)驅動經(jīng)營戰(zhàn)略。蘇寧金融營銷系統(tǒng)也沿著這個思路發(fā)展，規(guī)劃系統(tǒng)的發(fā)展方向，未來規(guī)劃包含：營銷流程全閉環(huán)，營銷過程實時數(shù)據(jù)，智能報表，營銷數(shù)據(jù)挖掘，營銷活動推薦，營銷活動預算自控。
圖 9 展望未來
作者介紹
王清平，蘇寧金融研發(fā)中心資深架構師，精通微服務架構模式，熟悉 Java 領域技術架構。在廣告、營銷、電商領域的技術研發(fā)、架構設計等方面擁有多年實戰(zhàn)經(jīng)驗，擅長提升系統(tǒng)的高可用，高性能，擴展性等能力。現(xiàn)在主要負責蘇寧金融會員及互聯(lián)網(wǎng)研發(fā)中心的應用架構與技術架構工作。
王海民，蘇寧金融研發(fā)中心高級技術經(jīng)理，主要負責蘇寧金融會員及互聯(lián)網(wǎng)研發(fā)中心的營銷部門工作。具有營銷、電商、支付、金融等相關領域 10 年以上工作經(jīng)歷；擅長互聯(lián)網(wǎng)產(chǎn)品服務端應用技術架構。
