導(dǎo)語(yǔ)：在線數(shù)字商品交易平臺(tái)邏輯框架分析一文來(lái)源于網(wǎng)友上傳，不代表本站觀點(diǎn)，若需要原創(chuàng)文章可咨詢客服老師，歡迎參考。

摘要：話費(fèi)、流量等數(shù)字商品已成為日常生活中不可或缺的部分，在線購(gòu)買交易量級(jí)不斷攀升，對(duì)交易系統(tǒng)業(yè)務(wù)邏輯的高效性、安全性也提出了更高要求，結(jié)合“面向?qū)ο蟪绦蜷_(kāi)發(fā)實(shí)戰(zhàn)”教學(xué)目標(biāo)，對(duì)系統(tǒng)業(yè)務(wù)邏輯框架進(jìn)行了分析與設(shè)計(jì)，制定開(kāi)發(fā)內(nèi)容。業(yè)務(wù)框架主要包括接收上游訂單及查詢業(yè)務(wù)、渠道分配業(yè)務(wù)、渠道發(fā)貨業(yè)務(wù)、接收渠道結(jié)果通知業(yè)務(wù)、向渠道查詢結(jié)果業(yè)務(wù)、向上游通知結(jié)果業(yè)務(wù)等，業(yè)務(wù)邏輯完整，確保安全高效。

關(guān)鍵詞：數(shù)字商品；交易平臺(tái)；業(yè)務(wù)框架

隨著通信技術(shù)的發(fā)展以及移動(dòng)互聯(lián)網(wǎng)應(yīng)用軟件的大量出現(xiàn)，廣大手機(jī)用戶，特別是年輕用戶更傾向于在移動(dòng)終端進(jìn)行話費(fèi)及流量等數(shù)字商品的購(gòu)買消費(fèi)，傳統(tǒng)的營(yíng)業(yè)廳繳費(fèi)、充值卡繳費(fèi)等方式逐漸被邊緣化，產(chǎn)業(yè)結(jié)構(gòu)也逐漸發(fā)生調(diào)整，新的行業(yè)在線交易業(yè)務(wù)模式出現(xiàn)并呈多樣化發(fā)展，業(yè)務(wù)邏輯也不斷完善，在確保交易資金安全的基本前提下，不斷調(diào)整系統(tǒng)模塊結(jié)構(gòu)，優(yōu)化交易業(yè)務(wù)邏輯，以提高單筆訂單的處理效率，縮短交易時(shí)間，給用戶呈現(xiàn)更好的體驗(yàn)感。通過(guò)對(duì)話費(fèi)流量等數(shù)字商品交易業(yè)務(wù)邏輯框架的分析與設(shè)計(jì)，使學(xué)生了解更多與生活息息相關(guān)的互聯(lián)網(wǎng)應(yīng)用背后的技術(shù)細(xì)節(jié)，提升學(xué)習(xí)興趣，并在業(yè)務(wù)邏輯實(shí)現(xiàn)的過(guò)程中提升動(dòng)手能力，實(shí)現(xiàn)課程教學(xué)目的。

1業(yè)務(wù)需求分析

在數(shù)字商品交易發(fā)展的初期，很多業(yè)務(wù)流程處理都是集成在一個(gè)模塊中完成的，從接收上游收單到向渠道發(fā)貨的業(yè)務(wù)邏輯都在統(tǒng)一模塊中順序執(zhí)行完成，此種處理在設(shè)計(jì)上相對(duì)簡(jiǎn)單，所需考慮情況也較少，訂單自始至終都是由一個(gè)工作線程處理，處理速度相對(duì)較慢，在業(yè)務(wù)發(fā)展的初期訂單量不足時(shí)還可接受，但是當(dāng)業(yè)務(wù)量級(jí)增長(zhǎng)到一定階段時(shí)，此種業(yè)務(wù)框架模式的弊端就開(kāi)始顯現(xiàn)，表現(xiàn)在系統(tǒng)不能及時(shí)接收處理上游訂單，或是訂單出現(xiàn)網(wǎng)絡(luò)異常等情形時(shí)人工介入的頻率增加，這些問(wèn)題都直接影響到企業(yè)盈利。因此結(jié)構(gòu)調(diào)整成為必然，將業(yè)務(wù)模塊拆分成多個(gè)模塊，以訂單狀態(tài)變化驅(qū)動(dòng)業(yè)務(wù)流轉(zhuǎn)，各模塊線程以流水線接力的方式完成訂單的消化，這樣的結(jié)構(gòu)在效率及安全性上都有大幅提升。業(yè)務(wù)框架設(shè)計(jì)主要由接收上游訂單及查詢業(yè)務(wù)模塊、渠道分配業(yè)務(wù)模塊、渠道發(fā)貨業(yè)務(wù)模塊、接收渠道結(jié)果通知業(yè)務(wù)模塊、向渠道查詢結(jié)果業(yè)務(wù)模塊、向上游通知結(jié)果業(yè)務(wù)模塊等組成。接收上游訂單及查詢業(yè)務(wù)模塊負(fù)責(zé)接收上游的訂單交易請(qǐng)求以及訂單充值情況查詢請(qǐng)求，兩種請(qǐng)求根據(jù)接口協(xié)議中的命令字段值進(jìn)行區(qū)分，收單業(yè)務(wù)經(jīng)過(guò)一定校驗(yàn)處理后在自身數(shù)據(jù)庫(kù)中生成對(duì)應(yīng)的訂單記錄繼續(xù)充值過(guò)程，接收查詢業(yè)務(wù)則負(fù)責(zé)在本系統(tǒng)查詢上游訂單的充值結(jié)果并按協(xié)議返回?cái)?shù)據(jù)。渠道分配業(yè)務(wù)模塊用于根據(jù)生成的訂單記錄中的交易要素選擇最優(yōu)的下游渠道或下游運(yùn)營(yíng)商進(jìn)行交易，由于所選擇的渠道未必都可交易成功，因此該過(guò)程可能會(huì)重復(fù)多次，但是每次執(zhí)行都會(huì)在數(shù)據(jù)庫(kù)中生成對(duì)應(yīng)訂單流水記錄，用于記錄當(dāng)次選擇的渠道信息。渠道發(fā)貨業(yè)務(wù)模塊負(fù)責(zé)根據(jù)選擇的渠道信息向該渠道發(fā)送交易網(wǎng)絡(luò)請(qǐng)求，并記錄下游響應(yīng)情況。接收渠道結(jié)果通知業(yè)務(wù)模塊用于異步的交易方式，被動(dòng)接收渠道對(duì)交易訂單的完成情況。向渠道查詢結(jié)果業(yè)務(wù)模塊同樣用于異步交易方式，主動(dòng)向下游查詢訂單完成情況。向上游通知結(jié)果業(yè)務(wù)模塊用于將自身數(shù)據(jù)庫(kù)接收的上游訂單的完成情況主動(dòng)告知上游，實(shí)現(xiàn)訂單的完結(jié)。

2業(yè)務(wù)邏輯詳細(xì)設(shè)計(jì)

交易系統(tǒng)業(yè)務(wù)框架模塊圖如圖1所示，主要由6個(gè)業(yè)務(wù)模塊構(gòu)成，下文將從流程圖的角度對(duì)各個(gè)模塊的業(yè)務(wù)邏輯進(jìn)行設(shè)計(jì)說(shuō)明。

2.1接收上游訂單及查詢業(yè)務(wù)模塊

本業(yè)務(wù)模塊是交易訂單進(jìn)入平臺(tái)的唯一入口，安全性是首先需要考慮的，因此在收到請(qǐng)求時(shí)先提取出命令字、上游編號(hào)及上游訂單號(hào)、上游產(chǎn)品編號(hào)、充值號(hào)碼等信息，根據(jù)上游編號(hào)在數(shù)據(jù)庫(kù)中查找對(duì)應(yīng)上游信息，判斷上游狀態(tài)是否正常，本次請(qǐng)求IP是否在上游請(qǐng)求IP白名單內(nèi)，對(duì)請(qǐng)求數(shù)據(jù)進(jìn)行簽名校驗(yàn)等安全驗(yàn)證操作，通過(guò)后再根據(jù)命令字進(jìn)行后續(xù)處理。若是充值命令，首先根據(jù)上游編號(hào)及上游訂單號(hào)在數(shù)據(jù)庫(kù)訂單表中查詢是否已存在該筆訂單記錄，若存在則按照接口協(xié)議進(jìn)行報(bào)文回復(fù)，不做其他處理，如不存在則進(jìn)行新訂單入庫(kù)操作。訂單入庫(kù)邏輯為：首先對(duì)充值號(hào)碼進(jìn)行白名單及當(dāng)日充值額度上限檢查，若不通過(guò)則返回報(bào)文，流程結(jié)束；若通過(guò)則根據(jù)上游產(chǎn)品編號(hào)在平臺(tái)產(chǎn)品表中查找平臺(tái)產(chǎn)品編號(hào)、運(yùn)營(yíng)商、省份等信息，同時(shí)生成對(duì)應(yīng)的系統(tǒng)訂單號(hào)，將這些信息插入系統(tǒng)訂單表及訂單發(fā)貨隊(duì)列表，訂單表記錄及隊(duì)列表記錄狀態(tài)置為等待選擇渠道。訂單表記錄保存訂單的詳細(xì)信息，該表屬于大表，信息永久保留。訂單發(fā)貨隊(duì)列表主要記錄訂單狀態(tài)，提高搜索速度，記錄在訂單完結(jié)時(shí)會(huì)刪除。收單業(yè)務(wù)在保證安全的前提下，盡量縮短業(yè)務(wù)處理邏輯，節(jié)省時(shí)間，提高收單效率。若是查詢命令，則根據(jù)上游編號(hào)及訂單號(hào)在訂單表中查詢記錄是否存在，若沒(méi)有則回復(fù)訂單不存在，若存在則根據(jù)訂單結(jié)果（充值成功、充值失敗、充值中）組織相應(yīng)報(bào)文進(jìn)行回復(fù)，完成業(yè)務(wù)處理。流程圖如圖2所示。

2.2渠道分配業(yè)務(wù)模塊

渠道分配業(yè)務(wù)模塊從訂單發(fā)貨隊(duì)列表中查找狀態(tài)為等待選擇渠道的記錄信息集合，通過(guò)訂單號(hào)在渠道發(fā)貨流水表中查找該筆訂單的所有發(fā)貨流水記錄信息。統(tǒng)計(jì)發(fā)貨次數(shù)是否超過(guò)限制，若超過(guò)限制則將訂單置為失敗，修改相關(guān)表狀態(tài)后不再進(jìn)行處理；若沒(méi)有超過(guò)限制，則根據(jù)訂單表記錄里的面值、省份、運(yùn)營(yíng)商等信息在渠道表里查找有支持對(duì)應(yīng)產(chǎn)品的渠道信息集合，并按照渠道分流比由大到小的順序?qū)Y(jié)果進(jìn)行排序，優(yōu)先向優(yōu)質(zhì)渠道發(fā)貨以提高成功率。然后逐個(gè)取出集合中的記錄，判斷渠道當(dāng)前是否可用，不可用則判斷下一個(gè)，可用則判斷當(dāng)前渠道是否在已嘗試發(fā)貨流水記錄中存在，若存在則判斷下一個(gè)，當(dāng)集合都遍歷后仍無(wú)符合條件渠道，則將訂單置為失敗處理；若不存在則作為本次待發(fā)送的渠道，停止判斷，立即將隊(duì)列表記錄鎖定，判斷訂單狀態(tài)是否為等待選擇渠道，若不是則將發(fā)貨隊(duì)列狀態(tài)修改為分配渠道中，再根據(jù)選擇的渠道號(hào)在渠道產(chǎn)品表中查找對(duì)應(yīng)渠道產(chǎn)品編號(hào)等信息，生成本次渠道發(fā)貨流水號(hào)，將渠道號(hào)、訂單號(hào)、渠道發(fā)貨流水號(hào)、渠道產(chǎn)品編號(hào)、流水狀態(tài)等信息插入渠道發(fā)貨流水記錄表，記錄狀態(tài)為等待發(fā)貨，同時(shí)將訂單表及隊(duì)列表中的記錄狀態(tài)修改為等待發(fā)貨，以便進(jìn)行下一步處理。流程圖如圖3所示。

2.3渠道發(fā)貨業(yè)務(wù)模塊

渠道發(fā)貨業(yè)務(wù)模塊從訂單發(fā)貨隊(duì)列表中查找狀態(tài)為等待發(fā)貨的記錄信息集合，對(duì)集合中的每條記錄查詢鎖定并判斷訂單記錄狀態(tài)是否為等待發(fā)貨、流水記錄狀態(tài)是否為等待發(fā)貨，狀態(tài)無(wú)誤則將發(fā)貨隊(duì)列狀態(tài)修改為發(fā)貨中。再根據(jù)流水表中渠道號(hào)，查詢對(duì)應(yīng)渠道發(fā)貨地址、簽名秘鑰等信息，按照接口協(xié)議組織報(bào)文發(fā)送請(qǐng)求，并根據(jù)渠道響應(yīng)的信息修改相關(guān)表狀態(tài)。若發(fā)貨成功，則將訂單表記錄、隊(duì)列表記錄、流水表記錄狀態(tài)都修改為等待充值結(jié)果，等待渠道異步返回充值結(jié)果。若發(fā)貨失敗則將訂單表記錄及隊(duì)列表記錄狀態(tài)修改為等待選擇渠道，流水表記錄狀態(tài)修改為發(fā)貨失敗，等待再次嘗試。若未接收到響應(yīng)報(bào)文，則按發(fā)貨成功處理。流程圖如圖4所示。

2.4接收渠道結(jié)果通知業(yè)務(wù)模塊

接收渠道結(jié)果通知業(yè)務(wù)模塊用于接收渠道發(fā)送的訂單充值結(jié)果，通知的結(jié)果情形只有成功和失敗。簽名校驗(yàn)后，根據(jù)接口協(xié)議中的訂單發(fā)貨流水號(hào)，找到相應(yīng)的訂單發(fā)貨流水記錄、訂單記錄、訂單發(fā)貨隊(duì)列記錄，判斷三個(gè)記錄的狀態(tài)是否都為等待充值結(jié)果，若不一致則等待人工核實(shí)處理，若一致則根據(jù)充值結(jié)果進(jìn)行相應(yīng)處理。若充值成功，則將訂單表記錄、發(fā)貨流水記錄狀態(tài)修改為充值成功，若充值失敗，則將兩個(gè)記錄狀態(tài)修改為充值失敗，再將訂單發(fā)貨隊(duì)列記錄刪除，同時(shí)插入訂單通知隊(duì)列記錄，狀態(tài)為等待通知上游，等待將結(jié)果通知給上游。流程圖如圖5所示。

2.5向渠道查詢結(jié)果業(yè)務(wù)模塊

向渠道查詢結(jié)果業(yè)務(wù)模塊作為接收渠道結(jié)果通知模塊的補(bǔ)充，在長(zhǎng)時(shí)間沒(méi)有收到渠道結(jié)果通知的情況下主動(dòng)向渠道發(fā)起結(jié)果查詢請(qǐng)求，在訂單發(fā)貨隊(duì)列表中查找狀態(tài)為等待充值結(jié)果且更新時(shí)間超過(guò)設(shè)定間隔時(shí)間的記錄進(jìn)行查詢，并根據(jù)查詢結(jié)果及時(shí)更新訂單相關(guān)狀態(tài)，避免因渠道通知模塊異常造成訂單未及時(shí)完結(jié)，導(dǎo)致訂單交易耗時(shí)延長(zhǎng)。查詢到結(jié)果后的處理和渠道主動(dòng)通知結(jié)果處理相同，只是在異常情況下出現(xiàn)返回查詢結(jié)果為訂單不存在時(shí)，就需要人工核對(duì)溝通處理。訂單狀態(tài)修改與接收渠道通知業(yè)務(wù)基本一致，不再贅述，流程圖與圖5相似，未單獨(dú)畫(huà)出。

2.6向上游通知結(jié)果業(yè)務(wù)模塊

在系統(tǒng)內(nèi)訂單結(jié)果明確后就要將該充值結(jié)果通知給上游，在通知隊(duì)列表中查詢狀態(tài)為等待通知上游且通知次數(shù)少于限定次數(shù)的記錄，分配給工作線程，鎖定通知隊(duì)列記錄并將狀態(tài)修改為通知中，避免被再次篩選出來(lái)。同時(shí)檢查訂單表記錄及發(fā)貨流水記錄狀態(tài)是否同為充值成功或充值失敗，相同時(shí)則按照接口協(xié)議將結(jié)果組包發(fā)送到上游，若上游成功接收并響應(yīng)則將訂單表記錄中是否通知上游狀態(tài)改為是，同時(shí)刪除通知隊(duì)列記錄，訂單邏輯完結(jié)；單表記錄及發(fā)貨流水記錄狀態(tài)不同時(shí)則將通知隊(duì)列狀態(tài)修改為等待通知上游，同時(shí)通知次數(shù)加1，等待再次通知。流程圖如圖6所示。

3結(jié)論

本文對(duì)數(shù)字交易平臺(tái)業(yè)務(wù)邏輯框架進(jìn)行了分析與設(shè)計(jì)，根據(jù)高內(nèi)聚、低耦合的原則設(shè)計(jì)業(yè)務(wù)模塊，以狀態(tài)變化驅(qū)動(dòng)業(yè)務(wù)流轉(zhuǎn)，保證交易安全的同時(shí)提高訂單處理效率。本案例應(yīng)用在“面向?qū)ο蟪绦蜷_(kāi)發(fā)實(shí)戰(zhàn)”課程實(shí)踐中，作為實(shí)踐內(nèi)容，在鍛煉學(xué)生動(dòng)手能力的同時(shí)，培養(yǎng)團(tuán)隊(duì)協(xié)作精神。

參考文獻(xiàn)：

[1]吳杰明，方英蘭.軟件工程實(shí)例教程[M].北京：清華大學(xué)出版社，2010.

[2]羅小利，吳清烈.SaaS軟件服務(wù)基于大規(guī)模定制的業(yè)務(wù)邏輯框架研究[J].電信科學(xué)，2011，27（9）：26-31.

[3]陳偉，沈備軍，戚正偉.面向SaaS應(yīng)用的業(yè)務(wù)邏輯定制框架的研究與實(shí)現(xiàn)[J].計(jì)算機(jī)應(yīng)用研究，2011，28（1）：155-158.

[4]張榮，孫家澤.電信增值業(yè)務(wù)框架中業(yè)務(wù)邏輯的設(shè)計(jì)[J].西安郵電學(xué)院學(xué)報(bào)，2008（3）：111-113.

[5]吳立春.基于Facade模式的業(yè)務(wù)邏輯層框架設(shè)計(jì)[J].微計(jì)算機(jī)信息，2007（24）：245-246+308.

作者：謝劍 單位：湖南信息職業(yè)技術(shù)學(xué)院