基于微服務架構社會化發(fā)行系統(tǒng)設計與實現(xiàn)

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

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

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

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

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

1 微服務架構優(yōu)勢與不足

1.1 微服務優(yōu)點

單體結構系統(tǒng)根據(jù)功能拆分為多個微小的服務，每個服務可單獨開發(fā)、編譯、部署等，相比單體架構微服務具有以下優(yōu)勢[4]。

（1）降低復雜度

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

（2）可獨立部署

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

（3）容錯

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

（4）可擴展

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

1.2 微服務不足

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

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

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

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

2 ETC 社會化發(fā)行業(yè)務功能

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

2.1 H5 新辦ETC 訂單

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

2.2 原生新辦ETC 訂單

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

2.3 ETC 設備激活

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

2.4 特殊業(yè)務辦理

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

2.5 支付功能

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

3 微服務架構設計

3.1 微服務拆分

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

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

表1 系統(tǒng)拆分表

3.2 架構總體設計

（1）技術選型

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

（2）架構設計

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

通過ETC 社會化發(fā)行業(yè)務功能、服務拆分、技術選型等分析，確定了微服務總體架構?？蓪⑾到y(tǒng)架構分為應用層、接入層、平臺服務層、數(shù)據(jù)層、基礎支撐層。系統(tǒng)架構圖如圖1 所示。

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

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

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

數(shù)據(jù)層：主要指Mongo 數(shù)據(jù)庫實例、Redis 緩存等。

基礎支撐層：包括服務器、網(wǎng)絡設備、等支撐系統(tǒng)的物理組件。

圖1 系統(tǒng)架構圖

4 微服務架構實現(xiàn)

4.1 服務注冊與發(fā)現(xiàn)

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

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

4.2 服務路由

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

圖2 Eureka 各元素通訊圖

4.3 微服務網(wǎng)關

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

本文采用SpringCloud Zuul 組件實現(xiàn)微服務網(wǎng)關服務，Zuul 不僅具有動態(tài)路由功能，還可通過過濾器組件自定義實現(xiàn)微服務安全認證、簽名驗簽等功能。動態(tài)路由與負載均衡：當客戶端請求進入網(wǎng)關服務，Zuul 根據(jù)微服務實例名與路徑匹配關系，自動將請求轉發(fā)到服務端。Zuul 路由轉發(fā)通過Ribbon 組件實現(xiàn)，Ribbon 根據(jù)自定義配置將請求動態(tài)負載到微服務，從而實現(xiàn)微服務高并發(fā)。安全認證：由于Http 請求是無狀態(tài)的，服務端無法區(qū)分安全訪問和非法訪問?？蛻舳苏埱蠓仗峁┑慕涌跁r，他們訪問的權限往往需要有一定限制，系統(tǒng)不會將所有接口對外開放。然后Zuul 組件默認路由并沒有校驗權限，為此需要借助zuul 組件另外核心功能過濾器ZuulFilter 來實現(xiàn)請求攔截。在過濾器中實現(xiàn)權限校驗邏輯，校驗通過才能請求微服務[10]。

4.4 服務容錯

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

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

4.5 微服務高并發(fā)以及高可用

根據(jù)遼寧省ETC 發(fā)行需求可知，在2019 年下半年要完成過去幾年甚至十幾年ETC 發(fā)行量的2-3 倍?？上攵到y(tǒng)在這段時間要承擔大量的請求數(shù)，因此系統(tǒng)要具備高并發(fā)以及高可用等特點。高并發(fā)是系統(tǒng)并行處理大量請求的能力，主要體現(xiàn)在系統(tǒng)快速響應、高吞吐量、高并發(fā)用戶量等指標。高可用是指系統(tǒng)是否具備穩(wěn)定運行的能力，比如某服務異常不可用時是否有備份提供服務，主要解決服務單點故障問題。

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

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

4.6 微服務調用關系

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

圖3 數(shù)據(jù)流向圖

5 微服務架構其他技術

5.1 統(tǒng)一日志處理ELK

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

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

圖4 ELK 日志處理流程

5.2 微服務監(jiān)控Adimin

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

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

5.3 單元測試與在線文檔Swagger

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

6 結語

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