基于微服務的Web系統(tǒng)功能架構設計與實現

魏東紅，王其才，商 超

（中國電子科技集團公司 第五十四研究所，河北 石家莊 050000）

1 微服務架構

1.1 概述

微服務架構的概念由Martin和James在2014年正式提出，有別于傳統(tǒng)的單應用服務架構與SOA(Service-Oriented Architecture，面向服務架構）。單應用架構的所有業(yè)務邏輯及實現全部在一個工程中，開發(fā)方式簡單，但耦合性強，隨著系統(tǒng)的升級，復雜度也越來越高，后期維護成本較大［1］；SOA將系統(tǒng)的邏輯功能進行服務化拆分，降低了服務之間的耦合性；微服務架構是在SOA的基礎上逐漸發(fā)展而來，將系統(tǒng)的邏輯功能進一步細化拆分，變?yōu)槎鄠€高內聚、低耦合的微型服務，可由不同的團隊、不同的編程語言、不同的設計模式、不同的存儲數據庫開發(fā)和維護，每個微服務使用獨立的進程進行部署［2］，微服務之間采用輕量級的通信機制進行數據交互。相比SOA，微服務的分解粒度更細、通信機制輕量化、開發(fā)迭代速度快、服務測試可實現自動化［3］。

1.2 架構

微服務架構一般分為注冊中心、微服務(含網關）、數據庫等，如圖1所示。

圖1 微服務架構

2 Web系統(tǒng)架構設計

2.1 架構設計

鑒于目前存在的服務功能劃分不清晰問題，本文探討一種通用的Web系統(tǒng)設計架構，將微服務架構細化分解，能夠滿足大多數使用場景，如圖2所示。

圖2 Web系統(tǒng)架構設計

Web系統(tǒng)架構主要分為注冊中心、網關、登錄認證、反向代理、消息中間件、各類功能性微服務，貫穿服務訪問全流程，微服務、注冊中心、代理等均可以Docker容器的方式快速發(fā)布部署與啟動［4］。

2.2 注冊中心

微服務通過注冊中心有機結合在一起，未使用注冊中心時，需要將調用系統(tǒng)的地址寫入配置中，以便調用系統(tǒng)提供的服務接口。微服務啟動時，向注冊中心注冊，注冊中心會維護微服務的健康狀態(tài)以及調用信息，接口調用時，系統(tǒng)無需事先知道對方的地址和端口等信息，通過與注冊中心的交互，可獲取對方微服務的信息，進行接口的調用，例如Spring Cloud中的Feign接口，只需配置對應的服務名即可。常用的注冊中心有Zookeeper，Consul，Eureka，Nacos等。

2.3 反向代理

反向代理將瀏覽器端的請求映射至對應的微服務或靜態(tài)文件，獲取前端靜態(tài)文件(HTML，JS，CSS等）、通過Ajax交互數據、連接認證服務器均可通過代理進行地址映射，一般的軟件設計中，采用Nginx代理。Nginx實現了負載均衡，在服務集群部署的情況下，多個微服務可分擔負載，避免因為某個服務下線引起系統(tǒng)崩潰。

2.4 服務網關

服務網關對Web瀏覽器的請求進行統(tǒng)一轉發(fā)，將瀏覽器端的請求和后臺微服務群體隔離，同時集成認證服務的配置，實現用戶鑒權，未通過認證的請求重定向至登錄界面，用戶登錄后，網關對瀏覽器請求進行轉發(fā)，并將數據返回至瀏覽器呈現。鑒于服務網關的統(tǒng)一轉發(fā)功能，可記錄用戶的操作日志，便于分析用戶行為，監(jiān)控請求及服務的運行情況，對客戶端請求進行熔斷和限流處理等。常用的服務網關有Spring Cloud Gateway，Kong，Dubbo Proxy等。

2.5 登錄認證

Web管理系統(tǒng)通常進行登錄認證，網關登錄認證可采用外部的認證服務，也可單獨實現，由于系統(tǒng)中可能存在多個微服務具備管理頁面，因此需要實現單點登錄(SingleSignOn，SSO）功能，用戶登錄系統(tǒng)后，可獲得整個系統(tǒng)相關服務的訪問權限，訪問互相信任的服務頁面，無需二次登錄，提升用戶體驗。登錄認證可與網關相配合，常用的認證服務協議有CAS，OAuth2，WebAuth等。

2.6 消息中間件

消息中間件實現了微服務之間的解耦，同時滿足應用服務的擴展需求，微服務之間可通過消息機制進行通信，服務發(fā)布者可直接將消息發(fā)送給消息中間件，無需等待處理消息的服務是否啟動，且支持多個消息的消費者，減少了繁雜的、相似的代碼，隨后消息中間件將消息存放在若干隊列中，消息的消費者讀取消息隊列后，對關注消息進行處理，目前常用的消息中間件有Activemq，Rabbitmq等。

2.7 事件通知微服務

事件通知類微服務主要負責監(jiān)聽寫入消息中間件的事件，將事件轉化為數據處理的通知(包括對數據進行處理、前端數據的推送呈現等），然后在消息中間件中發(fā)布消息主題與內容，訂閱該主題的微服務可獲取消息內容進行處理，這樣做可以將事件產生與處理徹底解耦，方便數據處理方式的改進和替換。

2.8 頁面類微服務

頁面類微服務主要包括頁面相關的靜態(tài)文件和數據推送相關服務，目前Nodejs，Webpack，Npm，Spring Boot等工具均能很好地實現前端服務的獨立開發(fā)，當前比較流行的前端開發(fā)框架有Vue，Angular，React等［5］，這些框架的出現使得開發(fā)更為便捷，易于實現前后端服務的分離。前后臺分離能夠使團隊更加專注于前端或后端的開發(fā)，工作職責更加明確，有助于提升團隊技術水平和研發(fā)能力。

2.9 數據處理類微服務

數據處理類微服務主要負責系統(tǒng)的復雜數據處理，包含數據整合、算法、視圖模型等。由于該類微服務需要經常進行復雜處理和計算，占用的資源較其他微服務多，因此需要部署在性能較高的節(jié)點，此類微服務是系統(tǒng)的核心，保證服務的穩(wěn)定性、可靠性尤為重要，通常通過集群部署和負載均衡配置，緩解該類服務的運行壓力。

2.10 數據訪問類微服務

數據訪問類微服務主要負責數據庫的持久化操作，進行數據存儲、獲取、簡單統(tǒng)計等操作。該類服務直接面向數據庫，可配置Hibernate，MyBatis，Spring JPA等持久化工具，簡化程序，其接收其他微服務的數據訪問請求，能夠進行數據模型轉換、存儲數據和返回微服務所需的數據。

2.11 接口適配類微服務

接口適配類微服務主要負責處理與外部系統(tǒng)或設施的接口，每個服務可進行單獨配置，由于系統(tǒng)接口多種多樣，數據也千差萬別，因此接口適配類微服務數量繁多，對同一類別的數據，如何統(tǒng)一數據模型是降低系統(tǒng)復雜度的關鍵因素，接口適配一般為雙向服務：(1）通過接口獲取數據之后進行簡單處理，然后將數據發(fā)送至數據處理類微服務或數據訪問類微服務。(2）接收內部微服務的數據，將數據處理為外部系統(tǒng)所需格式，并通過接口進行數據發(fā)送。

3 停車場監(jiān)控微服務架構

下面以停車場監(jiān)控為例，說明基于微服務的Web系統(tǒng)設計架構實現方式，系統(tǒng)架構如圖3所示。

圖3 停車場監(jiān)控微服務架構

監(jiān)視流程如下：

(1）用戶在客戶端訪問停車場監(jiān)控系統(tǒng)界面，訪問請求通過Nginx代理至服務網關，服務網關通過約定的請求消息頭判斷用戶是否已經登錄，若未登錄，則將請求重定向至認證服務提供的統(tǒng)一登錄界面，并帶有源請求路徑信息。

(2）用戶輸入登錄名和密碼，并成功登錄，頁面隨機跳轉至停車場車位監(jiān)控頁面。

(3）停車場車位監(jiān)控頁面發(fā)送請求獲取停車位和停車位占用信息，服務網關將請求轉發(fā)至數據處理服務，數據處理服務調用數據訪問服務接口從數據庫獲取數據，通過一定的方式處理后，將數據視圖返回至監(jiān)控界面，在前端生成各類視圖。

(4）點開停車場的視頻控制管理界面，由于用戶已經登錄系統(tǒng)，獲得了相關系統(tǒng)的授權信息，可以直接訪問視頻控制界面，對視頻設備進行控制，無需二次登錄。

(5）當停車情況發(fā)生改變時，例如車輛駛入或離開停車位，傳感器適配微服務接收傳感器的變化數據，判斷變化內容，根據變化內容生成事件，存入消息中間件，同時調用數據訪問微服務將變化內容存入數據庫中。事件通知微服務監(jiān)聽事件的發(fā)生，生成頁面推送更新消息；Web微服務監(jiān)聽頁面更新消息并將更新推送至前端監(jiān)控頁面，頁面經過數據處理后顯示變化信息。

(6）用戶退出系統(tǒng)后，之前的登錄信息在認證服務注銷，此時監(jiān)控頁面、監(jiān)控錄像均不可查看。

4 結語

目前微服務架構還存在多種待優(yōu)化問題，本文通過將統(tǒng)一認證服務納入Web系統(tǒng)架構，實現系統(tǒng)的單點登錄功能，避免用戶二次登錄，將微服務按照功能分為服務網關、事件通知、數據處理、數據訪問、接口適配，各類服務職責明確，邊界清晰，有利于進行微服務的設計。微服務之間通過消息中間件的方式實現服務之間異步交互，使服務之間進一步解耦，并以停車場監(jiān)控系統(tǒng)為例，對系統(tǒng)架構進行解釋說明，為進行Web系統(tǒng)的開發(fā)提供了一種架構設計方案。