組件式在線票務(wù)平臺

陳玉石

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

1、平臺架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7、結(jié)語

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

參考文獻：

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

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

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