一種應用于高鐵領域的訂餐服務系統(tǒng)設計

郭 楠

(通號通信信息集團有限公司，北京 100070)

鐵路一直以來都是互聯(lián)網(wǎng)應用較少涉及的領域，目前旅客乘車體驗已經(jīng)隨著高鐵技術、信號技術等的飛速發(fā)展不斷提升，鐵路餐飲方面的體驗提升，必將使客戶滿意度大幅提高。隨著鐵路出行人群的日益龐大，除高鐵目前本身提供的餐飲服務外，還需要利用互聯(lián)網(wǎng)實現(xiàn)旅客有更多的餐飲服務選擇，因此需要穩(wěn)定而高效的系統(tǒng)軟件架構來滿足大規(guī)模并發(fā)請求的要求。同時，鐵路系統(tǒng)中的訂餐與傳統(tǒng)的訂餐網(wǎng)絡存在一些區(qū)別，后者更多的局限在一個城市或者城市的一個區(qū)域，訂單量比較分散。而前者大部分請求是發(fā)生在列車運行過程中，旅客面對的大部分是自己不熟悉的商家，因此訂單的商家會更集中于有品牌效應的商家，發(fā)生訂單擁塞的可能性更大，因此后臺服務需要引導用戶解決訂單沖突，選擇合適的商家及產(chǎn)品，而且，送餐業(yè)務的時間要求更高，需要平臺對于商家完成訂單有嚴格的時間要求。

1 總體功能架構

為提供穩(wěn)定高效的服務，系統(tǒng)框架縱向分為4層，由下至上分別是基礎層，數(shù)據(jù)層，業(yè)務組件層和應用層，其結構如圖1所示。

圖1 功能架構

基礎層包括基礎網(wǎng)絡設施、硬件配置、網(wǎng)絡環(huán)境、應用服務器和數(shù)據(jù)庫軟件等；數(shù)據(jù)層主要包括垂直劃分的數(shù)據(jù)資料，分為基礎數(shù)據(jù)（包括系統(tǒng)配置，車次信息等）、商品庫（包括品牌資料，美食信息，美食分類，訂購價格等）、訂單數(shù)據(jù)（包括訂單詳細信息，配送相關信息等），用戶資料（包括乘客基本信息，商家基本信息）等。各數(shù)據(jù)之間使用松散耦合方式，不做強關聯(lián)，即可以拆分為多個數(shù)據(jù)源，操作數(shù)據(jù)使用讀寫分離模式。服務組件層使用SOA框架，提供各個模塊獨立的服務接口，各服務模塊之間松散耦合，對不需要及時反饋的接口做異步處理。使用zookeeper管理注冊服務。應用層提供手機App和web訪問的數(shù)據(jù)調(diào)用接口，主要以JSON方式返回數(shù)據(jù)，使用反向代理技術和瀏覽器緩存優(yōu)化訪問速度。

2 總體技術架構

為實現(xiàn)整體功能，系統(tǒng)從技術層面實現(xiàn)，如圖2所示。

1）CDN系統(tǒng)

能夠?qū)崟r根據(jù)網(wǎng)絡流量、各節(jié)點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息，將用戶的請求重新導向離用戶最近的服務節(jié)點上。其目的是使用戶就近取得所需內(nèi)容，解決Internet網(wǎng)絡擁擠的狀況，提高用戶訪問網(wǎng)站的響應速度。

2）負載均衡、反向代理

圖2 技術架構

基于商用的硬件F5做分發(fā)（集群，前期可以不用），web服務器如nginx，在7層做負載均衡或者反向代理分發(fā)到集群中的應用節(jié)點（反向代理在集群之后建），靜態(tài)資源隔離，可以暫時考慮使用獨立的靜態(tài)資源服務器，如以后規(guī)模擴大，可以使用MogileFS做靜態(tài)資源的分布式部署+Varnish圖片緩存。

3）App接入

應用層運行在Jboss或者Tomcat容器中，代表獨立的系統(tǒng)，如前端購物、用戶自主服務、后端系統(tǒng)等，協(xié)議接口使用HTTP、JSON格式數(shù)據(jù)，若進一步優(yōu)化可以采用Servlet3.0,異步化Servlet,提高整個系統(tǒng)的吞吐量。Session保存使用外部的Nosql數(shù)據(jù)庫（Membercache或redis），使App接入層無狀態(tài)化。

4）業(yè)務服務

代表某一領域的業(yè)務提供服務，對本項目而言，領域有用戶、美食、訂單、支付業(yè)務等。不同的領域提供不同的服務，這些不同的領域構成一個個模塊，模塊劃分和接口設計應參考高內(nèi)聚、接口收斂的原則，為以后擴展提供便利（當然前期根據(jù)應用規(guī)模的大小，模塊可以部署在一起）。業(yè)務層對外即時協(xié)議可以NIO的RPC方式暴露，采用比較成熟的NIO通訊框架，如netty、Mina。查詢類的接口可以封裝成Web service或REST風格的接口，對網(wǎng)站可以提供jsonp的回調(diào)方式。

對于分布式系統(tǒng)的一致性，盡量滿足可用性，對于需要事務但不需要及時反饋結果的場景(比如下單)，使用異步處理方式，挪到線程中運行。

5）基礎服務中間件

服務注冊使用zookeeper注冊服務，調(diào)用時從zookeeper中獲取服務信息，為以后做分布式擴展提供基礎。異步消息機制對于及時性要求不高的業(yè)務（比如下單，通知等），使用MQ異步消息隊列處理；數(shù)據(jù)檢索在高鐵訂餐系統(tǒng)對于搜索的需求和其他電商平臺相比相對簡單，前期可以直接使用數(shù)據(jù)庫檢索，后期可以考慮將檢索部分獨立出來，使用Solr/Luecne做索引。日志作為統(tǒng)計分析使用的重要依據(jù)，在整個交易過程中，會大量產(chǎn)生。分析統(tǒng)計日志可以使用Hadoop，通過MapReuce的分布式處理框架，用于處理大規(guī)模的數(shù)據(jù)，會寫到結果表中。

6）數(shù)據(jù)存儲

數(shù)據(jù)庫存儲大體分為關系型（事務型）的數(shù)據(jù)庫，以Oracle、MySql為代表，有Key-Value非關系型數(shù)據(jù)庫（NoSql），以Redis和Memcached，MongoDB為代表。高鐵送餐項目的關系型數(shù)據(jù)庫采用MySql，數(shù)據(jù)庫使用讀寫分離機制，使用MysqlProxy接口統(tǒng)一處理，不影響開發(fā)難度。對于需要鎖定操作的數(shù)據(jù)（例如庫存，限制數(shù)量等），可以使用Redis在外部處理，然后統(tǒng)一更新到主數(shù)據(jù)庫中。

數(shù)據(jù)庫到一定級別可以考慮按業(yè)務垂直分庫的方式，將原來一個數(shù)據(jù)庫分成多個，要注意業(yè)務的變化，尤其是需要統(tǒng)一事務的地方，盡量保持在同一個數(shù)據(jù)源內(nèi)。設計時考慮空間換時間的準則，盡量做到各個子系統(tǒng)之間數(shù)據(jù)依賴關系最小化。

緩存設計使用內(nèi)存數(shù)據(jù)庫做Cache，如Redis、Membercache，對于要求一致性較高的場景，在更新數(shù)據(jù)庫的同時，更新緩存，對于一致性要求不高的，可以采用設置緩存失效時間的策略。

3 結束語

隨著信息化時代的來臨，鐵路運輸服務部門應更多地致力于解決旅客出行中遇到的各種問題。鐵路在線訂餐服務，將使旅客出行體驗得到極大的提升，因此本文從軟件架構地層面分析了鐵路訂餐服務系統(tǒng)的功能點和架構設計，著重對可能影響系統(tǒng)運行的問題提供了解決方案，希望利用先進技術手段對鐵路旅客服務業(yè)務提供新的建設思路。目前已經(jīng)取得一些有益的進展，嘗試與廣鐵等路局合作，推動高鐵訂餐服務的落地。

[1]王靜.互聯(lián)網(wǎng)+時代下高鐵車站客運服務研究[J].甘肅科技，2016,32（23）:32-33.

[2]郝穎.提高高速鐵路服務質(zhì)量的思考和對策[J].管理觀察，2010（33）:25-26.

[3]黃興建，石修路，黃其河.基于微信公眾平臺的高鐵客運訂餐服務系統(tǒng)設計與實現(xiàn)[J].鐵道經(jīng)濟研究，2016（3）:42-47.

[4]吳崇遠.部分高鐵開通訂餐服務[J].綜合運輸，2014（8）:93-94.

[5]周路，付立民，楊海超.關鍵路徑法在高寒地區(qū)高速鐵路建設供貨管理中的應用[J].鐵路通信信號工程技術，2017，14（2）:108-111.

[6]王桂霞.鐵總推出“高鐵網(wǎng)上訂餐”服務符合市場化運營[J].中國老年，2017（17）:6.

[7]楊爍萍.告別盒飯方便面,高鐵迎來網(wǎng)上訂餐時代[J].金融科技時代，2017（8）:85.

[8]李文霞.我國高鐵發(fā)展的成就及存在的問題[J].環(huán)球市場信息導報, 2017（27）:20.

[9]陳禮騰.中國高鐵首度試水在線外賣鐵路服務走向開放“互聯(lián)網(wǎng)+”[J].計算機與網(wǎng)絡，2017,43（15）:13.