基於通用jar、動態配置、組件編排的會員任務中心繫統設計

1、聊聊本文想說什麼:

爲更好幫助商家的會員快速成長,保持用戶活性,完善用戶的成長體系,有贊用戶中心-會員成長團隊基於現有的業務場景,設計了一套較完備任務中心繫統。同時也有不少通用技術組件可以落地。接下來本文會簡單分享下這些經常使用的技術組件,拋磚引玉。mysql

在開始以前咱們會先提幾個問題:redis

  • 1.任務中心對於普通商戶有什麼用處?
  • 2.如何實現任務中心,作到快速接入,擴展性好?
  • 3.有哪些技術能夠結合任務中心一塊兒落地?

1.1 咱們內部的一些黑話

#2、爲何要作任務中心?sql

2.1 任務中心的出發點:

  • a、用戶激活:提高用戶體驗,增長客戶活躍,方便商戶進行用戶信息採集,完善本身的信息網。
  • b、提升留存:引導客戶每日參與任務,經過會員體系+積分紅長值獎勵,提升用戶粘性。
  • c、提升用戶復購和客單價:設置購買任務和結合積分購買等特權。
  • d、老帶新傳播:經過拉新任務或者拼團任務等活動,持續拉新。

2.2 任務中心的目標:

  • B端: 商戶可視的任務配置中心,方便管理控制任務。
  • C端:用戶領取完成任務,異步或同步處理完成,提供:定時任務、階段任務。
  • 接入、使用方:快速可視化接入,任務完成回執簡單。
  • 系統自己:對於新任務接入,可拓展性,儘可能保證主流程改動最小。

3、咱們是如何實現的?

3.1 咱們的技術方案

咱們從現有的業務體系中,剝離出B端的配置中心和C端的任務處理中心,集合一些經常使用的系統組件,儘可能作到接口原子化,可編排、能力內聚;在結合通用工具jar,是業務系統接入足夠快速;同時設置了平臺型通用配置,使用基於apollo的動態加載配置信息到本地緩存,達到不用發佈應用,就能夠快速接入新任務。 數據庫

3.2 如何串聯平臺、商戶、用戶?

有贊雖然是一家saas公司,可是在有贊內部平臺、商戶、用戶的概念是都有維護的,能夠說三者相輔相成,不會獨立出現。緩存

  • 1.平臺側能夠經過後臺系統快速接入,給產品同窗進行審批和配置落地。
  • 2.商戶端能夠在頁面,快速配置任務信息和任務獎勵。
  • 3.給業務方提供多種任務快速接入方式,通用的任務調度完成以及商戶維度的通用獎勵發放能力。

3.2 咱們還提供了哪些能力?

3.3 任務的經常使用狀態

通用的合理的狀態流轉,能夠快速定位區分C端用戶的任務完成狀況,失敗和終止的業務能夠依賴定時任務作任務完成重放,快速推動到完結,併發放獎勵,規避異常給用戶帶來的獎勵信息不一樣步的問題,保證系統內的一致性。 併發

4、咱們使用了哪些核心技術組件

4.1 冪等控制組件

4.1.1 爲何要要使用冪等組件

在任務中心落地中,不少場景須要控制任務的惟一冪等,屢次發放不會重發等等。以前咱們主要是經過db冪等表,插入業務惟一索引來保證冪等,可是須要數據庫的事務保證,即冪等流水和業務要一塊兒提交,失敗即回滾。當使用到多庫的場景時,業務系統每一個庫都要增長一張流水錶,而且控制本分片內業務id和分片id一致,比較繁瑣。運維

還有一部份內部系統使用分佈式存儲(好比redis),來保存業務請求記錄。服務端在接收到請求後,用原子性的查詢和保存操做(好比redis的setnx命令),來保證業務惟一流水落到存儲中,在業務設置的超時時間前,控制業務流水的冪等。當發現重複流水時,按照必定的策略返回。異步

在任務中心繫統落地時,同時保留了兩種模式,而且還要考慮接入方依賴的存儲的拓展性和快速接入。jvm

4.1.2 冪等組件的規則

  • 冪等使用支持註解方式快速接入+spEL表達式拼接冪等入參信息。
  • 基於apollo的動態配置推送。
  • 冪等存儲策略:
    • 1.緩存redis存儲(優先)2.mysql存儲 等
  • 冪等拒絕策略:
    • 1.屢次返回相同結果 2.返回冪等碼 3.拋出異常 等

4.1.3 冪等組件的設計

經過基礎的工具jar包,承載整個冪等組件邏輯,達到快速接入的目的,經過apollo能夠動態推送相關配置,達到業務系統快速切換分支,隨時線上應急。 分佈式

4.2 集成了通用緩存能力流程編排組件

因爲多個任務中,不少基礎組件能力均可以直接複用。好比發放獎勵中:發放成長值、發放積分、優惠券等等,不少任務都有相同的邏輯,爲了達到無需重複開發,新任務快速接入的目的。

咱們開發了一套基於db+xml配置流程編排引擎,能夠快速編排已有邏輯,減小重複開發工做。

編排還提供的基礎能力:

  • 1.持續開發基於熱加載的模板動態加載機制。進一步增長流程的動態可配置能力。
  • 2.同時在通用模板中,實現了緩存通用邏輯以及熱點緩存功能,在大促或者商家有營銷活動時,任務中心也能夠穩定支持。

4.3 動態配置變動組件

目前不少基礎配置都是經過依賴配置文件,或者apollo的動態配置。

可是這兩種方式都是有必定優缺點的:配置文件的方式,雖然存儲容量沒有限制,可是配置變動後,須要重啓應用,比較複雜。而apollo開關的方式雖然能夠動態變動,可是存儲的配置信息不多,有必定長度限制。對於任務中心這種多任務平臺型的配置,有必定影響。

因此最後使用了基於jvm+apollo的延時加載的策略,即保證了不用頻繁發佈,同時能夠動態變動配置信息。

4.4 獨立的異步日誌流水記錄

傳統的同步日誌記錄,佔用系統資源,而且因爲任務中心的特性,C端任務完成流水信息會不少。 因此任務中心落地時轉化爲日誌的異步流水事件,由單獨的日誌系統提供日誌採集、上傳、可視化、檢索等通用能力。

5、將來,咱們還在砥礪前行:

本着可視化、配置化的原則,爲了讓外圍接入更容易,同時減小內部開發量的原則。接下來咱們還會去繼續完善系統:

  • 1.任務中心運維產品化(在建中):單獨開發的一套產品層應用,使用可視化的頁面後臺管理。方便業務接入和平常運維。能夠獨立經過頁面完成配置+上線。
  • 2.基於回調和配置的擴展點+流程共建(在建中):經過擴展點共建方式,將流程編排的能力,暴露給內外部的開發者,完成任務中心的共建。

有你有贊,將來可期(附內推郵箱:sunchang@youzan.com,歡迎加入有贊業務中臺-用戶中心) 預覽

相關文章
相關標籤/搜索