邯黃鐵路微服務(wù)架構(gòu)應(yīng)用中的關(guān)鍵技術(shù)問題研究

金樹橋

摘要 文章介紹了邯黃鐵路智慧化建設(shè)的主要內(nèi)涵，闡述微服務(wù)架構(gòu)在邯黃鐵路智慧化建設(shè)中的意義和作用，通過對邯黃鐵路微服務(wù)的系統(tǒng)基本架構(gòu)和基于Redis的數(shù)據(jù)中臺方案中的關(guān)鍵技術(shù)的研究、國產(chǎn)數(shù)據(jù)庫適配的比選、對數(shù)據(jù)庫部署方案的推演及實(shí)施，成功解決了邯黃鐵路的信息系統(tǒng)架構(gòu)升級，推動邯黃的智能化升級和數(shù)字化轉(zhuǎn)型。

關(guān)鍵詞 微服務(wù)架構(gòu)；云原生應(yīng)用；數(shù)據(jù)中臺；信息化創(chuàng)新

中圖分類號 U29-39文獻(xiàn)標(biāo)識碼 A文章編號 2096-8949（2024）06-0010-03

0 引言

邯黃鐵路是以貨運(yùn)為主的區(qū)域性合資鐵路，邯黃鐵路全線長468 km，共計(jì)31個車站，其中8個車站辦理貨運(yùn)業(yè)務(wù)，主要作業(yè)集中在東部的渤海三站，即渤海東站、渤海新區(qū)站、渤海西站，約占裝車總量的85%。

2020年，邯黃鐵路有限責(zé)任公司印發(fā)了《“十四五”發(fā)展規(guī)劃》和《邯黃鐵路智慧化建設(shè)規(guī)劃綱要》，提出了建設(shè)智能貨運(yùn)、智能運(yùn)輸?shù)纫幌盗袘?zhàn)略目標(biāo)，并開始籌建一系列信息化改造及新建項(xiàng)目。“邯黃鐵路智能貨運(yùn)一體化應(yīng)用”（以下簡稱“貨運(yùn)一體化”）是其中的關(guān)鍵項(xiàng)目之一，承擔(dān)了整合既有應(yīng)用系統(tǒng)、推動應(yīng)用架構(gòu)全面升級的基礎(chǔ)性工作。

按照兩個規(guī)劃要求，結(jié)合邯黃公司的投資計(jì)劃，貨運(yùn)一體化擬基于微服務(wù)架構(gòu)規(guī)范，以公司運(yùn)輸調(diào)度、資源規(guī)劃、貨運(yùn)作業(yè)、安全管控為核心，重構(gòu)一系列依托PaaS平臺運(yùn)行的云原生應(yīng)用，形成完整的云原生應(yīng)用體系，并逐步擴(kuò)大云原生應(yīng)用范圍，最終實(shí)現(xiàn)企業(yè)應(yīng)用的整體升級。同時，按照國家信創(chuàng)要求，選購國產(chǎn)CPU、服務(wù)器、操作系統(tǒng)和數(shù)據(jù)庫，按照“邊建設(shè)、邊改造”的原則，結(jié)合應(yīng)用系統(tǒng)架構(gòu)設(shè)計(jì)，利用3年左右時間完成國產(chǎn)化替代。該文就項(xiàng)目設(shè)計(jì)中關(guān)于微服務(wù)架構(gòu)和安可替代的幾個關(guān)鍵技術(shù)問題進(jìn)行研究，提出相關(guān)的設(shè)計(jì)思路和實(shí)現(xiàn)解決方案。

1 系統(tǒng)基本架構(gòu)

基于微服務(wù)架構(gòu)的云原生應(yīng)用是目前信息系統(tǒng)的主流架構(gòu)，《邯黃鐵路智慧化建設(shè)規(guī)劃綱要》中已經(jīng)明確將微服務(wù)作為信息系統(tǒng)的主流架構(gòu)，所有新建應(yīng)用系統(tǒng)均應(yīng)優(yōu)先考慮使用微服務(wù)架構(gòu)。

微服務(wù)（Micro Service）是一種軟件架構(gòu)方式，將傳統(tǒng)上的單體應(yīng)用分解為一系列可獨(dú)立運(yùn)行的、多實(shí)例的服務(wù)，每個服務(wù)均提供良好定義的接口[1]。云原生（Cloud Native）應(yīng)用是基于微服務(wù)架構(gòu)、充分利用云計(jì)算特征重新開發(fā)的應(yīng)用系統(tǒng)。與傳統(tǒng)面向服務(wù)架構(gòu)（SOA）相比，微服務(wù)架構(gòu)強(qiáng)調(diào)“重構(gòu)”，是一種徹底放棄原有代碼，重新構(gòu)建全新代碼的思路，這也是云原生中“原生”的基本含義[2]。“多實(shí)例”是微服務(wù)架構(gòu)的一個基本特征，傳統(tǒng)的應(yīng)用通常只有1個或有限幾個實(shí)例，微服務(wù)應(yīng)用將傳統(tǒng)的單體應(yīng)用分解為多個微服務(wù)。每個微服務(wù)又同時運(yùn)行多個實(shí)例，因此，基于微服務(wù)架構(gòu)的云原生應(yīng)用需要更多的運(yùn)行環(huán)境支持，傳統(tǒng)的基于物理機(jī)或虛機(jī)的基礎(chǔ)設(shè)施環(huán)境，都無法滿足微服務(wù)應(yīng)用的運(yùn)行要求，需要基于容器的支撐平臺，即PaaS平臺之上。由于傳統(tǒng)IT系統(tǒng)本身的復(fù)雜性，PaaS平臺往往涉及跨平臺的多云、混合云管理[3]。

結(jié)合項(xiàng)目預(yù)算及基于微服務(wù)的云原生應(yīng)用、高可用性、多云混合云管理等要求，貨運(yùn)一體化應(yīng)用系統(tǒng)的基本架構(gòu)，如圖1所示：

主用系統(tǒng)采取新購的信創(chuàng)設(shè)備，建成完整的基于PssS的云原生應(yīng)用體系。備用系統(tǒng)采用利舊設(shè)備，在新系統(tǒng)投產(chǎn)后利用替換下來的既有x86服務(wù)器作為備用設(shè)備，將微服務(wù)直接部署在物理機(jī)操作系統(tǒng)上，不安裝云平臺，不提供多實(shí)例支持，以節(jié)省資源需求和建設(shè)投資。

主用系統(tǒng)中間件選用青云虛擬化軟件（IaaS）+魯班（原Kubesphere）PaaS平臺。其中青云虛擬化軟件實(shí)現(xiàn)新購信創(chuàng)設(shè)備的虛擬化。由于邯黃鐵路信息系統(tǒng)發(fā)展的歷史原因，邯黃鐵路信息系統(tǒng)繁多、架構(gòu)各異、整合困難，因此，先期必須提供多種基礎(chǔ)設(shè)施環(huán)境。應(yīng)用系統(tǒng)、中間件盡量以容器方式運(yùn)行，由PaaS平臺提供高可用保證，同時減少對硬件資源的占用。同時，為滿足“邊改造、邊升級”的策略要求，某些遺留系統(tǒng)及其依賴的中間件，還需以虛機(jī)方式運(yùn)行。該架構(gòu)通過青云虛擬化軟件來提供虛機(jī)，遺留系統(tǒng)和其所依賴的無法納入容器的中間件，由青云虛擬化軟件提供的虛擬服務(wù)器支撐運(yùn)行。

魯班PaaS平臺除提供高可用性保障之外，還集成了大量第三方工具，提供了交互式運(yùn)維管理界面、開發(fā)運(yùn)維一體化、圖形化性能及監(jiān)控、日志聚合、數(shù)據(jù)鏈路追蹤等服務(wù)。其底層基于Kubernetes構(gòu)建，具有開放式架構(gòu)，可提供安全、可靠、高可用的基礎(chǔ)設(shè)施管理和計(jì)算存儲資源調(diào)配、水平伸縮、服務(wù)遷移能力，為云原生應(yīng)用提供可信基礎(chǔ)設(shè)施服務(wù)。

數(shù)據(jù)庫系統(tǒng)獨(dú)立部署，主、備系統(tǒng)共享使用。數(shù)據(jù)庫選用人大金倉的KingbaseES V8系統(tǒng)，采取主備方式，直接部署在物理機(jī)上。

2 基于Redis的數(shù)據(jù)中臺方案

數(shù)據(jù)中臺是全領(lǐng)域數(shù)據(jù)的共享能力中心，提供數(shù)據(jù)采集、數(shù)據(jù)模型、數(shù)據(jù)計(jì)算、數(shù)據(jù)治理、數(shù)據(jù)資產(chǎn)、數(shù)據(jù)服務(wù)等全鏈路的一站式產(chǎn)品、技術(shù)、方法論服務(wù)。通過數(shù)據(jù)中臺，企業(yè)將原來分散在各應(yīng)用系統(tǒng)中的數(shù)據(jù)整合成為完整、一致、統(tǒng)一的企業(yè)數(shù)據(jù)，使數(shù)據(jù)能夠反映企業(yè)決策、設(shè)計(jì)、生產(chǎn)、銷售的全鏈條全場景。數(shù)據(jù)中臺是企業(yè)數(shù)智化的前提，也是一切智能算法的基礎(chǔ)，是邯黃建設(shè)智慧貨運(yùn)、智慧運(yùn)輸體系的基礎(chǔ)。

數(shù)據(jù)中臺建設(shè)是企業(yè)架構(gòu)升級的核心內(nèi)容，涉及內(nèi)容包括：建立數(shù)字化模型，全面實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)數(shù)字化建模；統(tǒng)籌企業(yè)應(yīng)用系統(tǒng)數(shù)據(jù)，形成全景全鏈條的企業(yè)級數(shù)據(jù)架構(gòu)；制定數(shù)據(jù)質(zhì)量標(biāo)準(zhǔn)，設(shè)計(jì)企業(yè)級元數(shù)據(jù)模型；構(gòu)建數(shù)據(jù)采集能力，建立穩(wěn)定可靠的數(shù)據(jù)來源；整合企業(yè)應(yīng)用系統(tǒng)，形成圍繞數(shù)據(jù)中臺的應(yīng)用體系等一系列問題。

在應(yīng)用建設(shè)期間，需要先解決數(shù)據(jù)中臺建設(shè)的技術(shù)問題，即探討基于Redis的微服務(wù)架構(gòu)中無狀態(tài)Stateless服務(wù)的解決方案。這是云原生應(yīng)用重構(gòu)的核心，也是數(shù)據(jù)中臺建設(shè)的最基礎(chǔ)技術(shù)前提和要求。

微服務(wù)的多實(shí)例特征，要求服務(wù)實(shí)例不能保存私有數(shù)據(jù)，否則就破壞了無狀態(tài)原則。如果每次都從數(shù)據(jù)庫讀寫數(shù)據(jù)，不但影響運(yùn)行速度，也會給數(shù)據(jù)庫造成很大壓力。因此，需要類似Redis的內(nèi)存數(shù)據(jù)庫中間件來管理共享的內(nèi)存數(shù)據(jù)，以及一組操作Redis的數(shù)據(jù)中臺服務(wù)。Redis和數(shù)據(jù)庫是兩個完全獨(dú)立的中間件，兩者之間不直接交換數(shù)據(jù)。如圖2所示。

數(shù)據(jù)中臺的本質(zhì)，就是提供一組Redis操作方法，使業(yè)務(wù)組件可以便捷地讀寫Redis，簡化系統(tǒng)設(shè)計(jì)。Redis代理由應(yīng)用框架提供，具體通過應(yīng)用框架的Redis Agent工具類實(shí)現(xiàn)，服務(wù)接口如下。

基本讀寫服務(wù)API，可不導(dǎo)入Jedis包直接操作Redis：

（1）getInstacne（ ） 獲取Redis Agent實(shí)例。

（2）get、set方法，提供object-object的鍵值對存取，服務(wù)自動記錄對象類型，自動決定使用哪種串行化方式。

（3）getString、setString方法，對String-String型鍵值對的快捷方法。

高級讀寫服務(wù)API，返回Jedis引用，直接操作Jedis：

（1）selectDb（index） 切換數(shù)據(jù)庫。數(shù)據(jù)庫用數(shù)字索引標(biāo)識。

（2）getJedis（ ） 返回Jedis引用，由使用者自行操控Redis。

在應(yīng)用層面，數(shù)據(jù)讀寫通常被歸到數(shù)據(jù)讀寫服務(wù)（通常是數(shù)據(jù)中臺服務(wù)的API），業(yè)務(wù)邏輯開發(fā)人員不需要花費(fèi)精力去關(guān)注實(shí)現(xiàn)細(xì)節(jié)，但需要保持足夠的控制。一種推薦做法是對業(yè)務(wù)邏輯提供一致的讀寫方法，并通過參數(shù)控制數(shù)據(jù)讀/寫的源/目標(biāo)對象。

（1）在讀方法中設(shè)置布爾參數(shù)refresh，refresh為true表示需要從數(shù)據(jù)庫中讀取數(shù)據(jù)，否則從Redis中讀取數(shù)據(jù)即可。該參數(shù)主要用于讀取來自外部源的數(shù)據(jù)，需要定期讀取數(shù)據(jù)庫來刷新Redis數(shù)據(jù)中臺。

（2）在寫方法中設(shè)置布爾參數(shù)commit，commit為true表示寫中臺的同時也寫數(shù)據(jù)庫，否則只寫中臺。該參數(shù)主要基于效率因素考慮，在數(shù)據(jù)IO較大時，可以更精細(xì)地控制寫操作頻度。

戰(zhàn)術(shù)數(shù)據(jù)中臺是應(yīng)用框架的一部分。除數(shù)據(jù)中臺方案外，應(yīng)用框架還需提供消息隊(duì)列代理、可靠守護(hù)進(jìn)程框架、統(tǒng)一登錄和用戶身份認(rèn)證、訪問授權(quán)等一系列服務(wù)。

3 國產(chǎn)數(shù)據(jù)庫適配及部署方案

經(jīng)比較適配，邯黃智能貨運(yùn)一體化應(yīng)用采用人大金倉KingbaseES v8作為數(shù)據(jù)庫。數(shù)據(jù)庫服務(wù)器采取讀寫分離的主備方式，提供需要的高可用性保證。邯黃現(xiàn)有應(yīng)用運(yùn)行于Oracle數(shù)據(jù)庫，該數(shù)據(jù)庫系統(tǒng)及其服務(wù)器（非信創(chuàng)）仍保持使用，支撐該次尚未遷移的遺留應(yīng)用系統(tǒng)運(yùn)行，同時，也作為貨運(yùn)一體化應(yīng)用的備用數(shù)據(jù)庫，使資源能力得到充分使用。待新設(shè)備采購到位再逐步進(jìn)行升級替換。上述架構(gòu)如圖3所示：

圖3中主用數(shù)據(jù)庫集群為新購金倉KingbaseES v8系統(tǒng)，采取讀寫分離的主備方式，其中主用數(shù)據(jù)庫為寫數(shù)據(jù)庫，承擔(dān)所有寫數(shù)據(jù)庫操作，備用數(shù)據(jù)庫為只讀數(shù)據(jù)庫，承擔(dān)讀數(shù)據(jù)庫操作。讀寫分離由金倉數(shù)據(jù)庫通過JDBC組件自行進(jìn)行負(fù)載均衡（Kingbase數(shù)據(jù)庫在JDBC鏈接串中指定多個數(shù)據(jù)庫URL，可自行定位讀寫服務(wù)器，不需要用戶在程序中予以考慮）。讀寫數(shù)據(jù)庫服務(wù)器間通過內(nèi)置同步軟件實(shí)現(xiàn)實(shí)時數(shù)據(jù)同步，當(dāng)檢測到一方出現(xiàn)問題后，會自動將負(fù)載全部轉(zhuǎn)移到另一臺服務(wù)器，不需要用戶干涉。問題修復(fù)后，可自行同步數(shù)據(jù)并恢復(fù)雙機(jī)運(yùn)行，整個過程均不需要人工干預(yù)。主用集群和備用數(shù)據(jù)庫系統(tǒng)（邯黃目前為單機(jī)系統(tǒng)）間采用Kingbase FlySync（簡稱KFS）進(jìn)行異步數(shù)據(jù)同步。KFS是一個非常強(qiáng)大的數(shù)據(jù)同步軟件，支持“多對一”“一對多”的異構(gòu)高效數(shù)據(jù)同步。其中，“多對一”表示多個數(shù)據(jù)源同步到一個目標(biāo)數(shù)據(jù)庫，“一對多”表示一個數(shù)據(jù)源同步到多個目標(biāo)數(shù)據(jù)庫，異構(gòu)表示可以在Kingbase、Oracle、MySQL、PostgreSQL等數(shù)據(jù)庫產(chǎn)品，以及RabbitMQ、Kafka等傳輸中間件間傳遞數(shù)據(jù)，高效表示基于數(shù)據(jù)庫log實(shí)現(xiàn)高效增量寫入。在該系統(tǒng)中，使用了KFS一對一的異構(gòu)數(shù)據(jù)庫同步能力。

數(shù)據(jù)庫是信創(chuàng)適配中的重點(diǎn)工作。從小型機(jī)到服務(wù)器、從實(shí)時應(yīng)用集群（RAC）到主備集群，從Oracle到國產(chǎn)數(shù)據(jù)庫，都會造成一定的性能損失，疊加起來，可能會對應(yīng)用性能造成較大影響，因此，必須在設(shè)計(jì)方案上考慮比較充分的性能冗余。衡量數(shù)據(jù)庫訪問量，主要是通過QPS和TPS兩個參數(shù)判斷，簡言之，QPS是每秒執(zhí)行SQL語句的數(shù)量，TPS是每秒提交事務(wù)的數(shù)量。由于該系統(tǒng)投資有限，而邯黃系統(tǒng)數(shù)據(jù)智能化要求較高，數(shù)據(jù)訪問量大，因此，在應(yīng)用中進(jìn)行了一定優(yōu)化，采用了自行編寫數(shù)據(jù)庫訪問代碼的方式，未使用MyBatis等框架進(jìn)行O-R Mapping，以期在性能上達(dá)到更優(yōu)。

邯黃鐵路智能貨運(yùn)系統(tǒng)的另一個特點(diǎn)，是主備系統(tǒng)分別使用了不同數(shù)據(jù)庫廠商的異構(gòu)數(shù)據(jù)庫，要求應(yīng)用系統(tǒng)具備自動識別數(shù)據(jù)庫類型、主動適應(yīng)不同數(shù)據(jù)庫連接的能力。在這方面，金倉數(shù)據(jù)庫實(shí)現(xiàn)了與Oracle的完美兼容，除加載數(shù)據(jù)庫驅(qū)動的方式略有不同外，所有數(shù)據(jù)庫操作均可復(fù)用同樣代碼。因此，只需配置兩套數(shù)據(jù)庫參數(shù)，并完成在線識別、鏈接操作即可。具體步驟如下：

（1）在配置參數(shù)中為兩套數(shù)據(jù)庫分別配置連接參數(shù)，程序自動根據(jù)URL中的關(guān)鍵字識別數(shù)據(jù)庫，并選用相關(guān)配置參數(shù)。

（2）每次獲取數(shù)據(jù)庫連接時，首先獲取主數(shù)據(jù)庫連接，在獲取失敗時改為獲取備用數(shù)據(jù)庫連接。

（3）應(yīng)用具體的數(shù)據(jù)庫操作方法，均與使用哪種連接無關(guān)。換言之，使用哪種數(shù)據(jù)庫對開發(fā)者是透明的。

邯黃數(shù)據(jù)庫架構(gòu)是根據(jù)邯黃設(shè)備實(shí)際情況設(shè)計(jì)的個性化備用方案，希望在主數(shù)據(jù)庫服務(wù)器設(shè)備失效時，備數(shù)據(jù)庫服務(wù)器可以實(shí)現(xiàn)自動接管。主—備集群失效時，備用數(shù)據(jù)庫集群可以通過人工干預(yù)進(jìn)行接管。人大金倉本身可以通過仲裁節(jié)點(diǎn)實(shí)現(xiàn)備用集群自動接管，但考慮主備集群同時故障的概率較小，兼之網(wǎng)絡(luò)、設(shè)備等各種復(fù)雜性因素，自動接管可能會帶來更多的不穩(wěn)定風(fēng)險，因此，選擇了人工干預(yù)切換的方式。由于通過KFS實(shí)現(xiàn)了準(zhǔn)實(shí)時同步，接管操作非常簡單，可在兩分鐘之內(nèi)完成，可以滿足邯黃信息系統(tǒng)故障切換時間的要求。

上述方案是邯黃鐵路智能貨運(yùn)一體化應(yīng)用初期的數(shù)據(jù)庫方案，僅考慮了聯(lián)機(jī)應(yīng)用系統(tǒng)（OLTP）。隨著邯黃鐵路智能貨運(yùn)建設(shè)的不斷深入，還需增加集成數(shù)據(jù)中臺和離線數(shù)據(jù)分析系統(tǒng)（OLAP），增加分析數(shù)據(jù)庫軟件。由于投資和設(shè)備能力限制，該次數(shù)據(jù)庫方案中未納入這部分內(nèi)容。后期工作中需增加獨(dú)立的分析數(shù)據(jù)庫服務(wù)器集群，借助于KingbaseFlySync，也可以輕松地搭建邯黃的集成數(shù)據(jù)中臺和大數(shù)據(jù)分析體系，實(shí)現(xiàn)企業(yè)級運(yùn)輸分析和決策支持系統(tǒng)。

4 結(jié)束語

邯黃鐵路智能貨運(yùn)一體化應(yīng)用，是一個典型的地方鐵路運(yùn)輸生產(chǎn)領(lǐng)域的現(xiàn)代化應(yīng)用信息系統(tǒng)。項(xiàng)目雖然規(guī)模不大，但匯集了信創(chuàng)、云原生、集中部署等現(xiàn)代信息化應(yīng)用的全部特點(diǎn)，具有很強(qiáng)的示范作用。通過邯黃貨運(yùn)一體化應(yīng)用的建設(shè)，不但可以解決邯黃鐵路的信息系統(tǒng)架構(gòu)升級，推動邯黃的智能化升級和數(shù)字化轉(zhuǎn)型，還可以為其他地方鐵路的信息化轉(zhuǎn)型升級提供很好的經(jīng)驗(yàn)積累。該文從邯黃鐵路智能貨運(yùn)建設(shè)實(shí)踐出發(fā)，從面到點(diǎn)闡述了一些實(shí)際設(shè)計(jì)和建設(shè)中的具體方案和經(jīng)驗(yàn)，涉及范圍較廣，疏漏之處在所難免。不當(dāng)之處，請同行不吝指正。

參考文獻(xiàn)

[1]劉子揚(yáng)， 王興中， 王青. 面向微服務(wù)的國家能源集團(tuán)鐵路綜合調(diào)度信息系統(tǒng)架構(gòu)設(shè)計(jì)與實(shí)現(xiàn)[J]. 鐵道運(yùn)輸與經(jīng)濟(jì)， 2022（S1）： 7-13.

[2]李貝貝， 閻志遠(yuǎn)， 戴琳琳. 鐵路運(yùn)輸應(yīng)用云原生技術(shù)優(yōu)化路線研究[J]. 鐵路計(jì)算機(jī)應(yīng)用， 2021（1）： 15-18+23.

[3]劉志勇. 基于微服務(wù)架構(gòu)的鐵路多云管理應(yīng)用實(shí)踐探索[J]. 鐵路通信信號工程技術(shù)， 2021（2）： 62-66.