得物增長(zhǎng)兌換商城的架構(gòu)演進(jìn)
一、簡(jiǎn)介
二、誕生背景
三、業(yè)務(wù)架構(gòu)
1. 業(yè)務(wù)架構(gòu)圖
2. 業(yè)務(wù)架構(gòu)概述
四、玩法迭代
1. 整體玩法總覽
2. RPC調(diào)用迭代
3. 庫(kù)存設(shè)計(jì)迭代
4. 獎(jiǎng)品橫向迭代
5. 兌換防刷迭代
6. 項(xiàng)目穩(wěn)定性建設(shè)
五、更多拓展
1. 抽獎(jiǎng)組件搭建器
2. 引入增長(zhǎng)的任務(wù)中臺(tái)
3. 打造簡(jiǎn)易的積分系統(tǒng)
六、總結(jié)
一、簡(jiǎn)介
在移動(dòng)互聯(lián)網(wǎng)蓬勃發(fā)展的今天，用戶的選擇日益多元化，App市場(chǎng)的競(jìng)爭(zhēng)也愈發(fā)白熱化。為了在激烈的市場(chǎng)競(jìng)爭(zhēng)中脫穎而出，提升用戶獲取效率并增強(qiáng)用戶粘性，越來(lái)越多的應(yīng)用開(kāi)始采用積分兌換、抽獎(jiǎng)等互動(dòng)玩法。這些精心設(shè)計(jì)的運(yùn)營(yíng)策略不僅能夠滿足用戶的參與感和成就感需求，更能有效促進(jìn)社交傳播，提升品牌忠誠(chéng)度。通過(guò)持續(xù)優(yōu)化和迭代，開(kāi)發(fā)者能夠在競(jìng)爭(zhēng)激烈的市場(chǎng)中占據(jù)優(yōu)勢(shì)地位，實(shí)現(xiàn)用戶的可持續(xù)增長(zhǎng)和長(zhǎng)期留存。
基于提升系統(tǒng)復(fù)用性和穩(wěn)定性的考量，我們構(gòu)建了一個(gè)統(tǒng)一的兌換商城中臺(tái)系統(tǒng)。該中臺(tái)旨在為各上游業(yè)務(wù)線提供標(biāo)準(zhǔn)化的積分兌換和獎(jiǎng)勵(lì)機(jī)制，使各類應(yīng)用和服務(wù)能夠快速接入并享受便捷的服務(wù)支持。通過(guò)這一中臺(tái)架構(gòu)，我們不僅實(shí)現(xiàn)了核心業(yè)務(wù)邏輯的集中化管理與維護(hù)，更為后續(xù)的功能擴(kuò)展（如抽獎(jiǎng)、彩票等多樣化玩法）奠定了堅(jiān)實(shí)基礎(chǔ)，從而顯著提升了開(kāi)發(fā)效率和用戶體驗(yàn)。
二、誕生背景
在用戶增長(zhǎng)和留存策略的探索中，增長(zhǎng)團(tuán)隊(duì)先后推出了多種互動(dòng)類玩法，如每日簽到、星愿森林、心愿海洋以及早期的點(diǎn)鞋成金等。這些玩法通過(guò)積分或虛擬貨幣的積累，不僅增強(qiáng)了用戶的參與感，也為用戶提供了豐富的獎(jiǎng)勵(lì)機(jī)制。然而，隨著玩法的多樣化，如何高效管理這些積分或貨幣的消耗途徑，成為提升用戶體驗(yàn)和趣味性的關(guān)鍵。
每日簽到
星愿森林
心愿海洋
點(diǎn)鞋成金
兌換專區(qū)
兌換專區(qū)
兌換專區(qū)
兌換專區(qū)
面對(duì)這一挑戰(zhàn)，團(tuán)隊(duì)意識(shí)到為每個(gè)互動(dòng)玩法單獨(dú)開(kāi)發(fā)兌換功能不僅需要前后端的全面支持，還需重復(fù)搭建復(fù)雜的監(jiān)控和預(yù)警系統(tǒng)以防范潛在的資損風(fēng)險(xiǎn)。這種重復(fù)開(kāi)發(fā)的模式不僅成本高昂，而且難以保證系統(tǒng)的一致性和穩(wěn)定性。因此，構(gòu)建一個(gè)統(tǒng)一的積分商城，為各互動(dòng)玩法提供通用化的兌換系統(tǒng)，成為了提升開(kāi)發(fā)效率和確保系統(tǒng)安全性的必然選擇。這樣不僅優(yōu)化了資源配置，也為后續(xù)的玩法擴(kuò)展和用戶體驗(yàn)升級(jí)奠定了堅(jiān)實(shí)的基礎(chǔ)。
在既有兌換業(yè)務(wù)的基礎(chǔ)上，我們也成功沉淀并提煉了多個(gè)核心領(lǐng)域模型。后續(xù)基于這些通用化的領(lǐng)域模型，我們逐步探索并實(shí)現(xiàn)了多種新型玩法的快速落地，包括老虎機(jī)、盲盒以及抽獎(jiǎng)券等多樣化互動(dòng)形式。
三、業(yè)務(wù)架構(gòu)業(yè)務(wù)
架構(gòu)圖
圖片
業(yè)務(wù)架構(gòu)概述
業(yè)務(wù)架構(gòu)主要分4級(jí)：
- 上層業(yè)務(wù)? 主要是有使用兌換商城功能的上游應(yīng)用，包括星愿森林、每日簽到、心愿海洋、增長(zhǎng)新客、社區(qū)抽獎(jiǎng)、學(xué)生答題等應(yīng)用。
- 玩法沉淀? 主要包括三類玩法，包括積分兌換、老虎機(jī)/盲盒，以及抽獎(jiǎng)券等。玩法核心所依賴的領(lǐng)域模型基本相似，各個(gè)系統(tǒng)都能得到了很好的復(fù)用。而在玩法層面，我們主要使用了設(shè)計(jì)模式中的模板模式，優(yōu)先搭建好每個(gè)玩法的骨架，然后將一些關(guān)鍵步驟交由上游應(yīng)用自定義實(shí)現(xiàn)。
- 領(lǐng)域模型? 活動(dòng)：對(duì)應(yīng)每個(gè)新接入的應(yīng)用都需要新建一個(gè)活動(dòng)模型，而各類自定義的業(yè)務(wù)層面的邏輯都是在活動(dòng)維度上實(shí)現(xiàn)的。? 模板：模板作為上下關(guān)系的重要承接，一個(gè)活動(dòng)能夠創(chuàng)建多個(gè)模板，而每個(gè)模板下又可以關(guān)聯(lián)多個(gè)獎(jiǎng)品。之所以存在模板這個(gè)中間層，是有多個(gè)原因的。 ? 原因1：模板和活動(dòng)之間的關(guān)系，我們可以以星愿森林為例，一個(gè)活動(dòng)他是存在多個(gè)兌換專區(qū)的，包含了合種專區(qū)、超值專區(qū)等，這些是需要通過(guò)模板維度來(lái)劃分的。 ? 原因2：模板和獎(jiǎng)品之間的關(guān)系，獎(jiǎng)品需要關(guān)聯(lián)到不同的資產(chǎn)，創(chuàng)建一個(gè)獎(jiǎng)品的成本較高。而將獎(jiǎng)品設(shè)計(jì)成可以被綁定到多個(gè)模板上，獎(jiǎng)品這個(gè)資產(chǎn)就可以得到一個(gè)很好的復(fù)用。同時(shí)每個(gè)模板中該獎(jiǎng)品有其獨(dú)立的庫(kù)存模塊，那么模板之間就不會(huì)互相影響了。 ? ...? 獎(jiǎng)品：后臺(tái)不同類型的獎(jiǎng)品統(tǒng)一都需要在獎(jiǎng)品庫(kù)內(nèi)創(chuàng)建。這樣我們就能在不同的活動(dòng)和模板中在獎(jiǎng)品庫(kù)內(nèi)選出該獎(jiǎng)品。每次新增新的類型獎(jiǎng)品，需要實(shí)現(xiàn)該新類型獎(jiǎng)品的發(fā)獎(jiǎng)能力，如優(yōu)惠券、津貼、現(xiàn)金等都依賴不同的下游應(yīng)用進(jìn)行發(fā)放。? 庫(kù)存：目前支持分時(shí)間段庫(kù)存、每日庫(kù)存以及總庫(kù)存邏輯頻控，包含用戶及獎(jiǎng)品的發(fā)放頻控、包含每日頻次、周期循環(huán)頻次以及總頻次。
- 下游依賴? 主要是兌換商城所依賴的下游應(yīng)用，包括營(yíng)銷中臺(tái)、商品聚合中心、提現(xiàn)中臺(tái)、口令服務(wù)、增長(zhǎng)配置中心等。
四、玩法迭代
整體玩法總覽
本次玩法迭代的介紹主要以積分兌換玩法為主，參考樣式如下：
圖片
要想兌換具體的商品需要經(jīng)過(guò)一系列流程，下圖為兌換的主流程介紹，包含了用戶從發(fā)起兌換到最終兌換成功或失敗的流程。主要為用戶選擇某個(gè)獎(jiǎng)品兌換需要處理的一系列業(yè)務(wù)邏輯。
如上文所說(shuō)，在玩法層面，主要使用了設(shè)計(jì)模式中的模板模式，利用自己領(lǐng)域模型的能力，優(yōu)先搭建好兌換玩法的骨架，比如有效性校驗(yàn)、庫(kù)存扣減、獎(jiǎng)品發(fā)放等邏輯，然后將一些關(guān)鍵步驟如前置自定義檢查、扣減貨幣、回滾操作交由上游應(yīng)用自定義實(shí)現(xiàn)。
玩法內(nèi)置邏輯是由商城內(nèi)部的領(lǐng)域模型實(shí)現(xiàn)，主要包含通用邏輯如下：
- 各個(gè)模型的有效性校驗(yàn)：確保兌換請(qǐng)求的合法性。
- 庫(kù)存及頻控模型的前置校驗(yàn)：檢查庫(kù)存和頻控模型，確保兌換請(qǐng)求的可行性。
- 庫(kù)存扣減邏輯：扣減獎(jiǎng)品庫(kù)存，確保庫(kù)存數(shù)據(jù)的實(shí)時(shí)性和準(zhǔn)確性。
- 獎(jiǎng)勵(lì)模型的發(fā)放邏輯：發(fā)放用戶所兌換的獎(jiǎng)品。
- 兌換成功后置處理：進(jìn)行兌換成功的后置處理，如記錄日志、更新用戶狀態(tài)等。
即下圖灰色模塊是由商城自己的玩法模板實(shí)現(xiàn)。
需業(yè)務(wù)方對(duì)接邏輯主要包含：
- 前置自定義校驗(yàn)：實(shí)現(xiàn)特定業(yè)務(wù)規(guī)則的前置校驗(yàn)。
- 貨幣扣減：扣除用戶相應(yīng)的積分或虛擬貨幣。
- 兌換失敗后的貨幣回滾：在兌換失敗時(shí)，將扣除的積分或虛擬貨幣返還給用戶。
即黃色箭頭及模塊是由商城側(cè)發(fā)起，調(diào)用上游接入應(yīng)用，由上游應(yīng)用處理相關(guān)邏輯，然后通知商城成功與否。
圖片
RPC調(diào)用迭代
1.0版本
在最初的版本中，黃色模塊（如前置自定義檢查、扣減貨幣、回滾操作）的實(shí)現(xiàn)方式較為繁瑣。具體流程如下：
- 上游業(yè)務(wù)方提供protobuf文件：每個(gè)新接入的業(yè)務(wù)方需要提供自己的protobuf文件。
- 生成go-grpc的server及client端樁代碼：根據(jù)protobuf文件生成go-grpc的server和client端樁代碼。
- 商城服務(wù)編寫(xiě)代碼調(diào)用client端樁代碼：在商城服務(wù)中編寫(xiě)代碼，調(diào)用client端樁代碼發(fā)起RPC調(diào)用。
這種實(shí)現(xiàn)方式存在以下問(wèn)題：
- 開(kāi)發(fā)成本高：每次新接入一個(gè)業(yè)務(wù)，都需要在商城服務(wù)和接入方同時(shí)編寫(xiě)代碼。
- 維護(hù)復(fù)雜：隨著業(yè)務(wù)接入數(shù)量的增加，代碼維護(hù)和管理的復(fù)雜度顯著提升。
圖片
2.0版本
為了減少商城側(cè)的開(kāi)發(fā)成本，我們借鑒了Java的SPI（Service Provider Interface）概念，對(duì)RPC調(diào)用進(jìn)行了優(yōu)化。具體實(shí)現(xiàn)如下：
- 商城統(tǒng)一生成protobuf的server端代碼：商城統(tǒng)一生成protobuf的server端代碼，作為服務(wù)提供者接口。
- 活動(dòng)模塊統(tǒng)一配置調(diào)用路由：在商城服務(wù)的活動(dòng)模塊中，統(tǒng)一配置調(diào)用路由，實(shí)現(xiàn)服務(wù)的動(dòng)態(tài)路由和調(diào)用。
- 接入方引用protobuf生成的server端樁代碼：每次有新業(yè)務(wù)接入，接入方只需引用對(duì)應(yīng)protobuf生成的server端樁代碼，并通過(guò)反向注冊(cè)機(jī)制實(shí)現(xiàn)服務(wù)的注冊(cè)和調(diào)用。
這種實(shí)現(xiàn)方式帶來(lái)了以下優(yōu)勢(shì)：
- 開(kāi)發(fā)成本降低 ：商城層無(wú)需再為每個(gè)新接入的業(yè)務(wù)編寫(xiě)代碼，只需進(jìn)行應(yīng)用配置。
- 維護(hù)簡(jiǎn)化 ：通過(guò)統(tǒng)一的服務(wù)提供者接口和調(diào)用路由，代碼維護(hù)和管理的復(fù)雜度顯著降低。
- 擴(kuò)展性強(qiáng) ：新業(yè)務(wù)的接入更加便捷，系統(tǒng)的擴(kuò)展性和靈活性得到提升。
通過(guò)這種優(yōu)化，我們不僅實(shí)現(xiàn)了RPC調(diào)用的高效復(fù)用，還為未來(lái)的業(yè)務(wù)擴(kuò)展和系統(tǒng)優(yōu)化奠定了堅(jiān)實(shí)的基礎(chǔ)。這種模塊化、可配置的設(shè)計(jì)理念，不僅提升了開(kāi)發(fā)效率，還增強(qiáng)了系統(tǒng)的靈活性和可擴(kuò)展性。
圖片
庫(kù)存設(shè)計(jì)迭代
一開(kāi)始庫(kù)存只有每日及總庫(kù)存的概念，實(shí)現(xiàn)也比較簡(jiǎn)單。為了保障庫(kù)存扣減的并發(fā)安全，使用Redis作為庫(kù)存的存儲(chǔ)。具體的庫(kù)存扣減則通過(guò)提前設(shè)置好Redis值并不斷扣減即可。由于Redis的單線程特性，也不用擔(dān)心并發(fā)重復(fù)扣減的風(fēng)險(xiǎn)。Redis一直扣減直至數(shù)值小于0就表示庫(kù)存已被耗盡。
rest, err := redis.decr(key)
if err {
...
return err
}
if rest < 0 {
return limitErr
}而后需求迭代中出現(xiàn)了分時(shí)間段庫(kù)存，每天需要分成多個(gè)時(shí)段來(lái)分配庫(kù)存，每個(gè)時(shí)間段的庫(kù)存如果未被耗盡會(huì)累積到下一個(gè)時(shí)段。這個(gè)時(shí)候通過(guò)簡(jiǎn)單的Decr命令就不能滿足需求了。
- 方案一 ：為每個(gè)時(shí)段單獨(dú)設(shè)置一個(gè)Redis的key，但這樣會(huì)導(dǎo)致某個(gè)時(shí)段的庫(kù)存被浪費(fèi)，不符合功能需求。要實(shí)現(xiàn)庫(kù)存累積效果，需要在進(jìn)入下一個(gè)時(shí)段時(shí)將上一個(gè)時(shí)段的庫(kù)存加到下一個(gè)時(shí)段，增加了實(shí)現(xiàn)復(fù)雜度。
- 方案二 ：繼續(xù)使用同一個(gè)庫(kù)存key，但需要拆分成兩次Redis命令調(diào)用，首先判斷當(dāng)前時(shí)段的庫(kù)存是否足夠，然后進(jìn)行扣減庫(kù)存。這種非事務(wù)性的執(zhí)行方式可能導(dǎo)致并發(fā)問(wèn)題，難以確保庫(kù)存被準(zhǔn)確扣減。
考慮到實(shí)現(xiàn)成本，我們選擇了方案二。具體邏輯如下：
圖片
- 當(dāng)前剩余未釋放庫(kù)存 = 總庫(kù)存 - 當(dāng)前已釋放庫(kù)存(即timeStock)? 當(dāng)前已釋放庫(kù)存是當(dāng)前已過(guò)時(shí)段各個(gè)庫(kù)存的累加。
- 如果當(dāng)前庫(kù)存 < 當(dāng)前剩余未釋放庫(kù)存，表示當(dāng)前時(shí)段已無(wú)可使用庫(kù)存，返回-1。
- 否則，返回當(dāng)前剩余未釋放庫(kù)存-1。
圖片
為了解決并發(fā)問(wèn)題，我們引入了Lua腳本，確保庫(kù)存扣減的原子性。
LUA腳本偽代碼：
# KEYS[1] 為 redis的key
# ARGV[1] 為 提前算出的剩余未釋放庫(kù)存
# return的值 < 0 代表庫(kù)存扣減失敗
local _args1 = ARGV[1]
local stock = redis.call('GET', KEYS[1])
if stock < _args1 then
return -1
else
local rest = redis.call('DECR', KEYS[1])
return rest
end
return -1獎(jiǎng)品橫向迭代
圖片
商城內(nèi)部的獎(jiǎng)品都統(tǒng)一維護(hù)在獎(jiǎng)品庫(kù)里，每個(gè)類型的獎(jiǎng)品都有通用屬性和擴(kuò)展屬性，同時(shí)不同的獎(jiǎng)品背后對(duì)應(yīng)著不同的資產(chǎn)，需要有獨(dú)立的發(fā)獎(jiǎng)邏輯(資產(chǎn)發(fā)放)。因此每增加一個(gè)類型的獎(jiǎng)品，不僅需要增加獎(jiǎng)品類型的枚舉，也需要對(duì)接下游資產(chǎn)的發(fā)放功能。
商城從一開(kāi)始便不斷的在新增不同類型的獎(jiǎng)品，從優(yōu)惠券、代金券、津貼，到后面拓展出現(xiàn)金、虛擬獎(jiǎng)品、道具等獎(jiǎng)品。
而一些特殊的獎(jiǎng)品，比如抽獎(jiǎng)券，單獨(dú)實(shí)現(xiàn)一個(gè)發(fā)獎(jiǎng)邏輯就不能實(shí)現(xiàn)一個(gè)完整功能，為此我們還特地拓展出抽獎(jiǎng)券玩法。具體玩法是：用戶需要在開(kāi)獎(jiǎng)前獲得抽獎(jiǎng)券，這時(shí)會(huì)發(fā)放一個(gè)抽獎(jiǎng)碼給用戶，我們會(huì)在指定時(shí)間根據(jù)規(guī)則進(jìn)行開(kāi)獎(jiǎng)并通知獲獎(jiǎng)的用戶。這里除了發(fā)放抽獎(jiǎng)券的邏輯之外，我們還需要一個(gè)獨(dú)立的開(kāi)獎(jiǎng)功能。
開(kāi)獎(jiǎng)流程如下圖：
圖片
抽獎(jiǎng)券的玩法迭代：
抽獎(jiǎng)券玩法的核心在于開(kāi)獎(jiǎng)定時(shí)任務(wù)的邏輯，這類抽獎(jiǎng)券活動(dòng)不同于獎(jiǎng)品兌換，單次活動(dòng)可能有百萬(wàn)人參與，一萬(wàn)人中獎(jiǎng)的情況。那么這樣開(kāi)獎(jiǎng)Job的實(shí)時(shí)計(jì)算量就過(guò)于龐大了，測(cè)試環(huán)境按照這個(gè)量級(jí)進(jìn)行開(kāi)獎(jiǎng)的話，耗時(shí)就已達(dá)到10多分鐘之久。這個(gè)時(shí)長(zhǎng)對(duì)于開(kāi)獎(jiǎng)腳本來(lái)說(shuō)是不可接受的了，不僅用戶體驗(yàn)達(dá)不到預(yù)期，而且時(shí)長(zhǎng)太長(zhǎng)，這段時(shí)間如果服務(wù)一旦出現(xiàn)其他情況(如新功能部署、容器節(jié)點(diǎn)被調(diào)度等)中斷開(kāi)獎(jiǎng)流程更是會(huì)阻塞流程。
為此我們做了以下迭代優(yōu)化：
- 開(kāi)獎(jiǎng)Job的實(shí)時(shí)計(jì)算前置：在用戶兌換抽獎(jiǎng)券時(shí)，系統(tǒng)提前為用戶打好標(biāo)簽，并隨機(jī)計(jì)算出一個(gè)分?jǐn)?shù)。將用戶的分?jǐn)?shù)加入到Redis的有序隊(duì)列中。這樣，在開(kāi)獎(jiǎng)時(shí)只需從有序隊(duì)列中取數(shù)，大大減少了實(shí)時(shí)計(jì)算量。
- 開(kāi)獎(jiǎng)Job引入并發(fā)操作：允許多場(chǎng)次和多獎(jiǎng)品同時(shí)進(jìn)行匹配，顯著提高開(kāi)獎(jiǎng)效率。當(dāng)然，為了避免并發(fā)操作引起的數(shù)據(jù)錯(cuò)亂，在關(guān)鍵流程中加入了Mutex鎖，確保數(shù)據(jù)的一致性和完整性。
- 異常通知與一鍵重開(kāi)功能：在應(yīng)用出現(xiàn)各類意外情況導(dǎo)致開(kāi)獎(jiǎng)流程被阻塞時(shí)，我們會(huì)有異常通知告知負(fù)責(zé)人，并提供一鍵重開(kāi)的功能。
最終效果：經(jīng)過(guò)以上優(yōu)化，正式版上線時(shí)，100萬(wàn)人的開(kāi)獎(jiǎng)時(shí)長(zhǎng)從10多分鐘縮短了30倍，僅需20秒即可完成開(kāi)獎(jiǎng)。這不僅大幅提升了用戶體驗(yàn)，還增強(qiáng)了系統(tǒng)的穩(wěn)定性和可靠性。
兌換防刷迭代
針對(duì)于防刷策略，項(xiàng)目從最開(kāi)始只是通過(guò)接口驗(yàn)簽及H5參數(shù)加密進(jìn)行防控，但這種方式的破解成本比較低，也很容易被黑灰產(chǎn)刷接口。到后面我們便系統(tǒng)梳理了從業(yè)務(wù)層、接口層及黑灰產(chǎn)防控三方面對(duì)代碼進(jìn)行加固。
- 業(yè)務(wù)層防刷? 首先是獎(jiǎng)品維度的頻控，這是基于3.2-業(yè)務(wù)架構(gòu)概述中模板模型實(shí)現(xiàn)的，包含每日頻次、周期循環(huán)頻次以及總頻次。? 其次是活動(dòng)維度的頻控，這個(gè)是在兌換流程中，商城中臺(tái)給業(yè)務(wù)方提供了開(kāi)放能力。在兌換前置環(huán)節(jié)可以自定義校驗(yàn)邏輯，比如N天可兌換N次。
圖片
圖片
- 接口層防刷? 這個(gè)主要是依賴于得物統(tǒng)一的流控中心，可以針對(duì)于單個(gè)接口配置限流和熔斷策略，這里就不過(guò)多贅述了。
- 黑灰產(chǎn)防控? 針對(duì)于這部分流量，我們首先是通過(guò)接口驗(yàn)簽和時(shí)間校驗(yàn)先過(guò)濾一部分。? 其次是針對(duì)IP及設(shè)備的黑名單過(guò)濾。? 還有就是針對(duì)于高價(jià)值獎(jiǎng)品，我們會(huì)在前置環(huán)節(jié)預(yù)埋token，只有通過(guò)正常流程的用戶才能進(jìn)行兌換。
項(xiàng)目穩(wěn)定性建設(shè)
商城作為一個(gè)潛在的資損高危區(qū)，在穩(wěn)定性建設(shè)上投入大量資源是必要的。本文我們首先聚焦于問(wèn)題發(fā)現(xiàn)及應(yīng)急止血方面的工作，包括通過(guò)監(jiān)控和告警快速發(fā)現(xiàn)問(wèn)題，以及通過(guò)一鍵止損開(kāi)關(guān)及時(shí)對(duì)發(fā)生異常的業(yè)務(wù)進(jìn)行熔斷。
監(jiān)控告警
在監(jiān)控告警方面，我們采用了多種技術(shù)手段來(lái)確保系統(tǒng)的穩(wěn)定性和及時(shí)發(fā)現(xiàn)潛在問(wèn)題：
業(yè)務(wù)監(jiān)控組件：對(duì)于一些明細(xì)數(shù)據(jù)的同環(huán)比對(duì)比，我們使用了得物通用的業(yè)務(wù)監(jiān)控組件。這種組件能夠?qū)崟r(shí)監(jiān)控業(yè)務(wù)數(shù)據(jù)的變化，幫助我們快速發(fā)現(xiàn)異常情況。
Prometheus SDK埋點(diǎn)：對(duì)于一些需要分位數(shù)統(tǒng)計(jì)的數(shù)據(jù)，我們使用了Golang的Prometheus SDK進(jìn)行埋點(diǎn)，并統(tǒng)一收集上報(bào)。
最終這些數(shù)據(jù)統(tǒng)一接入到增長(zhǎng)的監(jiān)控大盤中，能夠清晰地看到各個(gè)接入方實(shí)時(shí)的訪問(wèn)數(shù)據(jù)、兌換數(shù)量及面額等。
告警配置：根據(jù)采集到的數(shù)據(jù)，我們根據(jù)規(guī)則指標(biāo)制作了各類告警通知，確保在異常情況發(fā)生時(shí)能夠及時(shí)響應(yīng)：
- 事前預(yù)警 ：獎(jiǎng)品庫(kù)存的實(shí)時(shí)通知與查看，確保庫(kù)存充足。
- 事中告警 ：獎(jiǎng)品數(shù)量及金額的同環(huán)比變化，及時(shí)發(fā)現(xiàn)異常波動(dòng)。
- 事后統(tǒng)計(jì) ：獎(jiǎng)品的核銷率及T+1天金額對(duì)賬，確保數(shù)據(jù)準(zhǔn)確無(wú)誤。
圖片
圖片
圖片
|
|
一鍵止損開(kāi)關(guān)
為了在發(fā)生異常時(shí)能夠快速響應(yīng)，我們引入了一鍵止損開(kāi)關(guān)。這個(gè)開(kāi)關(guān)能夠在檢測(cè)到異常情況時(shí)，立即對(duì)相關(guān)業(yè)務(wù)進(jìn)行熔斷，防止資損進(jìn)一步擴(kuò)大。通過(guò)這種機(jī)制，我們能夠在最短時(shí)間內(nèi)控制問(wèn)題，減少損失。
五、更多拓展
抽獎(jiǎng)組件搭建器
為了進(jìn)一步提升抽獎(jiǎng)玩法的易用性和靈活性，我們與前端團(tuán)隊(duì)聯(lián)合打造了可視化的H5抽獎(jiǎng)組件。該組件基于商城中臺(tái)，提供了完整的抽獎(jiǎng)解決方案，運(yùn)營(yíng)人員只需按照SOP文檔進(jìn)行配置，即可快速接入抽獎(jiǎng)玩法并投入使用，真正實(shí)現(xiàn)了抽獎(jiǎng)玩法的“開(kāi)箱即用”。
產(chǎn)品特性：
- 開(kāi)箱即用： 提供完整的前后端組件， 支持九宮格/翻拍/老虎機(jī)等樣式；
- 中獎(jiǎng)控制： 中獎(jiǎng)次數(shù)及中獎(jiǎng)?lì)l次控制；
- 庫(kù)存控制： 獎(jiǎng)品每日/總庫(kù)存控制， 分時(shí)段釋放；
- 多種獎(jiǎng)品： 優(yōu)惠券/代金券/津貼/虛擬獎(jiǎng)品等；
部分組件樣式如下，也支持在可視化的H5搭建器內(nèi)自定義組件樣式。
圖片
在抽獎(jiǎng)組件的設(shè)計(jì)中，抽獎(jiǎng)次數(shù)的獲取是一個(gè)關(guān)鍵環(huán)節(jié)。最初，這一功能完全依賴于業(yè)務(wù)方自行實(shí)現(xiàn)，這導(dǎo)致只有已經(jīng)接入過(guò)商城玩法的業(yè)務(wù)方才能使用H5的抽獎(jiǎng)組件。為了提升組件的通用性和易用性，我們進(jìn)行了以下優(yōu)化：
引入增長(zhǎng)的任務(wù)中臺(tái)
為了簡(jiǎn)化抽獎(jiǎng)次數(shù)的獲取流程，我們引入了增長(zhǎng)的任務(wù)中臺(tái)。通過(guò)這一中臺(tái)，用戶可以完成配置的指定任務(wù)來(lái)獲得積分，這些積分可以直接用于參與抽獎(jiǎng)。
圖片
打造簡(jiǎn)易的積分系統(tǒng)
我們打造了一個(gè)完整的積分系統(tǒng)，實(shí)現(xiàn)了從獲得積分、消耗積分到領(lǐng)取獎(jiǎng)勵(lì)的閉環(huán)流程。具體實(shí)現(xiàn)如下：
- 獲得積分：用戶通過(guò)完成指定任務(wù)（任務(wù)中臺(tái)提供了非常豐富的任務(wù)類型）獲得積分。
- 消耗積分：用戶使用積分參與抽獎(jiǎng)，系統(tǒng)自動(dòng)扣除相應(yīng)積分。
- 領(lǐng)取獎(jiǎng)勵(lì)：用戶中獎(jiǎng)后，系統(tǒng)自動(dòng)發(fā)放獎(jiǎng)品，完成整個(gè)抽獎(jiǎng)流程。
這種閉環(huán)流程的設(shè)計(jì)帶來(lái)了多重優(yōu)勢(shì)：
- 簡(jiǎn)化接入流程 ：業(yè)務(wù)方無(wú)需自行實(shí)現(xiàn)抽獎(jiǎng)次數(shù)的獲取邏輯，降低了接入成本。
- 增強(qiáng)通用性 ：所有業(yè)務(wù)方都可以通過(guò)積分系統(tǒng)使用H5抽獎(jiǎng)組件，提升了組件的適用范圍。
六、總結(jié)
本文講述了增長(zhǎng)兌換商城整體的業(yè)務(wù)框架及部分功能的實(shí)現(xiàn)細(xì)節(jié)。兌換商城作為一個(gè)中臺(tái)，承接了不同上下游提出的需求，很多功能的實(shí)現(xiàn)都需要考慮到通用性及拓展性，而一些復(fù)雜需求或功能的實(shí)現(xiàn)，是否會(huì)加重配置的難度，影響后續(xù)業(yè)務(wù)方的接入成本，都是需要在項(xiàng)目迭代中不斷思考的問(wèn)題。不僅如此，在迭代過(guò)程中的穩(wěn)定性保障也會(huì)是商城自始至終的基本要求。
對(duì)于兌換商城之后的規(guī)劃：
- 拓展玩法：引入更潮流、更具吸引力的玩法，以保持用戶的持續(xù)參與和新鮮感。通過(guò)不斷創(chuàng)新，確保商城始終處于用戶增長(zhǎng)的前沿。
- 降本提效：輸出簡(jiǎn)版玩法及后臺(tái)配置，維護(hù)每個(gè)版本的Changelog及SOP文檔，確保迭代過(guò)程透明且可追溯。精簡(jiǎn)業(yè)務(wù)接入流程，減少開(kāi)發(fā)成本和維護(hù)成本，提升整體效率。
- 交流進(jìn)步：本文作為大綱綜述，簡(jiǎn)要的講解了兌換商城整體的架構(gòu)，后續(xù)將輸出更深入的博客文章，詳細(xì)探討兌換商城的核心技術(shù)實(shí)現(xiàn)、優(yōu)化策略。通過(guò)不斷的技術(shù)交流，促進(jìn)項(xiàng)目的成熟和優(yōu)化，確保商城系統(tǒng)的高效穩(wěn)定運(yùn)行。
