陳玉石

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

1、平臺架構

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

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

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

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

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

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

2、鑒權設計

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

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

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

3、支付模塊設計

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

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

4、訂單模塊設計

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

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

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

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

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

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

5、查詢模塊設計

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

機票的查詢難度在于數(shù)據(jù)量大，變動快，如果前端直接查詢后端數(shù)據(jù)源接口，則會產生很大的查詢時長，因為這包含多個數(shù)據(jù)源的查詢結果計算，這是用戶不能接受的。機票大約有5000個航班，用戶預定周期跨度為一年，數(shù)據(jù)量在180萬左右;如果以二八原則來約束，即80%的機票預定都在一個月內，也有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ù)源獲取后，經過查詢服務的原子層服務接口匯總、計算，統(tǒng)一更新到ElasticSearch模塊中，前端用戶查詢的是ElasticSearch服務，查詢的結果可以進行集合運算，查詢的響應時長如果不計算網絡傳輸時長可以保證200ms的響應速度。

6、結算模塊設計

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

7、結語

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

參考文獻：

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

[2]蔡寶玉.計算機網絡安全技術在電子商務中的應用[J].計算機產品與流通，2020（05）：18.

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