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