陳玉石

摘要：OTA是用戶在線差旅平臺(tái)，一般包含機(jī)票、火車票、酒店的預(yù)定，具有相當(dāng)?shù)臉I(yè)務(wù)復(fù)雜度，對(duì)數(shù)據(jù)的準(zhǔn)確性、實(shí)時(shí)性有很高的要求。各電商或者其他品類的渠道增加這樣的產(chǎn)品具有很高的業(yè)務(wù)復(fù)雜度和運(yùn)營(yíng)復(fù)雜度，為此我們研發(fā)了一套組件式在線票務(wù)平臺(tái)，標(biāo)準(zhǔn)化了用戶鑒權(quán)模式、支付模式和訂單模式[1]，既支持以H5或PCWEB的方式和第三方對(duì)接，也支持以接口的方式和渠道側(cè)對(duì)接，大大豐富了渠道側(cè)的產(chǎn)品能力和運(yùn)營(yíng)能力。

1、平臺(tái)架構(gòu)

在線票務(wù)平臺(tái)分為用戶面、管理面和運(yùn)營(yíng)面，三面隔離。用戶面為渠道側(cè)客戶的Portal，管理面為渠道側(cè)管理Portal，運(yùn)營(yíng)面為平臺(tái)運(yùn)營(yíng)Portal。用戶面接入的Portal分為H5和PCWeb類型，前端采用vuemint輕量級(jí)框架。用戶面的Portal分為機(jī)票預(yù)定前端FlightPortal、火車票預(yù)定前端TrainPortal、酒店預(yù)定前端HotelPortal，分別對(duì)應(yīng)不同的二級(jí)域名;渠道側(cè)前端CustomerPortal，運(yùn)營(yíng)前端OperatorPortal，也分別對(duì)應(yīng)不同的二級(jí)域名以及鑒權(quán)方式。

編排層包含用戶面機(jī)票編排層、用戶面火車票編排層、用戶面酒店編排層，用戶面的三個(gè)編排層彼此獨(dú)立，不能互相調(diào)用，只能由前端發(fā)起編排層的調(diào)用。渠道側(cè)編排層和運(yùn)營(yíng)面的編排層也彼此獨(dú)立，不能相互訪問。

從前端到編排層經(jīng)過網(wǎng)關(guān)鑒權(quán)，下文有對(duì)鑒權(quán)的敘述。編排層下是各個(gè)原子層服務(wù)，包含機(jī)票查詢服務(wù)FlightQueryService、機(jī)票標(biāo)準(zhǔn)數(shù)據(jù)查詢服務(wù)FlightFIQueryService、機(jī)票O(jiān)TA查詢服務(wù)FlightOTAQueryService、機(jī)票自有數(shù)據(jù)查詢服務(wù)FlightCrawlerQueryService等，火車票的原子層服務(wù)包含火車票查詢服務(wù)TrainQueryService、火車OTA查詢服務(wù)TrainOTAQueryService、火車票自有數(shù)據(jù)查詢服務(wù)TrainCrawlerQueryService等;酒店查詢服務(wù)包含HotelQueryService，酒店OTA查詢服務(wù)HotelOTAQueryService，酒店自有數(shù)據(jù)查詢服務(wù)HotelCrawlerQueryService。訂單模塊包含機(jī)票訂單服務(wù)FlightOrderService、火車票訂單服務(wù)TrainOrderService、酒店訂單服務(wù)HotelOrderService;標(biāo)準(zhǔn)訂單原子服務(wù)OrderService，訂單服務(wù)既支持正向訂單也支持逆向訂單。

平臺(tái)還包含網(wǎng)關(guān)鑒權(quán)服務(wù)AuthService，各個(gè)業(yè)務(wù)的邊緣服務(wù)FlightEdgeService、TrainEdgeService、HotelEdgeService。和財(cái)經(jīng)相關(guān)的服務(wù)包含商品服務(wù)ProductService，合同結(jié)構(gòu)化服務(wù)ContractService，結(jié)算服務(wù)SettleService，自有數(shù)據(jù)模塊對(duì)接各個(gè)平臺(tái)的數(shù)據(jù)服務(wù)接口，統(tǒng)一整合后存儲(chǔ)到NoSQL數(shù)據(jù)庫中，商品、訂單等服務(wù)采用關(guān)系型SQL數(shù)據(jù)庫，各個(gè)原子服務(wù)彼此不能互相調(diào)用，通過編排層統(tǒng)一調(diào)用或通過MQ實(shí)現(xiàn)數(shù)據(jù)狀態(tài)的一致性。

前端所有的操作全部打點(diǎn)，打點(diǎn)的數(shù)據(jù)內(nèi)容不包含用戶個(gè)人數(shù)據(jù)，打點(diǎn)的數(shù)據(jù)上報(bào)到大數(shù)據(jù)中心BGC，但是不進(jìn)行用戶的畫像。管理面所有的操作日志全部打點(diǎn)，并接受審計(jì)，管理面的日志數(shù)據(jù)存儲(chǔ)期限為三年，用戶面的日志存儲(chǔ)期限為一年。

平臺(tái)的配置中心服務(wù)為ConfigService，ConfigService對(duì)接Redis;各個(gè)服務(wù)的異步通信模塊采用MQ（ActiveMQ）進(jìn)行，前端的查詢數(shù)據(jù)存儲(chǔ)于ElasticSearch;所有數(shù)據(jù)的存儲(chǔ)由各個(gè)微服務(wù)完成，各個(gè)查詢服務(wù)定時(shí)同步增量數(shù)據(jù)到ElasticSearch，前端各個(gè)預(yù)定模塊例如機(jī)票、火車票、酒店的數(shù)據(jù)來源是ElasticSearch，ElasticSearch提供數(shù)據(jù)并進(jìn)行集合運(yùn)算。

2、鑒權(quán)設(shè)計(jì)

平臺(tái)采用插件的方式對(duì)接到渠道側(cè)，需要和渠道側(cè)打通用戶登錄、支付和訂單模塊。用戶進(jìn)入渠道側(cè)的APP或者其他前端后，通過授權(quán)進(jìn)入我們的預(yù)定頁面，鑒權(quán)的方式采用Auth2.0[2]，每一個(gè)進(jìn)入預(yù)定首頁的用戶都需要進(jìn)行授權(quán)。授權(quán)后用戶訪問預(yù)定各票務(wù)首頁，Portal獲取會(huì)話的cookie;如果沒有獲取到cookie，則直接拉起用戶的授權(quán)頁，如果有cookie則校驗(yàn)cookie中的token，token存在有效期，如果過了有效期，依然拉起授權(quán)頁。

用戶的請(qǐng)求將會(huì)攜帶token，網(wǎng)關(guān)對(duì)token進(jìn)行解析，Portal不解析token，token的密鑰存儲(chǔ)于配置中心，解析的結(jié)果包含用戶相關(guān)信息，例如userId、domain，domain對(duì)應(yīng)了渠道名。用戶對(duì)后臺(tái)所有的非靜態(tài)請(qǐng)求都必須基于網(wǎng)關(guān)，每次請(qǐng)求都會(huì)進(jìn)行鑒權(quán)。渠道側(cè)用戶在Auth后，302到網(wǎng)關(guān)進(jìn)行二

次鑒權(quán)，網(wǎng)關(guān)獲取到用戶的userId、domain以及token，會(huì)再次調(diào)用渠道側(cè)提供的接口進(jìn)行鑒權(quán)，鑒權(quán)后根據(jù)算法生成AuthToken，設(shè)置到header中。后臺(tái)調(diào)用接口必須要有該AuthToken，否則將返回失敗;AuthToken的有效期是30分鐘，30分鐘內(nèi)調(diào)用將重新刷新該token，如果調(diào)用間隔超過30分鐘，將會(huì)重新進(jìn)行鑒權(quán)操作。

3、支付模塊設(shè)計(jì)

用戶在機(jī)票、火車票、酒店前端完成查詢并選擇好對(duì)應(yīng)的產(chǎn)品后，將創(chuàng)建訂單拉起支付，一般來說支付能力由渠道提供，平臺(tái)也提供支付能力，兩種模式的差別主要在于流水和結(jié)算，如果渠道需要鎖定流水，則渠道提供支付能力，并且和平臺(tái)進(jìn)行T+N的結(jié)算模式;如果渠道不需要鎖定流水，則平臺(tái)提供支付能力，和渠道進(jìn)行反向T+N的結(jié)算。

支付模塊的拉起可以分為拉起原生或H5的支付模塊，拉起之前必須要?jiǎng)?chuàng)建訂單，首先在平臺(tái)創(chuàng)建訂單，創(chuàng)建成功后調(diào)用渠道側(cè)的創(chuàng)單接口，并獲取到訂單號(hào)，由渠道側(cè)的訂單號(hào)來拉起支付，拉起支付后產(chǎn)生一個(gè)支付流水號(hào)存入庫中，訂單完成后進(jìn)行結(jié)算，結(jié)算的依據(jù)就是訂單號(hào)、支付流水號(hào)。

4、訂單模塊設(shè)計(jì)

用戶購買機(jī)票、火車票、酒店產(chǎn)品會(huì)產(chǎn)生訂單，如果只在平臺(tái)產(chǎn)生訂單，則渠道側(cè)無法進(jìn)行支付，也無法感知這一筆交易的存在;如果只在渠道側(cè)產(chǎn)生訂單，則平臺(tái)無法感知這一訂單的存在，并且無法進(jìn)行后期的運(yùn)營(yíng)工作。所以一筆訂單在平臺(tái)側(cè)創(chuàng)建后也必須要在渠道側(cè)進(jìn)行創(chuàng)建，用戶提交訂單請(qǐng)求后，首先在平臺(tái)側(cè)創(chuàng)建訂單，創(chuàng)建成功后，調(diào)用渠道側(cè)創(chuàng)建訂單，調(diào)用渠道側(cè)的接口的鑒權(quán)采用AccessToken模式，token來源于用戶登陸后從渠道側(cè)獲取的Token，該token需要定時(shí)刷新，數(shù)據(jù)存儲(chǔ)在Redis中，設(shè)置失效時(shí)間，如果失效了則用戶提交訂單的時(shí)候會(huì)報(bào)錯(cuò)返回授權(quán)頁;如果沒有失效，則刷新token的失效時(shí)間。

渠道側(cè)除了提供創(chuàng)單接口，還需要提供取消訂單、支付完成、申請(qǐng)退款、退款完成、訂單完成等接口。機(jī)票、火車票、酒店的預(yù)定和普通的電商商品預(yù)定有差別，電商商品支付完成后即完成預(yù)定流程，但是票務(wù)的預(yù)定只是占座成功，酒店的預(yù)定需要前臺(tái)確認(rèn)，因此需要產(chǎn)品提供方二次確認(rèn)。確認(rèn)的操作是個(gè)異步的過程，時(shí)間跨度最長(zhǎng)可以是小時(shí)級(jí)別，所以訂單在創(chuàng)建后，仍然需要定時(shí)任務(wù)調(diào)用各個(gè)航空公司預(yù)定查詢接口、火車票預(yù)定查詢接口、酒店的預(yù)定查詢接口，如果預(yù)定失敗，則通過MQ發(fā)送失敗消息，各個(gè)原子層服務(wù)訂閱MQ消息，并進(jìn)行相應(yīng)的處理，既要取消平臺(tái)側(cè)訂單，也需要取消渠道側(cè)訂單。

訂單支付完成后，需要進(jìn)行出票的操作，機(jī)票、火車票、酒店的出票操作也是異步流程，既有自動(dòng)化的出票方式，也有人工的出票方式，出票時(shí)限由具體的業(yè)務(wù)性質(zhì)決定，機(jī)票的出票時(shí)限是飛機(jī)起飛前一個(gè)小時(shí)，火車票的出票時(shí)限是15分鐘，酒店的出票時(shí)限是1個(gè)小時(shí)。其中機(jī)票的出票存在風(fēng)險(xiǎn)，一般90%以上的票要求30分鐘內(nèi)出完，當(dāng)機(jī)票的出票時(shí)長(zhǎng)超過1個(gè)小時(shí)或者臨近出發(fā)6個(gè)小時(shí)以內(nèi)，則進(jìn)入預(yù)警列表，必須要人工介入，否則當(dāng)乘客到場(chǎng)無票則視為重大事故。

訂單的逆向操作即退票操作，是運(yùn)營(yíng)最繁重的工作;當(dāng)用戶申請(qǐng)退票后，首先判斷是否可以退票，如果可以退票則需要進(jìn)行確認(rèn)，因?yàn)闄C(jī)票、火車票、酒店存在很復(fù)雜的退票規(guī)則，根據(jù)退票規(guī)則會(huì)產(chǎn)生手續(xù)費(fèi)，所以必須要用戶確認(rèn)手續(xù)費(fèi)后再進(jìn)行真正的退票操作。其中退票規(guī)則最復(fù)雜的是機(jī)票，例如CA1580航班退票規(guī)則是20-120-50-24-70，代表的含義是如果用戶在機(jī)票起飛之前120小時(shí)退票，則收取機(jī)票款的20%的手續(xù)費(fèi);如果是機(jī)票起飛前24小時(shí)到120小時(shí)內(nèi)申請(qǐng)退票，則收取機(jī)票款的50%的手續(xù)費(fèi);如果是機(jī)票起飛前24小時(shí)內(nèi)含起飛后申請(qǐng)退票，則收取機(jī)票款70%的手續(xù)費(fèi)。不同航司不同航班的退票規(guī)則區(qū)別很大，退票規(guī)則也在不斷變化，用戶在預(yù)定的時(shí)候就需要把退票規(guī)則推送給用戶，因此該規(guī)則存在履行態(tài)和當(dāng)前態(tài)，兩者可能不一致，用戶的訂單以履行態(tài)為基準(zhǔn)，用戶預(yù)定的時(shí)候以當(dāng)前態(tài)為基準(zhǔn)。

當(dāng)用戶確認(rèn)退票后，則進(jìn)行計(jì)算流程，計(jì)算出用戶的手續(xù)費(fèi)和應(yīng)退金額，創(chuàng)建逆向訂單，逆向訂單必須經(jīng)過審核流程，客服審核后確認(rèn)退款，則需要進(jìn)行兩次調(diào)用，一次是調(diào)用票務(wù)方的退票接口，例如各個(gè)航司的退票接口，火車票平臺(tái)的退票接口，酒店平臺(tái)的退票接口;然后啟用定時(shí)任務(wù)查詢退票的狀態(tài)，查詢到退票成功后調(diào)用渠道側(cè)的逆向訂單接口，渠道側(cè)的逆向訂單接口完成最終的為用戶退款操作;如果平臺(tái)側(cè)收款，則退款操作由平臺(tái)側(cè)完成。

就票務(wù)訂單而言可能存在多個(gè)訂單子項(xiàng)，例如機(jī)票的訂單包含機(jī)票款、燃油費(fèi)、機(jī)建費(fèi)、保險(xiǎn)費(fèi)、行李費(fèi)、其他費(fèi)，如果是兒童，兒童的費(fèi)用和成人的費(fèi)用還有差別，兒童一般是按照標(biāo)準(zhǔn)倉位的50%計(jì)算費(fèi)用。那么一個(gè)訂單包含多個(gè)項(xiàng)目，在不同場(chǎng)景下退票的規(guī)則是不一樣的，所以就要求在逆向的場(chǎng)景下，可以針對(duì)子項(xiàng)進(jìn)行退款，但是不同渠道平臺(tái)的支持程度不一樣，所以在設(shè)計(jì)上，既要支持以總賬的形式完成和結(jié)束訂單，也要支持以子項(xiàng)的形式操作訂單。

5、查詢模塊設(shè)計(jì)

就票務(wù)平臺(tái)而言，最復(fù)雜的場(chǎng)景有兩個(gè)，一個(gè)是逆向的訂單場(chǎng)景，一個(gè)就是查詢。機(jī)票、火車票、酒店的查詢規(guī)則差別很大，其中最復(fù)雜的是機(jī)票的查詢場(chǎng)景。機(jī)票的查詢的要求是實(shí)時(shí)性和準(zhǔn)確性。因?yàn)槠脚_(tái)存在多個(gè)數(shù)據(jù)源，包含官方標(biāo)準(zhǔn)倉位價(jià)格數(shù)據(jù)源、各個(gè)供應(yīng)商的折扣數(shù)據(jù)數(shù)據(jù)源、自有折扣倉位數(shù)據(jù)源、航司官網(wǎng)數(shù)據(jù)源等，機(jī)票的價(jià)格既需要參考所有的數(shù)據(jù)源，也要保證實(shí)時(shí)性。

機(jī)票的查詢難度在于數(shù)據(jù)量大，變動(dòng)快，如果前端直接查詢后端數(shù)據(jù)源接口，則會(huì)產(chǎn)生很大的查詢時(shí)長(zhǎng)，因?yàn)檫@包含多個(gè)數(shù)據(jù)源的查詢結(jié)果計(jì)算，這是用戶不能接受的。機(jī)票大約有5000個(gè)航班，用戶預(yù)定周期跨度為一年，數(shù)據(jù)量在180萬左右;如果以二八原則來約束，即80%的機(jī)票預(yù)定都在一個(gè)月內(nèi)，也有15萬的數(shù)據(jù)量，這樣的數(shù)據(jù)量難以做到實(shí)時(shí)，平臺(tái)以500個(gè)線程不斷輪詢各個(gè)數(shù)據(jù)源接口，以增量的形式更新數(shù)據(jù)，每個(gè)數(shù)據(jù)的更新平均時(shí)長(zhǎng)是5S，則一輪數(shù)據(jù)更新平均需要25分鐘;再進(jìn)一步以二八原則約束，即用戶大部分的查詢都會(huì)集中在熱門航線，例如北京上海航線、上海深圳航線、深圳北京航線等，那么這樣就完全可以保證“熱門航線3個(gè)月數(shù)據(jù)的實(shí)時(shí)性”，這個(gè)實(shí)時(shí)性體現(xiàn)在數(shù)據(jù)3分鐘可以更新一輪;次熱門航線數(shù)據(jù)10分鐘可以更新一輪;非熱門航線數(shù)據(jù)1個(gè)小時(shí)更新一輪。

數(shù)據(jù)從數(shù)據(jù)源獲取后，經(jīng)過查詢服務(wù)的原子層服務(wù)接口匯總、計(jì)算，統(tǒng)一更新到ElasticSearch模塊中，前端用戶查詢的是ElasticSearch服務(wù)，查詢的結(jié)果可以進(jìn)行集合運(yùn)算，查詢的響應(yīng)時(shí)長(zhǎng)如果不計(jì)算網(wǎng)絡(luò)傳輸時(shí)長(zhǎng)可以保證200ms的響應(yīng)速度。

6、結(jié)算模塊設(shè)計(jì)

結(jié)算的主體是渠道和平臺(tái)，結(jié)算模塊的設(shè)計(jì)點(diǎn)包含兩個(gè)部分，一個(gè)是合同結(jié)構(gòu)化，一個(gè)是結(jié)算單的推送。合同結(jié)構(gòu)化將渠道和平臺(tái)的合約以結(jié)構(gòu)化的形式呈現(xiàn)，例如雙方的分潤(rùn)模式、結(jié)算周期，分潤(rùn)模式支持階梯分潤(rùn)，結(jié)算模式支持T+N（N>=0），N既可以支持天數(shù)，也可以支持小時(shí)數(shù)。結(jié)算單的推送時(shí)機(jī)是在訂單完成的情況下進(jìn)行推送，訂單完成包含訂單的正向完成和逆向完成;完成后根據(jù)各個(gè)渠道提供的推送接口要求進(jìn)行推送，訂單模塊提供結(jié)算數(shù)據(jù)并生產(chǎn)MQ消息，結(jié)算模塊訂閱MQ消息并完成推送。

7、結(jié)語

組件式在線票務(wù)平臺(tái)提供了多重?cái)?shù)據(jù)源的實(shí)時(shí)查詢能力、票務(wù)的預(yù)定能力和結(jié)算能力，并且打通了渠道側(cè)的用戶和訂單模塊，能夠以配置的方式，提供標(biāo)準(zhǔn)化的接入模型[3]，該方案目前已經(jīng)接入了數(shù)十個(gè)自有流量渠道，預(yù)定首頁的日訪問UV達(dá)到40w/天。

參考文獻(xiàn)：

[1]董恒鑠.企業(yè)信息化管理中計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)的運(yùn)用分析[J].計(jì)算機(jī)產(chǎn)品與流通，2020（05）：11.

[2]蔡寶玉.計(jì)算機(jī)網(wǎng)絡(luò)安全技術(shù)在電子商務(wù)中的應(yīng)用[J].計(jì)算機(jī)產(chǎn)品與流通，2020（05）：18.

[3]周成就.互聯(lián)網(wǎng)模式下的計(jì)算機(jī)應(yīng)用探討[J].計(jì)算機(jī)產(chǎn)品與流通，2020（04）：55.