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

1、聊聊本文想說什麼：

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

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

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

1.1 咱們內部的一些黑話

#2、爲何要作任務中心？

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命令)，來保證業務惟一流水落到存儲中，在業務設置的超時時間前，控制業務流水的冪等。當發現重複流水時，按照必定的策略返回。

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

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，歡迎加入有贊業務中臺-用戶中心） 預覽