于 曼 黃 凱 張 翔

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

0 引 言

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

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

1 關于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ā)行和充值等相關業(yè)務的系統(tǒng)。系統(tǒng)的邏輯架構如圖1所示。

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

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

(1) 代碼耦合性高。隨著業(yè)務量的不斷提升，代碼變得越發(fā)龐大，業(yè)務擴展變得愈發(fā)困難，對新需求的響應速度變慢，開發(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ù)操作相關的程序，將其設計為獨立的服務組件，解耦數(shù)據(jù)庫操作層與業(yè)務服務層。改造后的架構如圖2所示。

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

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

2 微服務架構介紹

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

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

圖3 微服務體系架構

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

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

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

圖4 ETC數(shù)據(jù)層平臺結構

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

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

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

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

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

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

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

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

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

4.2 負載均衡

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

4.3 redis集群化

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

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

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

4.4 7×24小時不停機

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

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

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

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

4.5 服務分化

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

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

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

4.6 服務監(jiān)控

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

系統(tǒng)運行期間可控制日志輸出級別，包括調(diào)試模式(所有日志都輸出)、警告模式(只輸出警告和錯誤日志)和錯誤模式(只輸出錯誤日志)等日志級別?？赏ㄟ^更改配置文件靈活控制日志級別，對于問題服務可通過日志快速準確定位問題。此外，利用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è)務需要，依然應用DB2和mongo兩種類型的數(shù)據(jù)庫。在進行平臺和服務劃分時，分為DB2和mongo兩個數(shù)據(jù)層平臺，以便于根據(jù)數(shù)據(jù)庫種類和性能的不同對服務器資源等進行分配。訪問DB2數(shù)據(jù)庫的數(shù)據(jù)操作層服務搭載在DB2數(shù)據(jù)平臺上，訪問mongo數(shù)據(jù)庫的數(shù)據(jù)層服務搭載在mongo數(shù)據(jù)平臺上。數(shù)據(jù)服務搭載平臺，完成服務載入與卸載、請求接收、分發(fā)、響應生成，服務組件以動態(tài)庫的形式封裝不同的服務。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 結 語

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