資訊專欄INFORMATION COLUMN
摘要：基于的動態(tài)配置推送。對于任務中心這種多任務平臺型的配置，有一定影響?；诨卣{(diào)和配置的擴展點流程共建在建中通過擴展點共建方式，將流程編排的能力，暴露給內(nèi)外部的開發(fā)者，完成任務中心的共建。
一、聊聊本文想說什么：
??為更好幫助商家的會員快速成長，保持用戶活性，完善用戶的成長體系，有贊用戶中心-會員成長團隊基于現(xiàn)有的業(yè)務場景，設(shè)計了一套較完備任務中心系統(tǒng)。同時也有很多通用技術(shù)組件能夠落地。接下來本文會簡單分享下這些常用的技術(shù)組件，拋磚引玉。
??在開始之前我們會先提幾個問題：
1.任務中心對于普通商戶有什么用處？
2.如何實現(xiàn)任務中心，做到快速接入，擴展性好？
3.有哪些技術(shù)可以結(jié)合任務中心一起落地？
1.1 我們內(nèi)部的一些黑話 二、為什么要做任務中心？ 2.1 任務中心的出發(fā)點：a、用戶激活：提升用戶體驗，增加客戶活躍，方便商戶進行用戶信息采集，完善自己的信息網(wǎng)。
b、提高留存：引導客戶每日參與任務，通過會員體系+積分成長值獎勵，提高用戶粘性。
c、提高用戶復購和客單價：設(shè)置購買任務和結(jié)合積分購買等特權(quán)。
d、老帶新傳播：通過拉新任務或者拼團任務等活動，持續(xù)拉新。
2.2 任務中心的目標：B端： 商戶可視的任務配置中心，方便管理控制任務。
C端：用戶領(lǐng)取完成任務，異步或同步處理完成，提供：定時任務、階段任務。
接入、使用方：快速可視化接入，任務完成回執(zhí)簡單。
系統(tǒng)本身：對于新任務接入，可拓展性，盡量保證主流程改動最小。
三、我們是如何實現(xiàn)的？ 3.1 我們的技術(shù)方案??我們從現(xiàn)有的業(yè)務體系中，剝離出B端的配置中心和C端的任務處理中心，集合一些常用的系統(tǒng)組件，盡量做到接口原子化，可編排、能力內(nèi)聚；在結(jié)合通用工具jar，是業(yè)務系統(tǒng)接入足夠快速；同時設(shè)置了平臺型通用配置，使用基于apollo的動態(tài)加載配置信息到本地緩存，達到不用發(fā)布應用，就可以快速接入新任務。
??有贊雖然是一家saas公司，但是在有贊內(nèi)部平臺、商戶、用戶的概念是都有維護的，可以說三者相輔相成，不會獨立出現(xiàn)。
1.平臺側(cè)可以通過后臺系統(tǒng)快速接入，給產(chǎn)品同學進行審批和配置落地。
2.商戶端可以在頁面，快速配置任務信息和任務獎勵。
3.給業(yè)務方提供多種任務快速接入方式，通用的任務調(diào)度完成以及商戶維度的通用獎勵發(fā)放能力。
3.2 我們還提供了哪些能力？ 3.3 任務的常用狀態(tài)??通用的合理的狀態(tài)流轉(zhuǎn)，可以快速定位區(qū)分C端用戶的任務完成情況，失敗和終止的業(yè)務可以依賴定時任務做任務完成重放，快速推進到完結(jié)，并發(fā)放獎勵，規(guī)避異常給用戶帶來的獎勵信息不同步的問題，保證系統(tǒng)內(nèi)的一致性。
??在任務中心落地中，很多場景需要控制任務的唯一冪等，多次發(fā)放不會重發(fā)等等。之前我們主要是通過db冪等表，插入業(yè)務唯一索引來保證冪等，但是需要數(shù)據(jù)庫的事務保證，即冪等流水和業(yè)務要一起提交，失敗即回滾。當使用到多庫的場景時，業(yè)務系統(tǒng)每個庫都要增加一張流水表，并且控制本分片內(nèi)業(yè)務id和分片id一致，比較繁瑣。
??還有一部分內(nèi)部系統(tǒng)使用分布式存儲(比如redis)，來保存業(yè)務請求記錄。服務端在接收到請求后，用原子性的查詢和保存操作(比如redis的setnx命令)，來保證業(yè)務唯一流水落到存儲中，在業(yè)務設(shè)置的超時時間前，控制業(yè)務流水的冪等。當發(fā)現(xiàn)重復流水時，按照一定的策略返回。
??在任務中心系統(tǒng)落地時，同時保留了兩種模式，并且還要考慮接入方依賴的存儲的拓展性和快速接入。
4.1.2 冪等組件的規(guī)則冪等使用支持注解方式快速接入+spEL表達式拼接冪等入?yún)⑿畔ⅰ?/p>
基于apollo的動態(tài)配置推送。
冪等存儲策略:
1.緩存redis存儲（優(yōu)先）2.mysql存儲 等
冪等拒絕策略:
1.多次返回相同結(jié)果 2.返回冪等碼 3.拋出異常 等
4.1.3 冪等組件的設(shè)計??通過基礎(chǔ)的工具jar包，承載整個冪等組件邏輯，達到快速接入的目的，通過apollo可以動態(tài)推送相關(guān)配置，達到業(yè)務系統(tǒng)快速切換分支，隨時線上應急。
??由于多個任務中，很多基礎(chǔ)組件能力都可以直接復用。比如發(fā)放獎勵中：發(fā)放成長值、發(fā)放積分、優(yōu)惠券等等，很多任務都有相同的邏輯，為了達到無需重復開發(fā)，新任務快速接入的目的。
??我們開發(fā)了一套基于db+xml配置流程編排引擎，可以快速編排已有邏輯，減少重復開發(fā)工作。
??編排還提供的基礎(chǔ)能力：
1.持續(xù)開發(fā)基于熱加載的模板動態(tài)加載機制。進一步增加流程的動態(tài)可配置能力。
2.同時在通用模板中，實現(xiàn)了緩存通用邏輯以及熱點緩存功能，在大促或者商家有營銷活動時，任務中心也可以穩(wěn)定支持。
4.3 動態(tài)配置變更組件??目前很多基礎(chǔ)配置都是通過依賴配置文件，或者apollo的動態(tài)配置。
??但是這兩種方式都是有一定優(yōu)缺點的：配置文件的方式，雖然存儲容量沒有限制，但是配置變更后，需要重啟應用，比較復雜。而apollo開關(guān)的方式雖然可以動態(tài)變更，但是存儲的配置信息很少，有一定長度限制。對于任務中心這種多任務平臺型的配置，有一定影響。
??所以最后使用了基于jvm+apollo的延時加載的策略，即保證了不用頻繁發(fā)布，同時可以動態(tài)變更配置信息。
4.4 獨立的異步日志流水記錄??傳統(tǒng)的同步日志記錄，占用系統(tǒng)資源，并且由于任務中心的特性，C端任務完成流水信息會很多。 所以任務中心落地時轉(zhuǎn)化為日志的異步流水事件，由多帶帶的日志系統(tǒng)提供日志采集、上傳、可視化、檢索等通用能力。
五、未來，我們還在砥礪前行：??本著可視化、配置化的原則，為了讓外圍接入更容易，同時減少內(nèi)部開發(fā)量的原則。接下來我們還會去繼續(xù)完善系統(tǒng)：
1.任務中心運維產(chǎn)品化（在建中）：多帶帶開發(fā)的一套產(chǎn)品層應用，使用可視化的頁面后臺管理。方便業(yè)務接入和日常運維?？梢元毩⑼ㄟ^頁面完成配置+上線。
2.基于回調(diào)和配置的擴展點+流程共建（在建中）：通過擴展點共建方式，將流程編排的能力，暴露給內(nèi)外部的開發(fā)者，完成任務中心的共建。
有你有贊，未來可期(附內(nèi)推郵箱：[email protected]，歡迎加入有贊業(yè)務中臺-用戶中心）
預覽
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/75953.html
摘要：業(yè)務對賬平臺的核心目的，就是及時發(fā)現(xiàn)類似問題，并及時修復。這對對賬平臺的吞吐量造成了挑戰(zhàn)。五健康度對賬中心可以拿到業(yè)務系統(tǒng)及其所在整個鏈路的數(shù)據(jù)一致性信息。在分布式環(huán)境下，沒有人能回避數(shù)據(jù)一致性問題，我們對此充滿著敬畏。 一、引子 根據(jù)CAP原理，分布式系統(tǒng)無法在保證了可用性（Availability）和分區(qū)容忍性（Partition）之后，繼續(xù)保證一致性（Consistency）。我...
摘要：因此數(shù)據(jù)中臺必須具備智能化能力，能夠為業(yè)務提供一定的智能數(shù)據(jù)分析能力。宜信作為一家金融科技公司，更多面對的是金融領(lǐng)域的智能業(yè)務需求。 showImg(https://segmentfault.com/img/bVbqQM0?w=1155&h=492); 內(nèi)容來源：宜信技術(shù)學院第1期技術(shù)沙龍-線上直播|AI中臺：一種敏捷的智能業(yè)務支持方案 主講人介紹：井玉欣 宜信技術(shù)研發(fā)中心AI應用團隊...
摘要：本文中，我們將描述系統(tǒng)的架構(gòu)開發(fā)演進過程，以及背后的驅(qū)動原因。應用管理層提供基本的部署和路由，包括自愈能力彈性擴容服務發(fā)現(xiàn)負載均衡和流量路由。 帶你了解Kubernetes架構(gòu)的設(shè)計意圖、Kubernetes系統(tǒng)的架構(gòu)開發(fā)演進過程，以及背后的驅(qū)動原因。 showImg(https://segmentfault.com/img/remote/1460000016446636?w=1280...
摘要：說起，必須要介紹是什么東西，為什么中小企業(yè)私有云適合使用?？匆幌卢F(xiàn)在的架構(gòu)圖開個玩笑。上面這四點導致我們必須要統(tǒng)一架構(gòu)，最終把整個業(yè)務系統(tǒng)遷移到基于的類似于的私有云的平臺。 本文系 ArchSummit 大會 CODING 工程師王振威演講實錄。 showImg(https://dn-coding-net-production-pp.qbox.me/c2f81423-54b9-4a7b...
摘要：事件處理器是自包含和獨立的，解耦于架構(gòu)。因其分布式和異步的性質(zhì)，事件驅(qū)動架構(gòu)的實現(xiàn)相對復雜，主要是由于它的異步和分布式特性。微內(nèi)核架構(gòu)微內(nèi)核架構(gòu)模式也被稱為插件架構(gòu)模式。 來自于OReilly免費的電子書：Software Architecture Patterns showImg(https://segmentfault.com/img/remote/1460000009652123...
閱讀 3554·2023-04-25 15:52
閱讀 607·2021-11-19 09:40
閱讀 2677·2021-09-26 09:47
閱讀 1054·2021-09-22 15:17
閱讀 3586·2021-08-13 13:25
閱讀 2295·2019-08-30 15:56
閱讀 3517·2019-08-30 13:56
閱讀 2134·2019-08-30 11:27
