基于微服務架構社會化發行系統設計與實現

（遼寧高速通智慧出行有限責任公司 遼寧 110000）

在拆除省界收費站背景下，遼寧高速基于國家政策，遼寧高速統一管理的優勢，提出ETC 聚合發行的構想，并積極推動建設ETC 生態圈。截至2019 年6 月，遼寧省汽車保有量為800 多萬輛，ETC 用戶僅有240 萬左右，因此ETC 占有比只有20%多。根據政策要求，在2019 年年底力爭全省新增ETC 用戶420 萬，各市汽車ETC 安裝率在80%以上，通行高速公路車輛ETC 使用率在90%以上。這意味著短時間要完成過去幾年甚至十幾年的發行量，可以想象任務之艱巨。傳統ETC 發行主要在省級發行方的專業服務網點或銀行代理網點進行，發行渠道單一、效率低、體驗差、不利于大規模發展用戶。在ETC聚合發行的構想下，一方面增加線下網點，另一方面重點拓展網上渠道充分發揮互聯網渠道優勢[1]。

隨著ETC 業務大力推廣，各大支付機構、銀行等相繼爭搶ETC在線發行市場。支付寶、微信、京東、360、中移動、各大銀行等多種渠道開展發行業務，因此ETC 在線發行系統勢必會出現接入方式多樣化、系統請求高并發、個性化業務拓展、系統快速響應等特點。而傳統ETC 發行系統多采用單體架構模式實現，單體架構將前端頁面、業務邏輯處理和數據處理等統一編碼在單個應用下。在ETC 發展初期由于業務需求單一、業務辦理少，采用單體架構在代碼開發、測試、部署、維護等流程中相對比較簡單高效。但是隨著ETC 業務不斷發展，需求逐漸增多，代碼結構會變得越來越龐大，后期對代碼的整體理解和實施維護方面的困難也會增強[2]。再者，單體架構在單一進程當中運行，如果遇到系統維護升級等情況也會導致系統其他功能不可用，從而影響系統的可靠度。因此，單體架構應用具有業務拓展困難、技術選擇單一、代碼耦合度高、維護困難、可靠度低等缺點。

2014 年學者 Martin Fowler 正式提出微服務架構的概念。微服務架構是一種架構模式，是指根據業務需求將系統拆分為多個微小服務，服務獨立部署在不同的進程中，不同服務通過一些輕量級交互機制來通信，例如RPC、HTTP 等。服務可獨立擴展伸縮，每個服務定義了明確的邊界，不同的服務可以采用不同的編程語言來實現，由獨立的團隊來維護[3]。

針對目前ETC 在線發行業務場景和單體架構的缺陷，本文將分析微服務架構體系優缺點、以及如何基于SpringCloud 微服務技術實現具有前后端分離、高并發、高可讀、可擴展、可獨立開發部署等特點的微服務架構系統。

1 微服務架構優勢與不足

1.1 微服務優點

單體結構系統根據功能拆分為多個微小的服務，每個服務可單獨開發、編譯、部署等，相比單體架構微服務具有以下優勢[4]。

（1）降低復雜度

傳統單體架構將所有功能模塊堆積在同一應用下，而微服務架構根據業務功能將服務拆解成多個單體應用，不同應用可以專注不同的功能實現，因此微服務結構清晰、功能單一、編碼簡單明了。每個微服務可獨立開發測試維護，模塊之間互不影響，降低模塊間耦合度的同時也提高了代碼的可讀和可維護性。

（2）可獨立部署

由于微服務拆分為多個獨立的應用，因此微服務可以獨立部署在單個服務器容器下，并運行在獨立的進程中。當業務迭代時只需開發部署相關服務即可，降低測試工作量避免了大量回歸測試，同時也降低了服務發布的風險。

（3）容錯

在微服務架構下，當某一組件發生故障時，故障會被隔離在單個服務中。通過限流、熔斷等方式降低錯誤導致的危害，保障核心業務正常運行。

（4）可擴展

微服務擴展性可從兩個方面分析，即開發可擴展和部署可擴展。開發可擴展是指有新增完整業務需求時，可單獨開辟新的服務模塊，在不影響現有服務的情況下，通過獨立模塊的編碼開發、測試、部署、完成業務需求。部署可擴展是指當系統訪問量過大時，可通過添加負載服務器，解決系統響應慢的問題。單體架構也可以實現服務的橫向擴展，但由于單體應用包含系統所有的功能，而某些功能訪問頻次并不高，如添加負載會導致資源的浪費。而微服務可通過監控每個服務的請求量，根據實際情況擴展不同的服務，合理使用服務器資源。

1.2 微服務不足

任何事務的出現都具有兩面性，微服務雖然有很多優勢，但同時也有以下幾點缺陷[5]。

增加運維成本和開支成本：由于微服務架構是由多個微小服務組成，需要在多臺服務器部署且每個服務會負載集群，因此服務器開支成本較高。如果微服務某個模塊出現異常，往往需要排查整個請求鏈路執行情況，而單體架構只需在本服務器根據日志分析即可，在這個過程中無形增加了運維成本。

問題追蹤難度增加：微服務請求調用鏈會經過多個不同的服務，如一次請求出現問題，需分析請求到達服務的狀態和執行結果，從而增加追蹤問題的復雜度。

內容重復：對部分業務，流程大致相同時，如果不能很方便將代碼封裝，就可能導致在多個服務中有些重復性的代碼。除此之外還有日志重復，一個調用鏈可能要調用多個服務，在追蹤問題時，每個服務都要對參數和響應進行記錄，這樣就導致相同日志內容重復出現在多個地方。

2 ETC 社會化發行業務功能

傳統ETC 設備申請需客戶攜帶身份證原件、駕駛證原件、自駕辦理車輛前往附近ETC 營業廳進行辦理。然而營業廳辦理會給用戶帶來很多不便，如遇到客戶資料不全、附近沒有營業廳網點、辦理人員太多等情況都可能導致用戶辦理中斷。隨著省界收費站拆除和ETC 大力推廣，傳統辦理模式已不能滿足當前需求。為應對ETC 業務的不斷擴張、減少客戶出行、節省用戶時間，從而提出ETC 社會化在線發行需求。客戶借助APP 客戶端或微信小程序在線提交客戶身份證、車輛行駛證、銀行卡、郵寄地址等信息申請ETC 設備，后臺審核用戶訂單信息，如客戶信息填寫正確，業務人員將ETC 設備郵寄給客戶。客戶收到未激活的設備，通過APP 客戶端或微信小程序等自助在線激活設備。根據需求分析可分為如下幾個功能：

2.1 H5 新辦ETC 訂單

H5 新辦模式主要對接銀聯、工行、建行、農行、郵儲、中行、農信社等銀行接入方。各接入方客戶端APP 通過調用ETC 社會化發行接口拉起新辦H5頁面，首頁展示新辦相關協議，用戶勾選同意后，點擊下一步，跳轉到車輛信息頁。此頁需上傳用戶行駛本正反面，填寫車牌號車牌顏色。點擊下一步，調用后臺接口校驗車牌是否在黑名單以及是否已發行。校驗通過后進入開戶人信息頁，此頁填寫開戶人姓名、身份證信息。點擊下一步，后臺服務將姓名、身份證號等關鍵信息傳遞給銀行，進行一次簽約校驗，銀行校驗用戶信息是否填寫正確。校驗通過后，銀行給用戶發送短信驗證碼，頁面跳轉到下一頁，用戶輸入校驗碼。點擊下一步，后臺將用戶手機號、驗證碼等信息上送給銀行，進行二次簽約校驗。校驗通過后，后臺服務將訂單提交到內部發行核心系統，完成新辦訂單提交。

2.2 原生新辦ETC 訂單

我們知道H5 新辦模式只需接入方調用后臺接口拉起H5 頁面，并提供一次簽約和二次簽約接口相關接口即可。雖然H5 模式方便商戶接入，但是H5頁面風格固定并不能滿足其他商戶頁面個性化需求。而原生新辦模式是指社會化發行系統只提供用戶車輛信息提交、身份信息提交、校驗車輛是否在黑名單、校驗車輛是否已發行、訂單提交等接口服務，前端頁面由各接入方自行實現。接入方可自行選擇通過安卓或IOS 系統原生APP、微信或支付寶小程序來實現前端頁面，這樣可以滿足不同商戶頁面個性化需求。

2.3 ETC 設備激活

新辦訂單出庫后，用戶收到的設備（ETC 卡OBU 標簽）是未激活狀態。用戶需通過微信小程序、APP 等渠道自助激活設備。其中設備激活分為標簽激活和卡激活兩部分。系統主要提供寫標簽車輛信息、寫標簽系統信息、寫標簽結果確認、卡片個人化、卡片系統化等服務。

2.4 特殊業務辦理

用戶在使用過程中遇到特殊情況，如損壞標簽、損壞ETC 卡或變更車輛信息等情況時，可在線辦理標簽更換、ETC 卡更換、車輛信息變更、卡注銷、標簽二次激活等相關特殊業務。

2.5 支付功能

在ETC 大力推廣的背景下，雖然很多渠道的ETC 設備是免費領取的，但并不意味著所有渠道免費或者永久免費。如需用戶支付標簽費用，系統提供微信、支付寶、銀聯等多種付款渠道。

3 微服務架構設計

3.1 微服務拆分

微服務是指根據業務功能合理拆分為多個可獨立部署維護的子服務。微服務的拆分方案是決定系統是否具備高內聚、松耦合、可擴展、高可讀等特性的關鍵所在。

從ETC 社會化發行業務功能章節分析可將服務拆分為新辦訂單、設備激活、特殊業務、支付服務等模塊，每個模塊完成各自領域內業務互不干擾。鑒于新辦訂單、激活、特殊業務等需調用內部核心發行系統完成，為減少冗余代碼提高代碼復用率，提取出第三方發行模塊。第三方發行模塊調用核心發行系統服務并對內部服務提供接口，如此提高代碼復用率的同時使以上三個模塊更專注于業務邏輯處理。同理，可提取出第三方支付服務。由于微服務不會開放所有的功能，增加用戶鑒權服務可保護數據服務安全。系統拆分如表1 所示。

表1 系統拆分表

3.2 架構總體設計

（1）技術選型

ETC 社會化發行采用的是前后端分離可獨立部署維護的微服務系統架構。后臺提供REST 風格接口，既支持各接入方系統直接調用，又支持接入方客戶端嵌入H5 頁面進行調用。前端采用VUE 框架，VUE 是一個輕量級MVVM 即數據雙向綁定架構模式，可減少開發人員頻繁操作DOM 文檔，方便開發人員專注于業務邏輯處理。目前微服務架構主流的技術有Dubbo 和SpringCloud。Dubbo 是一款開源的輕量級、高性能Java RPC 遠程調用框架，其提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動發現和注冊。SpringCloud 是一個完整的微服務解決方案，其提供注冊中心、配置中心、網關、鏈路追蹤、Fegin 遠程調用、斷路器、消息總線等一系列組件。經過對比，Dubbo 是一款輕量級RPC 框架，而SpringCloud 是專注于微服務領域的具有全套解決方案的框架。本文采用SpringCloud 技術來實現ETC 社會化發行微服務后臺。

（2）架構設計

從微服務技術角度分析以下三個服務必不可少。網關服務：網關服務是微服務架構的統一入口，其核心功能是路由轉發與過濾器。路由轉發類似于Nginx 反向代理，可根據路由規則將請求轉發到對應微服務。注冊中心：注冊中心記錄了微服務和服務地址之間的映射關系，承擔服務注冊與發現功能。配置中心：配置中心就是把項目中各種配置、各種參數、各種開關，全部都放到一個集中的地方進行統一管理，并提供一套標準的接口。當各個服務需要獲取配置的時候，就來配置中心的接口拉取。當配置中心中的各種參數有更新的時候，也能通知到各個服務及時同步最新的信息，使之動態更新。

通過ETC 社會化發行業務功能、服務拆分、技術選型等分析，確定了微服務總體架構。可將系統架構分為應用層、接入層、平臺服務層、數據層、基礎支撐層。系統架構圖如圖1 所示。

應用層：直接面向用戶可視化操作的H5 頁面或各接入方客戶端應用。

接入層：接入層是指微服務的統一入口，接收客戶端所有請求，并根據地址與服務路由規則將請求轉發到對應微服務。網關服務不僅有路由轉發功能，還包括服務鑒權、系統限流等功能。

平臺服務層：平臺服務層指從業務功能與SpringCloud 微服務技術體系角度拆分的具體服務。從業務服務分為新辦訂單、特殊業務、設備激活、用戶鑒權等。從微服務組件分為注冊中心、配置中心、基于Hystrix 斷路器組件、基于Ribbon 的負載均衡組件、基于Sleuth 鏈路追蹤組件、SpringBoot Admin 微服務監控服務等。

數據層：主要指Mongo 數據庫實例、Redis 緩存等。

基礎支撐層：包括服務器、網絡設備、等支撐系統的物理組件。

圖1 系統架構圖

4 微服務架構實現

4.1 服務注冊與發現

隨著業務的發展，系統功能越來越復雜，微服務數量也不斷增加。并且服務的集群規模、服務位置、服務命名等都可能發生變化。傳統模式下服務調用方需要單獨維護服務提供方地址，這樣不僅增加了維護的復雜度而且當服務提供方地址變更或者新增負載服務后調用方也不能動態感知。為解決此類問題，微服務架構體系提出服務治理概念，用于解決微服務的注冊與發現問題。

Eureka 是SpringCloud 微服務體系中專為服務治理構建的組件。Eureka 服務治理主要包括服務注冊中心、服務提供者、服務消費者三個要素。注冊中心是Eureka 提供的服務端，主要用于提供服務注冊與發現功能。服務提供者提供具體服務的應用，將自身服務注冊到注冊中心，供消費者發現，其中主要功能包括服務注冊、服務同步、服務續約等。服務消費者從注冊中心拉取服務列表，消費者根據需求調用具體服務，其中主要功能包括獲取服務、服務調用、服務下線等[6]。Eureka 各元素之間通信關系如圖2 所示。基于本系統架構，API 網關、各業務服務以及微服務組件等都會通過Eureka 進行服務注冊與發現，Eureka 維護消費端以及服務端的綁定關系。例如消費端API網關服務通過注冊中心查找定位具體的服務端服務。

4.2 服務路由

Spring Cloud Ribbon 是一個基于Http 和TCP 的客服端負載均衡工具，它是基于Netflix Ribbon 實現的。它不像服務注冊中心、配置中心、API 網關那樣獨立部署，但是它幾乎存在于每個微服務的基礎設施中，SpringCloud 微服務體系中Zuul 和Fegin 等組件就是基于Ribbon 來實現路由轉發或者客戶端調用。Ribbon 有很多負載均衡算法，最簡單算法來自著名的 Round Robin 算法，即輪詢法[7]。其思想是根據服務實例組成的集合，按照順序依次循環調用，另外還有加權輪詢[8]、最小連接數算法等[9]。

圖2 Eureka 各元素通訊圖

4.3 微服務網關

微服務是由很多服務組合而成的系統，每個服務都需要鑒權、限流、權限校驗等功能。如果每個服務都對外暴露接口，各自實現鑒權、限流等邏輯。這樣不僅會生成代碼冗余，而且造成客戶端調用地址多，維護很不方便。更好的解決方案是提供API 網關，API 網關作為微服務統一入口，類似Nginx 反向代理，將客戶端所有請求路由到服務端進行處理。當然網關不是單純轉發功能，還可針對流量進行擴展，比如鑒權、限流、權限校驗、簽名驗簽、日志等。通過引入網關，客戶端無須關心后臺調用哪些服務，只需要與網關進行交互。網關引入帶來方便的同時也伴隨著安全隱患，如果網關服務不穩定、響應效率低等都可能導致服務不可用。ETC 社會化發行系統采用網關作為系統的唯一入口，實現了請求響應日志信息統一打印，借助網關過濾器實現了請求信息簽名驗簽、用戶鑒權等功能，有效解耦業務功能與非業務功能代碼。

本文采用SpringCloud Zuul 組件實現微服務網關服務，Zuul 不僅具有動態路由功能，還可通過過濾器組件自定義實現微服務安全認證、簽名驗簽等功能。動態路由與負載均衡：當客戶端請求進入網關服務，Zuul 根據微服務實例名與路徑匹配關系，自動將請求轉發到服務端。Zuul 路由轉發通過Ribbon 組件實現，Ribbon 根據自定義配置將請求動態負載到微服務，從而實現微服務高并發。安全認證：由于Http 請求是無狀態的，服務端無法區分安全訪問和非法訪問。客戶端請求服務提供的接口時，他們訪問的權限往往需要有一定限制，系統不會將所有接口對外開放。然后Zuul 組件默認路由并沒有校驗權限，為此需要借助zuul 組件另外核心功能過濾器ZuulFilter 來實現請求攔截。在過濾器中實現權限校驗邏輯，校驗通過才能請求微服務[10]。

4.4 服務容錯

在微服務架構中，系統拆分成了多個微小服務，各微服務之間通過服務注冊與發現的方式互相依賴。由于每個服務運行在不同的進程，通過遠程調用方式互相通訊，這樣很可能出現網絡延遲或者被調用服務本身故障，因此導致調用方的對外服務也出現延遲，若此時調用方請求不斷增加，最后調用方可能出現無法響應而形成任務積壓，線程資源無法釋放，最終導致自身服務的癱瘓，甚至出現故障蔓延導致整個服務不可用。為了解決這樣的問題，因此產生了斷路器等一系列的服務保護機制。

針對上述問題，在Spring Cloud Hystrix 中實現了斷路器、線程隔離等服務保護功能。它是基于Netflix 的開源框架 Hystrix 實現的，該框架目標在于通過控制那些訪問遠程系統、服務和第三方庫的節點，從而對延遲和故障提供更強大的容錯能力。Hystrix 具備了服務降級、服務熔斷、線程隔離、請求緩存、請求合并及服務監控等強大功能[6]。例如網關服務通過Ribbon 路由到各級服務，Ribbon 默認實現了斷路器功能，當下級服務出現異常時能快速響應，避免大量請求堆積到網關從而導致整個服務不可用。

4.5 微服務高并發以及高可用

根據遼寧省ETC 發行需求可知，在2019 年下半年要完成過去幾年甚至十幾年ETC 發行量的2-3 倍。可想而知，系統在這段時間要承擔大量的請求數，因此系統要具備高并發以及高可用等特點。高并發是系統并行處理大量請求的能力，主要體現在系統快速響應、高吞吐量、高并發用戶量等指標。高可用是指系統是否具備穩定運行的能力，比如某服務異常不可用時是否有備份提供服務，主要解決服務單點故障問題。

系統高并發可從垂直擴展和水平擴展方面出發。垂直擴展：一提高單機硬件處理能力，比如增加系統內存、增加系統內核數等。二提高微服務快速響應能力。使用緩存將系統常用的用戶信息、商戶信息等基礎數據、以及更新頻次多查詢慢的統計數據放置在JVM 內存中，減少頻繁的數據庫查詢以及頻繁的IO 操作。使用線程池減少頻繁創建線程所占用的資源和時間，比如數據庫連接線程池。優化查詢語句，數據查詢在業務處理占比很高，通過優化查詢語句以及表結構添加索引等手段，可有效解決系統響應慢的問題。水平擴展，垂直擴展可提高單體服務的處理能力，但單機服務器處理能力有限面對高并發請求往往會出現請求丟失、內存溢出、連接超時等情況。微服務特點是通過分析，將業務量大、頻繁使用的業務模塊進行水平擴展。水平擴展是將微服務整體部署在新服務器下，可根據需求部署多臺服務，可精準定位減少資源浪費并且有效解決系統高并發問題。

系統高可用是指系統是否具備穩定的運行能力，如網關服務、注冊中心、業務服務等部署在單節點服務器，當請求量超出瓶頸時可能會出現單點故障。在服務注冊與發現段落，我們知道注冊中心Eureka可集群部署，實現服務同步，從而達到互為備份的目的。在服務路由段落分析，每個微服務可添加負載服務器，Ribbo 可通過負載策略將請求轉發到“活著”的微服務下，從而解決單點故障問題。網關服務作為微服務入口，請求方來自用戶，可通過F5、Nginx 反向代理等實現網關集群部署等，或者通過keepalive 地址漂移技術實現網關熱備，以達到網關高可用。

4.6 微服務調用關系

微服務特點是服務多、調用關系復雜，每一次請求鏈路會經過多個服務，所以微服務之間調用關系是否能清晰表達十分重要。通過服務拆分設計與架構總體設計分析以及SpringCloud 微服務技術特點，得到本系統數據流向圖如圖3 所示。

圖3 數據流向圖

5 微服務架構其他技術

5.1 統一日志處理ELK

從第1 章分析我們知道微服務架構有復雜度低、獨立部署、高容錯、可擴展等優勢，同時也有運維開支成本高、問題追蹤復雜、內容重復等不足。其中問題追蹤復雜和內容重復等都與日志打印方式息息相關。每次請求鏈路會經過多個服務且每個服務有多臺負載服務器，如果服務出現異常維護人員需要通過查找鏈路經過的所有服務日志來定位問題，因此追蹤問題變得異常復雜。針對現有問題，如果微服務日志統一收集在一個服務器且能通過唯一標識搜索每次請求鏈路上所有日志，這樣不僅能減少開發人員定位問題難度還能減少重復日志打印。

ELK Stack 是軟件集合Elasticsearch、Logstash、Kibana 的簡稱，由這三個軟件及其相關的組件可以打造大規模日志實時處理系統。其中，Elasticsearch 是一個基于 Lucene 的、支持全文索引的分布式存儲和索引引擎，主要負責將日志索引并存儲起來，方便業務方檢索查詢。Logstash 是一個日志收集、過濾、轉發的中間件，主要負責將各條業務線的各類日志統一收集、過濾后，轉發給 Elasticsearch 進行下一步處理。Kibana 是一個可視化工具，主要負責查詢 Elasticsearch的數據并以可視化的方式展現給業務方，比如各類餅圖、直方圖、區域圖等。ELK 的出現提供了微服務日志統一收集存儲，并且提供可視化界面減少開發人員日志查詢工作量。結合微服務鏈路追蹤技術，將請求鏈路唯一標識存儲于Elasticsearch，通過該唯一標識可將鏈路日志一次查出。高并發情況下微服務同步日志打印存儲會大大影響程序執行效率。本文結合Logback 日志組件、Redis 消息隊列、ELK 軟件來實現微服務日志異步統一收集存儲[11]。ELK 日志處理流程如下圖4 所示。

圖4 ELK 日志處理流程

5.2 微服務監控Adimin

微服務系統由多個模塊組成，且每個模塊可部署在多臺服務器，這樣解決單點故障的同時提高系統高并發。在生產服務運行當中，系統可能會出現很多問題，比如內存溢出、磁盤空間不足、系統響應超時、服務異常退出等問題。由于微服務的系統部署或者網絡調用關系非常復雜，人工發現問題變的越來越復雜，因此微服務監控扮演著重要的角色。

SpringBoot Admin 是一個管理和監控SpringBoot 應用程序的開源軟件，是在SpringBoot Actuator[12]接口基礎上進行UI 美化封裝的監控工具。與注冊中心Eureka 結合使用可監控微服務服務的健康狀況，例如服務器內存和磁盤空間使用情況、JVM 和內存指標、在線修改日志打印級別、請求鏈路響應時間、服務上線或下線狀態變更通知等。

5.3 單元測試與在線文檔Swagger

傳統接口文檔需開發人員根據接口規范編輯紙質文檔。由于接口每次升級改造都需同步修改紙質文檔，因此可能會出現多個版本文檔，也可能導致最新的文檔與實際接口不一致，所以給開發人員帶來額外的工作量。Swagger 是一個規范和完整的框架，用于生成、描述、調用和可視化 Restful 風格的 Web 服務。Swagger 提供在線API 接口文檔，開發者可通過瀏覽器在線查看接口規范并且可在線單元測試。

6 結語

在拆除省界收費站的背景下，ETC 發行業務得到大力推廣，傳統辦理模式遠遠不能滿足當前業務需求。本文通過對比單體架構和微服務架構優缺點，決定采用微服務架構來設計并實現社會化發行系統。社會化發行系統采用前后端分離技術。前端使用VUE 框架實現H5頁面，為各商戶接入提供方便快捷的解決方案。微服務后臺采用SpringCloud 技術體系，其具備獨立開發部署、松耦合、彈性擴張、高并發等特點。面對不同接入方需求，本系統即提供通用H5 頁面又提供REST 風格微服務接口。因此不僅能快速響應不同的需求，而且能適配需求的彈性擴展。由于社會化發行系統并發能力以及擴展能力增強，可支持業務不斷增加、擴展發行渠道。隨著本系統的上線部署，客戶可隨時隨地在不同渠道在線辦理ETC 發行業務，不僅有效解決了網點少、距離遠、排隊等待等問題，還大大提高了ETC 發行效率，在2019 年下半年發行430 萬套ETC 設備，高效完成遼寧省ETC 發行任務。