于 曼 黃 凱 張 翔

(北京速通科技有限公司軟件研發(fā)部門 北京 100000)

0 引 言

伴隨著中國高速公路投資規(guī)模的不斷擴大、建設(shè)里程的不斷增加，高速公路管理所需的通信、監(jiān)控和收費系統(tǒng)需求量在不斷擴大。電子不停車收費(Electronic Toll Collection，ETC)技術(shù)是伴隨著車輛增多和道路使用率提高而產(chǎn)生的一種旨在提高車輛通行能力的收費技術(shù)，適用于高速公路、交通繁忙的橋梁隧道或停車場等環(huán)境。除中國外，在美國、歐洲和日本等許多國家和地區(qū)，ETC技術(shù)也已經(jīng)被廣泛應(yīng)用，并形成規(guī)模效益。作為高速公路聯(lián)網(wǎng)電子不停車收費示范工程項目，北京市高速公路電子不停車收費系統(tǒng)是實現(xiàn)車輛不停車支付通行費功能的全自動收費系統(tǒng)，從2007年起已經(jīng)平穩(wěn)運行了十多年，至今已發(fā)展了400多萬用戶[1-4]。

近年來，北京ETC系統(tǒng)在高速公路、停車場和服務(wù)區(qū)收費中的應(yīng)用已經(jīng)開展了商業(yè)示范。取消省間收費站和用戶自主辦理、安裝、激活ETC卡和標簽等業(yè)務(wù)的出現(xiàn)進一步推動了用戶量和業(yè)務(wù)量的快速增長。然而，隨著業(yè)務(wù)的快速發(fā)展和用戶量的不斷增加，現(xiàn)有的ETC系統(tǒng)逐漸暴露出擴展性差、開發(fā)周期長、部署維護風險高等問題。通過對ETC系統(tǒng)的改造，解決原系統(tǒng)存在的嚴重問題是本文的最終研究目的。

1 關(guān)于ETC系統(tǒng)改造的分析

為了實現(xiàn)高速公路電子不停車收費的功能，ETC系統(tǒng)包括了發(fā)行系統(tǒng)、多路充值系統(tǒng)、傳輸記賬系統(tǒng)、銀行文件處理前置系統(tǒng)和清分系統(tǒng)等多個分支系統(tǒng)，其中發(fā)行系統(tǒng)是其核心部分，它是處理卡、電子標簽發(fā)行和充值等相關(guān)業(yè)務(wù)的系統(tǒng)。系統(tǒng)的邏輯架構(gòu)如圖1所示。

圖1 ETC系統(tǒng)邏輯架構(gòu)

由于項目設(shè)計之初規(guī)模較小，結(jié)構(gòu)簡單，用戶群體小及實時通信要求低等特點，各個子系統(tǒng)采用傳統(tǒng)的單體架構(gòu)模式設(shè)計，從而導致系統(tǒng)具有以下問題[5-7]。

(1) 代碼耦合性高。隨著業(yè)務(wù)量的不斷提升，代碼變得越發(fā)龐大，業(yè)務(wù)擴展變得愈發(fā)困難，對新需求的響應(yīng)速度變慢，開發(fā)成本變高。

(2) 代碼復用性低。存在大量重復開發(fā)的代碼，各子系統(tǒng)間對數(shù)據(jù)庫的操作相互獨立，不支持代碼復用。

(3) 每個子系統(tǒng)都可以直接訪問核心數(shù)據(jù)，存在搶占數(shù)據(jù)庫資源的現(xiàn)象。

(4) 系統(tǒng)整體進行統(tǒng)一打包及部署，不支持熱更新，部署維護風險較高。

針對ETC系統(tǒng)中存在的上述問題，需在不影響系統(tǒng)正常運行的情況下，對其進行改造。本文搭建數(shù)據(jù)層平臺，提出各子系統(tǒng)中與數(shù)據(jù)操作相關(guān)的程序，將其設(shè)計為獨立的服務(wù)組件，解耦數(shù)據(jù)庫操作層與業(yè)務(wù)服務(wù)層。改造后的架構(gòu)如圖2所示。

圖2 改造后ETC系統(tǒng)架構(gòu)

數(shù)據(jù)層平臺的搭建可增強數(shù)據(jù)操作相關(guān)程序的復用性，增加可支持的數(shù)據(jù)庫類型，且不局限于某些特定數(shù)據(jù)庫。此外，數(shù)據(jù)庫訪問層的變更不會影響業(yè)務(wù)層邏輯的代碼，最大程度減小部署和運維的風險。同時，新增負載均衡提升系統(tǒng)吞吐量和交易處理能力，可支持千萬級的ETC用戶量和與日俱增的交易量[8]。

2 微服務(wù)架構(gòu)介紹

傳統(tǒng)單體架構(gòu)較適合簡單的輕量級應(yīng)用，不適用于復雜度高、業(yè)務(wù)需求量大的中、大型應(yīng)用，因此，它已不再適用ETC數(shù)據(jù)層平臺的開發(fā)。微服務(wù)架構(gòu)理念的興起，很好地解決了這一問題，微服務(wù)架構(gòu)對復雜企業(yè)級應(yīng)用的敏捷開發(fā)部署中存在巨大優(yōu)勢。

微服務(wù)指的是圍繞業(yè)務(wù)構(gòu)建，協(xié)同工作的小而自治的服務(wù)，具有高的內(nèi)聚性、自治性和擴展性。微服務(wù)架構(gòu)的基本思想是將傳統(tǒng)的單體架構(gòu)應(yīng)用按照業(yè)務(wù)功能的不同拆分為一系列可以獨立設(shè)計、開發(fā)、部署、運維的服務(wù)單元，服務(wù)間可通過RPC或API等方式進行通信或被調(diào)用[9-12]。API網(wǎng)關(guān)可以對前端用戶身份進行認證和鑒別，并將前端發(fā)來的 HTTP請求轉(zhuǎn)發(fā)至對應(yīng)的服務(wù)中進行處理。其架構(gòu)如圖3所示[13]。

圖3 微服務(wù)體系架構(gòu)

微服務(wù)架構(gòu)較傳統(tǒng)單體架構(gòu)更有利于應(yīng)用的持續(xù)性開發(fā)。微服務(wù)系統(tǒng)中每個服務(wù)的更新和部署都獨立于其他服務(wù)組件，大大降低了系統(tǒng)更新的風險。每個服務(wù)單元可應(yīng)用不同的編程語言開發(fā)，并可以用不同的數(shù)據(jù)存儲技術(shù)，也可由不同的開發(fā)團隊管理，當有新技術(shù)出現(xiàn)時，可按照模塊逐個升級，具有較好的靈活性。同時，技術(shù)的多元化使得每個服務(wù)可根據(jù)需求和行業(yè)發(fā)展狀況選擇適合的技術(shù)類型，并根據(jù)需求提供接口服務(wù)。服務(wù)間的獨立性和松耦合，實現(xiàn)了單個微服務(wù)出現(xiàn)問題不會影響系統(tǒng)其他服務(wù)運行的目標，容錯能力強大[14-21]。

3 數(shù)據(jù)層平臺總體架構(gòu)設(shè)計

ETC數(shù)據(jù)層平臺基于微服務(wù)架構(gòu)的設(shè)計理念，封裝低粒度的數(shù)據(jù)庫操作行為，為業(yè)務(wù)層提供數(shù)據(jù)操作服務(wù)。數(shù)據(jù)層平臺主要包括通信管理層、工作處理層、主控管理層及數(shù)據(jù)庫，其整體架構(gòu)如圖4所示。

圖4 ETC數(shù)據(jù)層平臺結(jié)構(gòu)

通信管理層基于IO復用原則，負責外圍系統(tǒng)請求的接入接出。當請求接入成功建立連接后，通信管理層采用多線程技術(shù)獲取并解析請求, 根據(jù)業(yè)務(wù)類型的不同分配給對應(yīng)的工作進程處理。消息隊列機制與線程鎖在保證線程安全的前提下,借助共享內(nèi)存完成消息的傳遞、并行處理并轉(zhuǎn)發(fā)。多線程能夠合理高效利用服務(wù)器資源，可大幅度提升消息處理能力。在請求高峰期，消息隊列可以有效緩解壓力,避免因處理能力不足造成服務(wù)不可用等情況。共享內(nèi)存作為通信模塊與工作模塊的橋梁，是目前效率最高的進程間通信技術(shù), 所有交互完全在內(nèi)存中完成且可自定義分配內(nèi)存塊大小，在合理設(shè)計數(shù)據(jù)結(jié)構(gòu)的前提下具備了很高的適用性，并且Linux系統(tǒng)提供相關(guān)底層函數(shù)，保證了平臺使用時的穩(wěn)定性與安全性。

工作處理層是由多個獨立進程實現(xiàn)，根據(jù)通信管理層轉(zhuǎn)發(fā)來的請求調(diào)用動態(tài)庫微服務(wù)，處理相關(guān)業(yè)務(wù)邏輯, 最后將處理結(jié)果回發(fā)至通信管理層。工作處理層將業(yè)務(wù)邏輯根據(jù)不同的功能拆分成不同的子模塊,將各個模塊封裝為相互獨立的動態(tài)庫，依靠自身平臺框架用外圍系統(tǒng)請求參數(shù)實例化動態(tài)庫中的服務(wù)，從而基于C++實現(xiàn)依賴注入控制反轉(zhuǎn)的目的。該實現(xiàn)方式的本質(zhì)類似于微服務(wù)架構(gòu)，動態(tài)庫中的微服務(wù)變更無須編譯平臺代碼,服務(wù)之間互不影響，極大地降低了平臺和服務(wù)的耦合性，提高了平臺和服務(wù)的可擴展性，使得系統(tǒng)整體結(jié)構(gòu)變得非常靈活，是目前C++框架所不具備的[21-23]。

主控管理層主要負責管理通信管理層與工作處理層以及監(jiān)控服務(wù)的啟動。當請求開始處理時，主控管理層負責監(jiān)控服務(wù)處理的時長,根據(jù)特定服務(wù)類型及其自定義超時時間判定超時后的處理方法,減少調(diào)用等待時長,提升響應(yīng)速度。同時主控管理層監(jiān)控通信進程與工作進程存活狀態(tài),當意外掛掉進程時會重新啟動，確保數(shù)據(jù)層平臺的穩(wěn)定性與安全性。

4 數(shù)據(jù)層平臺關(guān)鍵技術(shù)

4.1 C++實現(xiàn)服務(wù)注入

一般C++框架中，如需要在實體A中使用實體B，會直接在實體A中創(chuàng)建實體B的對象，換而言之，是在實體A中去主動獲取所需要的外部資源實體B，如圖5所示。但若應(yīng)用反向注入控制反轉(zhuǎn)的方式，實體A如需使用實體B，無須主動創(chuàng)建實體B，而是被動地等待，等待容器獲取一個B的實例，然后容器反向把實體B的實例注入到實體A中。這種在Java/.Net中是依靠IOC/DI的容器來實現(xiàn)，通過配置文件中的類名實例化業(yè)務(wù)類進行依賴注入的。

圖5 實體A應(yīng)用實體B的傳統(tǒng)方式

ETC數(shù)據(jù)層平臺是一種通過C++實現(xiàn)IOC(控制反轉(zhuǎn))模式，服務(wù)和系統(tǒng)松耦合，進程分發(fā)靈活的平臺系統(tǒng)。平臺將根據(jù)不同功能拆分成的各個模塊封裝為相互獨立的動態(tài)庫，依靠請求參數(shù)實例化動態(tài)庫中的服務(wù)，將可用動態(tài)庫服務(wù)注入到自定義容器中，從而達到依賴注入控制反轉(zhuǎn)的目的，如圖6所示。在調(diào)用服務(wù)時，從自定義容器中取出對象進行后續(xù)邏輯處理，可徹底切分開服務(wù)與平臺間的耦合，使后期服務(wù)變動無需編譯平臺，平臺編譯無需編譯服務(wù)。

圖6 C++實現(xiàn)服務(wù)的依賴注入

4.2 負載均衡

系統(tǒng)的負載均衡器主要對分發(fā)服務(wù)的任務(wù)處理請求選擇最優(yōu)節(jié)點。該系統(tǒng)負載均衡的均衡策略為處理請求首先都暫存到阻塞隊列中等待策略模塊過濾轉(zhuǎn)發(fā)，分發(fā)服務(wù)的數(shù)據(jù)處理請求，負載均衡器主要根據(jù)CPU占用率等進行過濾選擇。當選擇到最優(yōu)的數(shù)據(jù)分析節(jié)點則將請求發(fā)送到對應(yīng)的節(jié)點進行處理，而如果有多個符合條件的節(jié)點，則負載均衡器將隨機選擇其中一個轉(zhuǎn)發(fā)處理請求[24]。

4.3 redis集群化

redis集群化基本原理是通過在多臺服務(wù)器上部署redis, 每臺服務(wù)器上啟動多個redis節(jié)點, 利用keepalive做虛擬IP實現(xiàn)訪問統(tǒng)一與高可用。其目的是在單臺服務(wù)器故障時可自動切換并短信報警，利用ruby語言實現(xiàn)多節(jié)點數(shù)據(jù)互通與故障切換功能解決單點故障問題。

在基于上述高可用情況下,數(shù)據(jù)平臺根據(jù)不同流水號分類成不同的key在redis中建立多個list序列, 根據(jù)查詢數(shù)據(jù)庫中最大值進行一定數(shù)量的自增, 自增后批量插入與流水號相對應(yīng)的list序列中并定時檢查redis中流水號數(shù)量進行補充。

在啟動多平臺時每個平臺統(tǒng)一連接redis集群, 各平臺接收到生成流水號的請求時根據(jù)不同流水號類型解析出不同key，然后利用redis acl庫的API 調(diào)用pop方法彈出與其對應(yīng)的value響應(yīng)給業(yè)務(wù)層 ，pop操作為原子性, 可保證數(shù)據(jù)唯一性。

4.4 7×24小時不停機

數(shù)據(jù)層平臺進程間通信基于共享內(nèi)存機制是目前最快的進程間通信技術(shù)，共享內(nèi)存是在linux系統(tǒng)級開辟的內(nèi)存空間，只要服務(wù)器不重啟，開辟的內(nèi)存空間就不會被釋放(手動釋放例外)?；诒緳C制可以保證進程意外崩潰時利用監(jiān)控機制重啟進程后，進程根據(jù)配置文件計算得出共享內(nèi)存地址后依舊可以通過其地址訪問到共享內(nèi)存，從而取出未處理的數(shù)據(jù)繼續(xù)進行處理。理論上管理進程不崩潰,數(shù)據(jù)層平臺可不間斷運行并隨時可以手動kill除管理進程外的任意進程。

基于流水號去中心化，共享內(nèi)存持久化的技術(shù)架構(gòu)下,結(jié)合Nginx進行多臺負載可保證平臺7×24小時不間斷運行并隨時可進行單臺服務(wù)器的數(shù)據(jù)平臺更新與維護工作，不會對線上業(yè)務(wù)產(chǎn)生任何影響。

此外，程序后臺啟動、切換用戶、切換shell、關(guān)閉shell等操作不會對啟動的進程造成影響，數(shù)據(jù)層平臺所有進程都采用守護進程方式運行。除手動觸發(fā)關(guān)閉外，系統(tǒng)不重啟將一直運行。

運行期間，數(shù)據(jù)平臺支持服務(wù)的熱更新，不停止當前業(yè)務(wù)的前提下對動態(tài)庫服務(wù)進行更新、停止和加載等操作?？紤]業(yè)務(wù)量的與日俱增, 為保證流水號的唯一性設(shè)置主機與從機并支持熱切換,在日后的使用場景中可保證接口不變的情況下自如切換主從。

4.5 服務(wù)分化

實際應(yīng)用中通常讀類業(yè)務(wù)耗時長、業(yè)務(wù)復雜，并且在大量請求到達時多線程解決方案并不理想，故大多選擇隊列緩存的方式進行處理。而因為讀類業(yè)務(wù)的超時會導致隊內(nèi)后續(xù)業(yè)務(wù)無法及時處理，最終導致連接超時，業(yè)務(wù)執(zhí)行失敗或因阻塞導致更新不及時使處理邏輯混亂等問題，如充值、動賬等核心業(yè)務(wù)，都可能因為讀類業(yè)務(wù)的阻塞導致請求方認為該次請求無效而重復請求，最終導致錯賬等問題的出現(xiàn)。

服務(wù)分化主要是根據(jù)其對數(shù)據(jù)庫操作，將服務(wù)劃分成讀與寫的類型?，F(xiàn)階段對數(shù)據(jù)庫的查詢操作劃分為讀類業(yè)務(wù),對數(shù)據(jù)庫的其他操作劃分為寫類業(yè)務(wù)(如:新增、修改、刪除)。在數(shù)據(jù)庫中使用自定義表用于持久化所有業(yè)務(wù)類型信息，方便后期新增與維護，在業(yè)務(wù)服務(wù)器啟動時會將所有業(yè)務(wù)服務(wù)進行初始化,通過讀取數(shù)據(jù)庫自定義表的內(nèi)容將相關(guān)啟用狀態(tài)下的業(yè)務(wù)類型加載到內(nèi)存中,使后續(xù)比對都在內(nèi)存中進行，提高效率。具體業(yè)務(wù)細分成1=讀、2=寫、3=其他，加載到內(nèi)存后，請求到達進行初步處理放入隊列, 主線程從隊列中取出消息后,根據(jù)請求的服務(wù)號在內(nèi)存中計算得到對應(yīng)業(yè)務(wù)類型,根據(jù)業(yè)務(wù)類型(讀/寫)分發(fā)到對應(yīng)的隊列中，后續(xù)工作進程會從隊列中取出請求進行處理并響應(yīng)。

服務(wù)分化成功地將讀類業(yè)務(wù)與寫類業(yè)務(wù)區(qū)分開來，互不影響，在實際應(yīng)用中讀類業(yè)務(wù)占到很大比例，通過分離的方式可以更具針對性地對讀類業(yè)務(wù)進行優(yōu)化，同時也解決了因讀類業(yè)務(wù)的阻塞導致其他后續(xù)業(yè)務(wù)無法及時處理的問題。

4.6 服務(wù)監(jiān)控

平臺的管理進程模式，可監(jiān)控通信進程與工作進程存活狀態(tài)，監(jiān)控服務(wù)調(diào)用時長。根據(jù)自定義時間判定超時服務(wù)后處理，目前生產(chǎn)環(huán)境是調(diào)用服務(wù)前記錄時間管理進程監(jiān)控。如果15 s后沒有改變，則認為該服務(wù)超時，自動殺掉其工作進程，從而減少業(yè)務(wù)邏輯層等待時長，提升響應(yīng)速度。

系統(tǒng)運行期間可控制日志輸出級別，包括調(diào)試模式(所有日志都輸出)、警告模式(只輸出警告和錯誤日志)和錯誤模式(只輸出錯誤日志)等日志級別。可通過更改配置文件靈活控制日志級別，對于問題服務(wù)可通過日志快速準確定位問題。此外，利用Redis轉(zhuǎn)存日志、異步打印日志、減少輸入輸出等待時間來提升整體平臺的處理能力，在redis不可用時可自主進行降級到本地輸入輸出打印,保證日志信息不丟失。

5 系統(tǒng)實現(xiàn)

原ETC系統(tǒng)的歷史數(shù)據(jù)主要存儲在DB2和mongo兩種類型的數(shù)據(jù)庫中，因此ETC數(shù)據(jù)層平臺在開發(fā)實踐中，為了最大程度減小數(shù)據(jù)遷移的風險，同時滿足業(yè)務(wù)需要，依然應(yīng)用DB2和mongo兩種類型的數(shù)據(jù)庫。在進行平臺和服務(wù)劃分時，分為DB2和mongo兩個數(shù)據(jù)層平臺，以便于根據(jù)數(shù)據(jù)庫種類和性能的不同對服務(wù)器資源等進行分配。訪問DB2數(shù)據(jù)庫的數(shù)據(jù)操作層服務(wù)搭載在DB2數(shù)據(jù)平臺上，訪問mongo數(shù)據(jù)庫的數(shù)據(jù)層服務(wù)搭載在mongo數(shù)據(jù)平臺上。數(shù)據(jù)服務(wù)搭載平臺，完成服務(wù)載入與卸載、請求接收、分發(fā)、響應(yīng)生成，服務(wù)組件以動態(tài)庫的形式封裝不同的服務(wù)。

5.1 數(shù)據(jù)層服務(wù)工作流程

當一個請求由客戶端發(fā)起后, 經(jīng)由前置服務(wù)器轉(zhuǎn)發(fā)至負載均衡服務(wù)后到達業(yè)務(wù)服務(wù)器,業(yè)務(wù)服務(wù)器進行邏輯判斷后向后臺發(fā)送請求,至此成功進入到新架構(gòu)的服務(wù)器內(nèi)部,開始正式處理及解析。服務(wù)的調(diào)用流程如圖7所示。

圖7 數(shù)據(jù)服務(wù)調(diào)用流程

1) 初始化階段。數(shù)據(jù)層平臺啟動，初始化一個下標為8位數(shù)的數(shù)組(系統(tǒng)協(xié)議的服務(wù)號定長為8位)并將數(shù)組內(nèi)容初始化為0，這些服務(wù)號是根據(jù)業(yè)務(wù)需求從10000000遞增而來，并根據(jù)業(yè)務(wù)進行細分。如果涉及讀數(shù)據(jù)庫則將其類型標記為1，如果非讀數(shù)據(jù)庫行為則標記為2，在添加服務(wù)時已將這些信息持久化保存到數(shù)據(jù)庫內(nèi)。在平臺初始化數(shù)組后, 讀取數(shù)據(jù)庫內(nèi)服務(wù)類型信息,并根據(jù)服務(wù)號對其所在下標數(shù)組的值進行更改,如10000001為讀服務(wù)對應(yīng)的類型值為1,則將開始初始化為0的下標號為10000001的數(shù)組值從0改為1,以此類推, 至此初始化工作已經(jīng)完成,所有業(yè)務(wù)需要調(diào)用的服務(wù)都已加載到內(nèi)存中并根據(jù)類型進行了細化。

2) 請求到達。一個新的請求成功轉(zhuǎn)發(fā)到數(shù)據(jù)層平臺后,平臺根據(jù)協(xié)議開始解析請求,截取服務(wù)號及消息體內(nèi)容,根據(jù)解析得到的服務(wù)號可以得知請求的業(yè)務(wù)類型,也可以根據(jù)自定義的服務(wù)號來判斷是否需要進行特別的邏輯處理,而且也可以結(jié)合服務(wù)號來定制相應(yīng)規(guī)則。如：讀類業(yè)務(wù)請求到達時,當前隊列如果負載超過80%則拒絕本次請求等個性化功能,如果本次服務(wù)號無特殊處理邏輯也無拒絕連接特征,則將其放入通信隊列當中,等待下一步處理。

3) 開始分發(fā)隊列。數(shù)據(jù)層平臺從通信隊列里取出一條經(jīng)上一步篩選過的請求報文后,將本次請求的服務(wù)號作為數(shù)組的下標,從中取出當前服務(wù)號下標數(shù)組的值,由此確定本次請求的操作類型。如果為讀類型,則將本次請求消息體內(nèi)容放入讀隊列中, 反之則放入寫隊列中。隊列的傳輸媒介考慮到效率問題，采用當前最快的進程間通信方式即共享內(nèi)存來完成，在此期間可根據(jù)業(yè)務(wù)需求自定義功能。

4) 請求處理階段。從消息隊列中獲取請求，根據(jù)Key值(服務(wù)號)獲取對應(yīng)服務(wù)的內(nèi)存地址，調(diào)用動態(tài)庫中的服務(wù)對其進行處理，并將響應(yīng)結(jié)果返回通信管理層，發(fā)送給前置。

至此數(shù)據(jù)層平臺從一個請求的發(fā)起、分發(fā)、處理、返回響應(yīng)的功能已介紹完畢。

此外，系統(tǒng)在添加或者更新服務(wù)組件時需要人工進行干預，處理流程如圖8所示。整個過程簡單易操作。主要操作流程是服務(wù)拷貝、服務(wù)列表更新、通信進程添加啟動服務(wù)。這個過程對數(shù)據(jù)層平臺無影響，也對其他正常運行的服務(wù)無影響，實現(xiàn)了服務(wù)的熱更新。

圖8 數(shù)據(jù)操作層人工干預流程

5.2 數(shù)據(jù)層平臺應(yīng)用優(yōu)勢分析

ETC數(shù)據(jù)層平臺本質(zhì)是應(yīng)用C++框架實現(xiàn)了微服務(wù)理念，按照業(yè)務(wù)功能分化出細粒度的數(shù)據(jù)服務(wù)，同時依據(jù)現(xiàn)有的先進技術(shù)對框架進行不斷完善。這種設(shè)計理念使得ETC系統(tǒng)在程序代碼層面、系統(tǒng)層面、系統(tǒng)響應(yīng)速度層面和部署維護層面展現(xiàn)出很大優(yōu)勢。

數(shù)據(jù)層平臺改造前后性能對比如表1所示。數(shù)據(jù)服務(wù)的單獨平臺化增強了與數(shù)據(jù)庫交互代碼的復用性，同時實現(xiàn)了系統(tǒng)間的代碼復用，可避免大量重復代碼的出現(xiàn)。細粒度的服務(wù)更加便于功能的新增與修改，增加了系統(tǒng)的擴展性。數(shù)據(jù)層平臺對前置系統(tǒng)的編程語言和架構(gòu)技術(shù)沒有要求，同時其可以與多種類型數(shù)據(jù)庫靈活交互，并且可支持多種通信協(xié)議，平臺接口相對靈活，具有很高的兼容性，增強了平臺的可用性。負載均衡、消息隊列、多線程和共享內(nèi)存技術(shù)的使用很好地提高了通信速度，實踐證明數(shù)據(jù)服務(wù)的響應(yīng)速度較改造前系統(tǒng)可提高至微秒級以內(nèi)。同時，數(shù)據(jù)層平臺支持服務(wù)級別的熱更新，進行不停機維護，服務(wù)新增或更新不會影響業(yè)務(wù)層邏輯代碼，對其他服務(wù)以及系統(tǒng)的整體運行也無任何影響。此外，相較改造前被動地處理投訴方式修改生產(chǎn)bug，數(shù)據(jù)層平臺可自主監(jiān)控平臺問題，并將監(jiān)控結(jié)果記錄，進行自查自修。

表1 數(shù)據(jù)層平臺改造前后性能對比表

數(shù)據(jù)層平臺是公司內(nèi)部自主研發(fā)，相較于開源系統(tǒng)或委托給第三方開發(fā)的系統(tǒng)，自主研發(fā)的系統(tǒng)平臺更具安全性以及應(yīng)變靈活性，系統(tǒng)后期升級、優(yōu)化的靈活性也更高，能夠快速且準確地響應(yīng)公司實際需求，可追蹤服務(wù)狀態(tài)記錄, 進行自定義處理。

6 結(jié) 語

本文主要目的和創(chuàng)新是根據(jù)北京ETC系統(tǒng)的實際情況，基于微服務(wù)架構(gòu)思想，利用C++框架搭建與數(shù)據(jù)庫交互的數(shù)據(jù)層平臺，實現(xiàn)對北京ETC系統(tǒng)的初步改造，從而解決原系統(tǒng)中的問題。數(shù)據(jù)層平臺用動態(tài)庫形式封裝了微服務(wù)，利用C++框架實現(xiàn)了服務(wù)的依賴注入控制反轉(zhuǎn)。數(shù)據(jù)層平臺具有微服務(wù)框架的特點，同時是自主研發(fā)的框架，在新技術(shù)的應(yīng)用上具有很靈活的選擇權(quán)。數(shù)據(jù)層平臺的搭建為ETC系統(tǒng)整體改造提供了條件，其松耦合的特點，更好地支持在傳統(tǒng)架構(gòu)下的業(yè)務(wù)邏輯層的代碼重構(gòu)。因此，下一步將重點考慮ETC系統(tǒng)業(yè)務(wù)邏輯部分的改造。