爲更好幫助商家的會員快速成長,保持用戶活性,完善用戶的成長體系,有贊用戶中心-會員成長團隊基於現有的業務場景,設計了一套較完備任務中心繫統。同時也有不少通用技術組件可以落地。接下來本文會簡單分享下這些經常使用的技術組件,拋磚引玉。mysql
在開始以前咱們會先提幾個問題:redis
#2、爲何要作任務中心?sql
咱們從現有的業務體系中,剝離出B端的配置中心和C端的任務處理中心,集合一些經常使用的系統組件,儘可能作到接口原子化,可編排、能力內聚;在結合通用工具jar,是業務系統接入足夠快速;同時設置了平臺型通用配置,使用基於apollo的動態加載配置信息到本地緩存,達到不用發佈應用,就能夠快速接入新任務。 數據庫
有贊雖然是一家saas公司,可是在有贊內部平臺、商戶、用戶的概念是都有維護的,能夠說三者相輔相成,不會獨立出現。緩存
通用的合理的狀態流轉,能夠快速定位區分C端用戶的任務完成狀況,失敗和終止的業務能夠依賴定時任務作任務完成重放,快速推動到完結,併發放獎勵,規避異常給用戶帶來的獎勵信息不一樣步的問題,保證系統內的一致性。 併發
在任務中心落地中,不少場景須要控制任務的惟一冪等,屢次發放不會重發等等。以前咱們主要是經過db冪等表,插入業務惟一索引來保證冪等,可是須要數據庫的事務保證,即冪等流水和業務要一塊兒提交,失敗即回滾。當使用到多庫的場景時,業務系統每一個庫都要增長一張流水錶,而且控制本分片內業務id和分片id一致,比較繁瑣。運維
還有一部份內部系統使用分佈式存儲(好比redis),來保存業務請求記錄。服務端在接收到請求後,用原子性的查詢和保存操做(好比redis的setnx命令),來保證業務惟一流水落到存儲中,在業務設置的超時時間前,控制業務流水的冪等。當發現重複流水時,按照必定的策略返回。異步
在任務中心繫統落地時,同時保留了兩種模式,而且還要考慮接入方依賴的存儲的拓展性和快速接入。jvm
經過基礎的工具jar包,承載整個冪等組件邏輯,達到快速接入的目的,經過apollo能夠動態推送相關配置,達到業務系統快速切換分支,隨時線上應急。 分佈式
因爲多個任務中,不少基礎組件能力均可以直接複用。好比發放獎勵中:發放成長值、發放積分、優惠券等等,不少任務都有相同的邏輯,爲了達到無需重複開發,新任務快速接入的目的。
咱們開發了一套基於db+xml配置流程編排引擎,能夠快速編排已有邏輯,減小重複開發工做。
編排還提供的基礎能力:
目前不少基礎配置都是經過依賴配置文件,或者apollo的動態配置。
可是這兩種方式都是有必定優缺點的:配置文件的方式,雖然存儲容量沒有限制,可是配置變動後,須要重啓應用,比較複雜。而apollo開關的方式雖然能夠動態變動,可是存儲的配置信息不多,有必定長度限制。對於任務中心這種多任務平臺型的配置,有必定影響。
因此最後使用了基於jvm+apollo的延時加載的策略,即保證了不用頻繁發佈,同時能夠動態變動配置信息。
傳統的同步日誌記錄,佔用系統資源,而且因爲任務中心的特性,C端任務完成流水信息會不少。 因此任務中心落地時轉化爲日誌的異步流水事件,由單獨的日誌系統提供日誌採集、上傳、可視化、檢索等通用能力。
本着可視化、配置化的原則,爲了讓外圍接入更容易,同時減小內部開發量的原則。接下來咱們還會去繼續完善系統:
有你有贊,將來可期(附內推郵箱:sunchang@youzan.com,歡迎加入有贊業務中臺-用戶中心) 預覽