前后端分離模式下的WEB 系統集成方案*

王 鋒，劉俊波

（中國電子科技集團公司第30 研究所，四川 成都 610041）

0 引言

當前WEB 系統開發多采用前后端分離模式。前端組件化、工程化，后端數據化；前端實現人機交互邏輯，提供業務數據展示，后端為前端提供業務數據支撐；前后端通過RESTful 接口進行數據交互。這種模式下前后端架構分離，降低了人員要求，開發效率高，給系統設計與開發帶來了極大便利。前后端分離后，一個系統被分割為了兩個獨立的工程。用戶身份不同時，前端需要根據后端權限數據實現模塊鑒權，同時在多個WEB 系統集成部署時，需要為這些系統提供統一的界面呈現，解決系統之間的頁面組件互相調用、用戶身份的單點登錄、后端資源請求權限檢測等問題。為此，本文設計了一種針對前后端分離模式下的WEB 系統集成方案。

1 總體架構

前后端分離模式下，前端和后端是獨立架構，互不干涉。不同系統后端服務采用的語言、框架往往不同，如果要在這些不同系統內部實現統一模式的身份認證和權限檢測，極其困難且代價太高。為此借用微服務的架構模型，在后端服務前面增加一個獨立的API 網關模塊[1]，專門為這些使用不同語言框架開發的系統解決如單點登錄、資源鑒權等共性問題。

集成方案將系統分為前端展示層、中間接入層和后端業務服務層3 層，架構如圖1 所示。展示層即為前后端分離后的純前端，采用vue 框架。中間接入層為API 網關模塊，通常部署在后端業務系統前面，負責用戶身份認證、權限檢測和路由轉發等功能。API 網關與業務系統之間采用RESTful 進行交互[2]。后端業務邏輯層為業務系統的后端服務。

圖1 總體架構

2 前端集成

WEB 前端已經從傳統的MVC 模式進一步發展為MVVM 模式[3]。系統采用vue+vue-router+iview UI 搭建前端基礎開發框架。vue 是一套用于構建用戶界面的漸進式框架[4]，具有易用、靈活等特性，便于與第三方庫和既有項目整合，是整個前端框架的技術核心。vue-router 是針對vue 開發的路由插件，作為vue 的官方的路由管理器，提供單頁應用服務。iview UI 是一套基于vue 的高質量UI 組件，提供如表單控件、按鈕、導航菜單、表格、對話框等常用組件，能夠滿足絕大部分WEB 應用場景。前后端交互請求工具采用axios，可以自定義攔截器、處理攜帶票據、cookie、自動取消請求、防止CSRF/XSRF 等功能。

2.1 組件引用

一個業務系統由許多業務組件構成，每個業務組件就是一個獨立的模塊，可以單獨打包使用。組件可以進一步劃分為更細小的組件，這里稱為微組件。獨立打包的微組件實際就是一個WEB widget，具有“高內聚、低耦合”的優點[5]。業務系統之間可以調用對方系統的組件來使用，如圖2 所示。

圖2 前端頁面組件調用

采用vue-custom-element 進行業務組件封裝。圍繞vue 組件的小包裝器，能夠在vue、react、angular 這些前端框架中提供無縫的使用方式。頁面中只需要引用相應的javaScript 文件，然后在HTML標簽中引入相應的標記即可渲染出vue 組件，為不同業務系統組件的相互調用提供解決方案。

組件開發時，為方便每個業務組件單獨打包，需要在項目中為該業務組件添加一個打包入口文件。該文件的命名方式應該與系統名稱和業務名稱相呼應。例如，某監控系統的設備管理模塊對應的打包入口文件命名為monitor-dev，該業務組件打包后對應文件名稱也為monitor-dev.js。在其他系統中如果需要引用該業務模塊，引入monitor-dev.js 以及組件對應的HTML 標記即可。HTML 標記在組件的打包入口文件中定義，標記名稱應該和入口名稱保持一致，如vue.customElement(‘widget-monitordev’,Dev)，其中“widget”表示這個一個vue 微組件，monitor 表示該組件是監控系統所有，Dev 表示對應的vue 業務組件，在HTML 中引入＜widgetmonitor-dev>＜/widget-monitor-dev>標記對即可加載對應的業務組件。業務組件加載及工作流程如圖3所示。

①登錄系統；

②獲取認證token，存儲到sessionStorage；

③使用系統定義的組件加載方法，通過token加載業務系統b 的monitor_dev 組件；

④業務系統b 的組件加載接口向API 網關驗證token 合法性；

⑤下載monitor_dev.js；

⑥Monitor_dev 組件使用token 向業務系統b 請求業務數據；

⑦業務系統b 的業務模塊向API 網關驗證token 合法性；

⑧業務系統b 向客戶端組件返回業務數據。

圖3 業務組件加載及工作流程

2.2 前端鑒權

前端鑒權存在兩個方面的需求：一是用戶是否具備組件顯示執行權限；二是組件向后端發起數據請求時后端返回的權限結果處理。

針對組件在前端是否能夠顯示執行，需要根據后端給出的權限進行判別。基于vue 的標簽指令自定義了一個權限判斷指令v-permission，該指令會根據后端返回的用戶接口請求白名單進行匹配，只有當該組件所使用接口在白名單中，組件才會被顯示和執行。比如，一個設備添加按鈕組件devadd，頁面引用該標簽時增加相應的v-permission指 令，＜widget-dev-add v-permission>＜/widget-devadd>，那么前端就會對組件顯示進行權限鑒別。只有當前用戶被允許使用設備添加接口時，該按鈕才會在頁面中顯示出來，否則頁面會隱藏此添加按鈕。

組件向后端發起數據請求的權限結果處理，會通過axios 自定義攔截器實現。axios 攔截器分為請求前攔截和請求后攔截兩種。由于請求結果是后端返回，所以使用請求后攔截。在這個攔截器中，針對請求結果的權限處理可以進行統一定義，使得系統集成時能有一個統一的異常處理模式，從而提高用戶體驗。

3 后端集成

后端采用一個專用的API 網關模塊，負責業務系統注冊、用戶認證和資源訪問鑒權等方面的集成業務，使得業務系統可以專注于業務開發。

3.1 系統注冊

業務系統需要在API 網關上注冊其基本信息和資源信息。基本信息應包括系統標識、系統地址和端口等；資源信息主要包括菜單定義及接口信息表；這些資源信息有規范化的格式，多采用xml 數據文件格式。API 網關擁有這些信息后，可以由管理員為用戶訪問配置資源授權。

3.2 用戶認證

API 網關模塊存在兩種部署模式：一是所有業務系統部署在API 網關模塊后面，資源請求必須通過API 網關模塊轉發，稱為斷路式部署模式；二是業務系統可能部署在API 網關模塊外面，資源請求可以不經過網關直接到達業務系統，稱為旁路式部署模式。無論選擇哪種部署模式，在多個系統集成時都希望能實現單點登錄模式，即一次登錄認證后對多個業務系統都有效，訪問其他業務系統時無需再次登錄認證。針對這兩種部署模式，為實現單點登錄，對應有兩種登錄認證流程。

3.2.1 斷路式部署認證

認證流程如圖4 所示。

圖4 斷路式部署認證流程

A：瀏覽器發起認證登錄；

B：API 網關認證（根據系統實際認證協議要求確定）成功后，基于JWT 格式生成認證票據及刷新票據，并返回給瀏覽器客戶端，而瀏覽器客戶端將認證票據及刷新票據存儲在客戶端（Session Storage）；

C：瀏覽器訪問任意業務系統，帶上認證票據，API 網關驗證票據，解析出用戶身份信息；

D：API 網關將請求及用戶信息轉發給相應業務系統。

3.2.2 旁路式部署認證

認證流程如圖5 所示。

圖5 旁路式部署認證流程

A：瀏覽器訪問業務系統，認證登錄；

B：業務系統將請求重定向到API 網關的認證地址；

C：瀏覽器向API 網關認證地址發起認證請求；

D：認證（根據系統實際認證協議要求確定）成功后，API 網關向瀏覽器客戶端返回認證授權碼；

E：瀏覽器將認證授權碼返回給業務系統；

F：業務系統將認證授權碼發送給API 網關認證，對授權碼有效性進行驗證；

G：API 網關驗證授權碼合法后生成認證票據及刷新票據，并將驗證結果及票據返回給業務系統；

H：業務系統獲得驗證結果和票據后認證完成，將請求資源、認證票據和刷新票據返回給瀏覽器客戶端。

3.3 資源鑒權

由于API 網關部署存在兩種模式，因此資源訪問鑒權也存在兩種方式。

3.3.1 斷路式部署模式鑒權

斷路部署模式下，前端發起業務請求時需帶上認證時返回的token 票據。API 網關接收請求后，先對token 合法性做驗證，驗證過程需要解析出對應的終端用戶身份信息。驗證成功后，基于該用戶信息與需要訪問的資源進行訪問授權判斷，判斷完成后基于資源URI 進行路由轉發，將用戶信息和資源請求轉發給最終的業務系統。

3.3.2 旁路式部署模式鑒權

旁路式部署模式下，前端發起資源請求首先到達業務系統。業務系統需要向API 網關驗證請求中token 票據的合法性，API 網關將驗證結果和票據解析出來的用戶信息一并返回給業務系統。業務系統基于訪問資源和用戶信息，向API 網關發起資源訪問鑒權，鑒權成功后再調用響應的業務處理模塊向前端返回資源信息。

4 結語

本系統集成方案解決了前后端分離模式下多個業務系統集成部署時需要解決的各種問題，包括前端的頁面統一框架、頁面互相調用、頁面鑒權處理等，以及后端服務的用戶身份單點登錄認證、資源訪問權限檢測等。采用本方案后，業務系統能專注于用戶業務開發，集成部署簡單方便且節約了成本，適用于前后端分離模式下各種語言和框架開發的WEB 系統。