一種應用于高鐵領域的訂餐服務系統設計

郭 楠

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

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

1 總體功能架構

為提供穩定高效的服務，系統框架縱向分為4層，由下至上分別是基礎層，數據層，業務組件層和應用層，其結構如圖1所示。

圖1 功能架構

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

2 總體技術架構

為實現整體功能，系統從技術層面實現，如圖2所示。

1）CDN系統

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

2）負載均衡、反向代理

圖2 技術架構

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

3）App接入

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

4）業務服務

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

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

5）基礎服務中間件

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

6）數據存儲

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

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

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

3 結束語

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

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

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

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

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

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

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

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

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

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