一種基于微服務的統一票務管理系統

黃 凱,羅 陳

(上?？萍拣^ 上海 200127)

0 引言

傳統票務系統不同模塊采用不同技術架構進行搭建,單個模塊升級迭代都會影響到其他模塊業務和數據,模塊不方便獨立設計和上線,使用起來十分煩瑣,開發和運維的工作量大。為了降低用戶使用難度,提高平臺集群化管理能力,因此需要對老舊系統進行改造[1]。

系統軟件架構的設計不僅關系到系統能否正確運行,同時也決定系統未來新功能迭代過程是否順利。歷史票務系統多采用集中式架構設計,雖然設計簡單,但是難以滿足時代發展需求,隨著信息技術更新迭代的出現,弊端逐漸顯現。因此,本文在微服務的系統架構下,設計了一套基于微服務的統一票務集群管理系統,此系統便于項目進行快速迭代和上線,不僅符合數字化管理需求的,而且有助于提升系統的總體性能[2]。

1 研究背景和目的

針對現有的展館票務業務流程及運營難點進行研究,發現各票務模塊采用不同的技術架構進行模塊建設,本文所述系統通過構建統一微服務票務管理框架,提供全面技術支撐和安全保障。由于老舊系統改造的工作量巨大,因此采取分布改造的方案[3]?，F有場館底層業務繼續采用原有BS架構或者CS架構,構建成一套獨立服務對業務進行抽象封裝,并對外提供接口能力,保證和滿足用戶實際使用需求,后續再進行內部重構和優化,且不影響系統總體運行。

對于集群化運營的不同場館之間的管理需求,該系統提供統一平臺、分層授權、屬地化運營管控的票務管理,只需要在系統后臺進行統一管理設置,同時該系統也支持各展館按照自身運營實際情況,設置本館自身的業務參數規則、票務產品信息等一系列運營管理規則,為各個展館保留了完整而獨立的業務管理功能[4]。系統在主館通過統一互聯網出口提供公眾服務,在遇到館間網絡中斷的情況下,采用屬地化應急備份系統來代替,需要保證不影響游客的購票、取票及檢票入館和觀看電影。

整個系統采用分布式架構設計,任意一個系統節點的中斷都不會導致多場館的業務中斷。單場館票務核心部署在各自展館的本地機房中,通過中間機房,最終構建一個統一的一體化票務平臺,實現對內統一管理和對外統一服務的目的[5]。整個系統采用統一服務對數據進行集中式處理和分布式部署,針對用戶采用分層授權策略來保證系統數據

2 系統總體應用架構設計

本文所研究的一種基于微服務的統一票務管理系統利用微服務技術進行系統構建,多場館系統統一采用管理架構和集群化運行機制。針對各個展館的不同展出內容、游客動線、業務細節的不同,各個展館運營部門需要按照自身運營實際情況進行管理,系統需要支持各展館自行設置本館業務參數規則、票務產品信息等一系列運營管理規則,因此各個展館保留自身完整而獨立的業務管理功能是重要需求。根據以上需求進行系統架構設計,系統主要由四層進行構建,即應用層、服務層、數據層和系統層。系統的總體架構設計圖,如圖1所示。

圖1 系統總體架構圖

從圖1可知,應用層主要對用戶提供多渠道小程序、Web和PC等主流前端交互頁面。業務分別應用部署在取票機系統、閘機系統和業務前端業務等用戶交互場景中。應用層統一采用Nginx進行反向代理服務設置。服務層主要針對業務系統和通用系統進行服務能力封裝并且進行業務能力輸出,業務系統主要是指票券業務、供應商業務和終端業務等等[6]。通用業務主要是OTA服務、支付系統、監控系統和日志系統等等。數據層主要負責系統中數據業務相關處理,系統數據庫采用主流的MySQL和MongoDB進行設計,數據中間件采用Redis、Kafka和Zookeeper等,主要用于處理經常需要讀取而不是寫入的數據并緩存在Redis中,如場館場地信息、票務信息、場次信息等,以此加快系統的處理效率。

該票務系統為了防止庫存超賣的分布式事務鎖、配置數據的同步等操作交給Zookeeper。數據存儲及中間件主要由數據庫、中間件、大數據三部分組成,是系統所有的核心數據所在,且為將來大數據挖掘和分析提供數據基礎。另外系統還集成大數據處理能力,后期可以進行數據分析和利用數據預估場館流量等分析內容[7]。大數據主要使用Hadoop和Spark主流框架進行構建。系統層是直接和硬件服務進行交互的,硬件底層需要保證系統的穩定性、安全性、通用性和易維護性的要求,統一采用JAVA開源開發環境,運行在Ubuntu或Centos等Linux操作系統環境下,采用開源軟件保證后續系統的安全運行。

3 系統模塊設計

本文所研究的一種基于微服務的統一票務管理系統采用微服務技術對票務系統進行模塊化設計,在保證多系統平穩運行的情況下,保證系統可以進行業務快速迭代開發,并且兼顧滿足不同場館票務個性化要求。

3.1 系統核心功能模塊

多場館票務系統之間架構連接主要由網售系統、數據中心系統、后端支撐系統和用戶中心系統組成,相關的應用統一部署在主館的機房,這也是從安全角度出發,畢竟外網的安全級別低、容易受到攻擊,內網的安全級別要求高,因此提供統一的對外網絡出口以及對內服務,有效保護各館底層票務系統的安全[8]。具體部署的應用還包括自營票務業務、OTA渠道售票應用和自營分銷渠道售票應用、公共服務系統等等。具體的系統多場館應用架構,如圖2所示。

圖2 系統多場館應用架構圖

主館所需的票務核心系統均部署在主館機房,包括票務系統、票檢系統、本館結算系統等,本地的所有票務硬件設備通過局域網與相應的系統進行聯通,保證安全穩定,同時在館間網絡故障時仍然能支持本地化現場票務服務[9]。具體的系統模塊應用關系圖,如圖3所示。分館也需要在本館部署相關備份系統業務,同時為保證數據安全,數據庫設置預定備份策略并進行本地備份,有條件可做異地備份。數據訪問嚴格按用戶級別授權對數據進行訪問,關鍵數據的修改記錄應記錄詳細的操作日志,以備后續追查。數據傳輸與關鍵的敏感數據存放進行一定的加密處理,以防用戶誤操作和介質失效而造成的數據損失。

圖3 系統模塊應用關系圖

3.2 系統技術架構

系統核心技術架構主要由三部分進行組成,分別是網絡接入、中間件和大數據。具體的系統技術架構,如圖4所示。票務系統的網絡接入主要選擇LVS和Nginx作為負載均衡服務,保證更大的訪問并發量。中間件主要使用分布式文件系統,對文件進行管理,功能包括存儲、同步和訪問等,解決大容量存儲和負載均衡的問題。票務系統把處理頻繁和經常需要讀取而不是寫入的數據緩存在Redis中,如場館場地信息、票務信息、場次信息等,以此加快系統的處理效率。大數據層需要保證數據高可靠性、高性能的結構化數據分布式存儲系統,Hbase 隨著數據量增多可以通過節點擴展進行支撐[10]。因此票務系統把HBase當做存歷史數據的平臺,業務流程上除了訂單數據庫外,還有其他交易相關的數據庫,它們都有同一個問題,容量很容易爆滿,為了將HBase發揮更大的用處,在特定的場景下,比如幾個月前的歷史數據,就會先從HBase查尋,將其寫入MySQL,核心的交易流程和支付流程直接在MySQL做,這樣對業務的影響最小,方便業務操作,提升總體數據處理效率[11]。

圖4 系統技術架構示意圖

4 統一票務系統應用

和傳統票務系統相比,統一票務系統接入了主流渠道“小程序”應用,提升了游客購票的便捷度與友好度,用戶無需下載App應用進行即可使用。另外系統采用圖形驗證碼、統一賬號管理、檢票直接使用身份證驗證,限制了黃牛運用刷票軟件刷票、倒票的行為。系統的購票全流程都可以在線上進行,實現了預約、下單、出票全程無紙化操作,業務管理工作人員直接使用電腦或平板設備來進行現場游客信息確認,極大地提高了工作效率。同時系統后臺可以查詢和報表實時知曉現場的進館情況。為了打通用戶的支付渠道,系統支持多種支付渠道,包括但不限于微信、支付寶、云閃付等常見支付方式,有助于改善游客購票付款的使用體驗,并減輕了財務每日在后臺需要進行多賬戶人工對賬的工作量[12]。具體的統一票務實際小程序使用效果圖,如圖5所示。

圖5 統一票務實際使用效果圖

與傳統的票務系統比較,多場館票務資源的整合可以給用戶的使用體驗方面帶來質的提升,用戶無需進行多系統注冊,使用一個賬號即可完成多場館購票服務。為了保證安全和公平,購票統一使用實名制購票,對票務進行統一限制,同時系統還會對用戶特殊證件進行校驗,保證不同證件類型用戶可以享受自有的權益。另外,游客在進館時使用身份證或者小程序中的票據二維碼在閘機檢驗,用戶系統進行身份核驗和場館人員記錄管理,系統所記錄和統計的場館內游客數量可以供管理人員進行場館管理和采取相對應的服務預案,根據游客數量進行流量控制,保證場館運行安全和游客的安全。

5 結語

針對傳統票務業務冗余,更新復雜的問題,本系統采用微服務即使,搭建了四層整體架構設計。其中應用層用來給用戶提供各種交互入口,不同的交互入口彼此獨立對應不同的數據庫和系統層。這些數據層經由服務層進行統一封裝,搭建成為統一的入口,入口內包含不同的模塊界面,為用戶提供多種交互。該系統實現有助于為用戶提供統一業務平臺,減少業務冗余,便于后期升級。該系統目前已經在上海科技館上線使用,上線至今為數十萬用戶提供便利。