李 楊,戴琳琳,閻志遠,江 琳,,李曉楠,
(1.中鐵程科技有限責任公司,北京 100081;2.中國鐵道科學研究院集團有限公司 電子計算技術研究所,北京 100081)
經過20余年的發展,中國鐵路客票發售與預訂系統(簡稱:客票系統)形成了覆蓋線上(即12306互聯網售票系統,包括12306網站及移動終端App)和線下全國3 000多個客運車站的超大型票務系統[1]。鐵路客票電子票庫系統(簡稱:電子票庫)作為客票系統的核心業務系統之一,承擔著旅客從購票、支付、退改簽、乘車、進出站和換乘等全流程信息化服務中的交易事務環節。電子票庫通過數據庫存儲過程、分布式擴展等技術,良好地承擔了近年來客票系統的巨大業務壓力,隨著客票系統交易量的日益增長及復雜度的日益增加,為進一步提高電子票庫的擴展能力,實現業務的快速迭代,減少研發、部署和維護的復雜性,基于服務架構,對當前電子票庫進行了改造[2]。本文闡述了改造后的電子票庫架構、關鍵技術和試運行效果。
當前,電子票庫支撐線上互聯網售票、線下終端(包括窗口、代售點、自動售票機等)售票,是鐵路電子客票的底層核心系統,是線上、線下服務一體化的重要環節。當前電子票庫架構如圖1所示。

圖1 當前電子票庫架構
1.1.1 客服內/外網
客服內/外網是支撐12306互聯網售票系統的獨立網絡分區。旅客的線上購票請求通過客服內/外網中的12306網站和移動終端App服務、排隊、風控等環節進入客票網,經過客票網中間件控制層后在電子票庫進行交易處理。
1.1.2 客票網
旅客的線下購票請求通過客票網里的鐵路局集團公司、車站線下終端接入中國國家鐵路集團有限公司(簡稱:國鐵集團)中間件控制層后,到達電子票庫進行交易處理。
電子票庫分為售票節點和退改簽節點。售票節點主要承擔售票、支付、候補等業務處理和數據存儲,并將數據實時同步到退改簽節點;退改簽節點主要承擔改簽、退票和檢票等業務處理和數據存儲,并將數據實時同步到緩存集群,提供大并發高速查詢服務。
目前,電子票庫采用商業數據庫Sybase[3],并通過分庫、分表支持橫向擴展,可以將業務請求均衡地分散到很多個數據庫節點上進行處理,提高了電子票庫的處理能力。由于電子票庫仍然采用數據庫存儲過程實現業務邏輯,這種數據與業務緊耦合的方式[4],一定程度上制約了電子票庫的擴展靈活性和業務治理水平。
為了實現業務與數據庫的徹底解耦,將原本在Sybase數據庫存儲過程中的業務邏輯抽離出來,可提升業務功能的快速迭代能力,提高業務復用能力和業務治理水平[5]。本文基于業界主流的業務治理模式——服務架構,對電子票庫進行了架構改造設計,如圖2所示。

圖2 新電子票庫架構
將現有Sybase+存儲過程的數據庫集群,逐漸改造為電子客票業務服務集群。新電子票庫架構主要分為接入層、應用層、數據層和總體支撐。
(1)接入層:負責電子票庫集群內各應用服務的導航、路由和管理。
(2)應用層:基于領域驅動設計對電子票庫業務流程進行重構,提煉并標準化基礎業務邏輯,形成可復用的核心組件,進而構建了公共基礎服務和業務服務。
(3)數據層:進行服務改造后,數據存儲更加靈活,可繼續采用商業數據庫,也可以根據實際需求采用開源或者國產數據庫。
(4)總體支撐:主要包括監控統計和服務治理[6]。為整個電子票庫集群提供了服務注冊、注冊中心、配置中心、動態擴縮容、熔斷限流、持續交付與部署等支撐。
服務架構相對于存儲過程模式更為復雜,電子票庫作為客票系統核心關鍵系統,在改造過程中須保持業務的穩定和連續,以下針對改造中的若干關鍵技術進行闡述。
電子票庫作為客票系統的核心業務系統,通過與眾多上下級系統及同級子系統進行交互和協同共同承擔客票業務。因此電子票庫在進行服務化改造后,需要進行適配,繼續保持與外部系統的交互,達到電子票庫在客票系統中的業務無縫銜接。適配技術主要分為3個方面,如圖3所示。

圖3 新電子票庫系統適配示意
2.1.1 API適配
應用程序編程接口(API,Application Programming Interface)適配。如圖3左上方所示,API接口分超文本傳輸協議(HTTP,Hypertext Transfer Protocol)和傳輸控制協議(TCP,Transmission Control Protocol)2類接口,是用于支撐電子票庫的上級系統接入。通過約定報文規范,進行報文格式化、序列化完成適配,適配后,線上票務交易系統、線下票務交易系統可通過中間件基于多種網絡協議進行業務請求,管理控制也可通過TCP進行業務管理。
2.1.2 數據存儲適配
如圖3左下方所示,數據存儲主要為數據庫、緩存、文件系統等數據資源,通過服務的內置持久化框架或者數據接口進行研發適配。實現對Sybase數據庫、其他類型數據庫、Redis緩存、其他緩存、文件系統的訪問。
2.1.3 同級關聯系統適配
如圖3右半部分所示,同級關聯系統主要包括客票系統的智能運營維護、定時任務、監控系統、業務審計、服務治理、安全掃描等系統。通過對Web適配、運營維護管理適配、報警通知適配、日志適配和技術支撐適配等技術進行研發,實現電子票庫服務化改造在客票系統中的無縫遷移。
在新電子票庫部署完畢之后,須進行數據遷移[7],整個數據遷移過程包括數據遷移評估、結構遷移、數據遷移和數據校驗等過程[8],如圖4所示。

圖4 數據庫遷移流程
2.2.1 數據遷移評估
如果目標數據庫與源端數據庫為同構數據庫,則主要對遷移數據量、存儲空間、遷移時間和工作量進行評估;如果目標數據庫與源端數據庫為異構數據庫,則在上述評估內容的基礎上增加對數據庫的函數、索引、序列,以及數據類型、字段長度等對象的兼容性評估,并評估是否存在顯性或隱性的遷移風險。
2.2.2 數據庫對象遷移
將包括表結構、索引、序列等在內的數據庫對象進行遷移,支持根據遷移目標數據庫類型進行數據庫對象的定義轉換。
2.2.3 數據遷移
全量數據遷移及后續的增量數據遷移,是為保障遷移過程中源端數據庫的數據變動能夠及時同步到目標數據庫中,確保兩端數據庫的數據一致性[9]。由于全量數據遷移過程持續時間較久,期間源端數據庫仍有新業務數據寫入,為保證數據遷移的一致性,在全量數據遷移之前,將啟動對增量數據監聽,將增量變動數據存儲在本地存儲中。當全量數據遷移完成后,對增量數據回放,將增量數據同步到新系統數據庫中。
2.2.4 遷移校驗
分別對源端數據庫和目標數據庫進行全量數據和增量數據抽取,按行生成哈希值,對哈希值進行比較。如果哈希值一致,則兩端數據庫數據一致;如果哈希值檢測數據不一致,則根據不一致的哈希值位置,找到相應數據記錄進行修復和數據補償。
為實現業務流量遷移,以及當前電子票庫向新電子票庫平滑過渡,將2種架構的電子票庫作為同等實例節點并行在生產系統中,通過中間件將業務請求逐步轉發到新電子票庫上,實現業務流量的遷移。具體業務遷移如圖5所示。

圖5 電子票庫服務化改造流量遷移
業務流量遷移技術實現多種遷移規則配置,支持按用戶遷移、按車次遷移等,可支持新老系統的灰度遷移與并行運行。同時,數據實時同步備份到當前電子票庫,在服務集群試運行驗證期遇到故障時,可及時切回當前電子票庫,降低風險。
改造后的電子票庫充分利用了服務架構的優勢,實現業務靈活擴展,并有效地提高處理能力,試運行的具體效果體現如下。
本文以AKF立方體擴展模型作為對電子票庫服務化改造后的擴展性評估,AKF立方體也叫做Scala Cube,它在《The Art of Scalability》一書中被首次提出[10],AKF 把系統擴展分為3個擴展維度:X軸、Y軸和Z軸。X軸表示無狀態實例的水平擴展,Y軸表示功能或者服務的擴展,Z軸表示散列塊或者數據分片擴展。
在服務改造前,電子票庫由于采用存儲過程實現業務邏輯,業務邏輯緊耦合在有狀態的數據庫里,如圖6(a)所示。

圖6 電子票庫AKF立方體擴展評估對比
(1)在X軸方向不具備擴展能力;
(2)在Y軸具備2層的業務劃分(售票層和退改簽層),具備一定的擴展能力;
(3)在Z軸上基于客票系統強大的動態分區系統具備較強的擴展能力。
進行服務化改造后,新電子票庫對業務邏輯和數據存儲進行了解耦。如圖6(b)所示。
(1)在X軸上新增了無狀態業務實例的橫向擴展能力,實現了一定范圍內處理能力的線性增長,提高了系統容量。此外,此種擴展方式無額外開發成本,實施簡單,使得新電子票庫擴展高效便捷;
(2)在Y軸上,增加了多層業務職責劃分,將新電子票庫拆分為更細粒度的多個服務。每個服務都負責特定的業務領域,如購票、退票、改簽等,降低了復雜性,提高了可維護性和可擴展性;
(3)在Z軸上,保持不變,仍然保持客票系統強大的數據分區擴展能力。
綜上所述,服務化后的新電子票庫具備了豐富而強大的擴展能力。
對電子票庫當前架構和服務化架構的單數據節點上進行提交訂單業務、支付業務壓測。性能對比如圖7所示。

圖7 電子票庫服務化改造前后性能對比
從圖7中可以看出,服務化架構在請求并發較小時,響應時間高于當前架構下存儲過程模式,這是由服務在模塊之間及與數據庫之間網絡交互多于存儲過程導致的,是服務化改造需要認知到的一個事情。但是隨著并發量增加,當并發超過50 TPS的時候,服務響應比較穩定,而存儲過程響應時間迅速增長。從而可以判斷出,服務化的電子票庫在大并發和高負載的場景下處理能力優于存儲過程模式。
本文基于服務架構,對電子票庫系統進行了遷移改造。試運行的效果表明,改造后的系統不僅實現了原架構中業務和數據的相分離,提高了業務擴展能力和處理能力,同時,提高了客票系統業務復用能力和業務治理水平,為未來客票系統應用服務的標準化、敏捷化建設提供了經驗。