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

摘要：話費、流量等數(shù)字商品已成為日常生活中不可或缺的部分，在線購買交易量級不斷攀升，對交易系統(tǒng)業(yè)務(wù)邏輯的高效性、安全性也提出了更高要求，結(jié)合“面向?qū)ο蟪绦蜷_發(fā)實戰(zhàn)”教學(xué)目標(biāo)，對系統(tǒng)業(yè)務(wù)邏輯框架進(jìn)行了分析與設(shè)計，制定開發(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ù)字商品；交易平臺；業(yè)務(wù)框架

隨著通信技術(shù)的發(fā)展以及移動互聯(lián)網(wǎng)應(yīng)用軟件的大量出現(xiàn)，廣大手機(jī)用戶，特別是年輕用戶更傾向于在移動終端進(jìn)行話費及流量等數(shù)字商品的購買消費，傳統(tǒng)的營業(yè)廳繳費、充值卡繳費等方式逐漸被邊緣化，產(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ù)邏輯，以提高單筆訂單的處理效率，縮短交易時間，給用戶呈現(xiàn)更好的體驗感。通過對話費流量等數(shù)字商品交易業(yè)務(wù)邏輯框架的分析與設(shè)計，使學(xué)生了解更多與生活息息相關(guān)的互聯(lián)網(wǎng)應(yīng)用背后的技術(shù)細(xì)節(jié)，提升學(xué)習(xí)興趣，并在業(yè)務(wù)邏輯實現(xiàn)的過程中提升動手能力，實現(xiàn)課程教學(xué)目的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3結(jié)論

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

參考文獻(xiàn)：

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

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

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

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

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

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