基于微服務架構的稅務管理系統(tǒng)在PaaS 平臺上的設計與實現(xiàn)

王夏洋

（中國海洋石油集團有限公司，北京100010）

0 引言

中海油稅務管理系統(tǒng)于2014 年實施上線。系統(tǒng)的建立為集團公司提供了統(tǒng)一的稅務信息管理平臺，對稅費數(shù)據(jù)統(tǒng)計、全稅種納稅申報管理、日常辦稅管理、重大業(yè)務事項稅務管理、稅務風險管理等工作進行高效的支撐和管控，可對集團稅務工作全貌進行全面、及時的掌控。同時，通過信息化手段實現(xiàn)了企業(yè)內(nèi)、外部稅務管理所需要的智能化、精細化的納稅申報管理、日常辦稅管理、重大業(yè)務事項稅務管理、稅務風險管理等業(yè)務功能管理和上述業(yè)務事項的IT 流程化管控。由于稅務管理系統(tǒng)構建在單體架構下，隨著系統(tǒng)不斷的使用，面臨以下問題：

（1）模塊之間耦合度高（前后端一體化），其中一個模塊升級需要其余全部升級，升級部署風險高。

（2）不能靈活地進行分布式部署，數(shù)據(jù)量越來越大，系統(tǒng)擴展性差，系統(tǒng)性能越來越差。

（3）業(yè)務多變，用戶對界面?zhèn)€性化的要求越來越高。

（4）各分子公司對頁面展示需求不一致，系統(tǒng)重復性開發(fā)工作量大。

（5）系統(tǒng)測試成本增加，版本管理要求高。

微服務[1-3]（Micro service）具有松耦合、獨立部署、開發(fā)效率高、代碼維護易、成本攤薄等優(yōu)點。

同時，PaaS 平臺（Platform-as-a-Service，平臺即服務），是將軟件開發(fā)平臺以一種服務的形式提供給用戶，為用戶提供全生命周期支持，使用戶方便地進行測試和開發(fā)[4-5]。

鑒于此，本文設計了一種基于微服務架構的稅務管理系統(tǒng)，并通過部署PaaS 平臺實現(xiàn)了系統(tǒng)的高效開發(fā)和部署。

1 相關工作

1.1 微服務架構

（1）微服務架構概念

微服務指通過一組服務實現(xiàn)應用，各個服務獨立運行于不同的進程中，不同的服務通過輕量級的交互機制進行通信[6]。每個服務都圍繞業(yè)務功能進行構建，且各個服務均維護著自身的數(shù)據(jù)存儲、業(yè)務開發(fā)、自動化測試案例和獨立部署機制。

微服務架構中前后端分離不僅僅只是一種開發(fā)模式，而是一種架構模式（前后端分離架構）。前后端分離時必須區(qū)分前后端的項目。前后端需要獨立部署，用不同的工程，不同的代碼庫，不同的開發(fā)人員。前端和后端工程師需要就交互式接口達成一致，以實現(xiàn)并行開發(fā)，開發(fā)結束后需要進行獨立部署，前端通過AJAX 來調(diào)用超文本傳輸協(xié)議（HyperText Transfer Protocol，HTTP）的請求調(diào)用后端的表述性狀態(tài)傳遞（Representational State Transfer，REST）應用程序編程接口（Application Programming Interface，API）。前端只需要關注頁面的樣式與動態(tài)數(shù)據(jù)的解析，而后端則側重于特定的業(yè)務邏輯。

（2）微服務架構技術

基于微服務架構和Docker 容器技術的PaaS 平臺為開發(fā)人員提供了一系列流程，用于快速開發(fā)、部署、運維管理、持續(xù)開發(fā)和持續(xù)集成。

目前，業(yè)界成熟的微服務架構包括Netflix、Spring Cloud 和Dubbo。Spring Cloud 基于Spring Boot，提供了開發(fā)微服務所需的組件，它包含很多子框架，其中Spring Cloud Netflix 是其中的一套框架。

（3）微服務部署

微服務是一系列單功能、細粒度的服務，將業(yè)務分解為單獨的服務單元，可擴展性強，低耦合，可以用不同的語言進行開發(fā)。由于每個微服務都以集群的方式部署，因此服務需要在彼此調(diào)用時進行負載平衡。

微服務在Docker 容器中作為鏡像運行[6]，Docker容器技術使我們的服務部署簡單高效。

（4）服務容錯

微服務之間存在復雜的依賴關系，本文使用Hystrix 組件進行微服務架構的容錯處理。Hystrix 是Netflix 的開源組件，通過熔斷、隔離、回退和限流為服務提供靈活的容錯保護，以確保系統(tǒng)穩(wěn)定。

（5）動態(tài)配置中心

微服務具有許多依賴配置，并且在服務操作期間需要動態(tài)修改某些配置參數(shù)。本文使用Spring Cloud的configserver 服務來實現(xiàn)動態(tài)配置中心。

1.2 PaaS平臺

（1）PaaS 平臺特點

①系統(tǒng)彈性伸縮

通過應用程序和數(shù)據(jù)分離以及集群部署，系統(tǒng)可實現(xiàn)快速的在線擴展、處理能力的線性擴展和自動故障處理。可以靈活地擴展相對獨立的應用程序主機。其特點有：

在線快速擴容：系統(tǒng)擴展運行時間短，無數(shù)據(jù)遷移，服務不中斷。

處理能力線性擴展：系統(tǒng)處理能力可通過增加節(jié)點的近線性來實現(xiàn)高吞吐量和高并發(fā)處理能力，并響應服務的爆炸式增長。

故障自動接管：群集可以自動發(fā)現(xiàn)故障節(jié)點并調(diào)整任務調(diào)度策略以接管故障節(jié)點，而不會影響處理，并使系統(tǒng)保持高可用性。

②應用集群化部署

將緊耦合的大型應用模塊化為多個小型應用，資源池提供系統(tǒng)資源的整體利用，將子模塊拆分，部署在資源池中。池化后，實現(xiàn)了應用的彈性伸縮，從而按需分配硬件，充分提高了資源利用率。

③通過數(shù)據(jù)分類，分離應用程序和數(shù)據(jù)

根據(jù)數(shù)據(jù)的實時性、重要性、敏感性等因素，將數(shù)據(jù)分為幾類，每類的數(shù)據(jù)對系統(tǒng)的作用、存儲和保護方式也各有不同[12]。

通過對應用提供數(shù)據(jù)的透明訪問，屏蔽數(shù)據(jù)的位置差異、數(shù)據(jù)分布差異、數(shù)據(jù)存儲等差異：

位置無關性：無論數(shù)據(jù)存儲子在本地還是遠程，最好對應用程序透明。

分布無關性：數(shù)據(jù)分布在多個數(shù)據(jù)節(jié)點上，對應用程序是透明的。例如，查詢某個客戶的所有相關數(shù)據(jù)，盡管相同的用戶信息分布在多個數(shù)據(jù)節(jié)點上，但它就像是應用程序的集中式數(shù)據(jù)庫。

存儲無關性：數(shù)據(jù)存儲在內(nèi)存庫、物理庫、文件或緩存中，對應用程序是透明的。

④合理規(guī)劃實現(xiàn)數(shù)據(jù)分布式部署

對不同業(yè)務的數(shù)據(jù)和不同類型的數(shù)據(jù)進行有效規(guī)劃部署。通過一定條件，將存儲在同一數(shù)據(jù)庫中的數(shù)據(jù)分發(fā)到多個數(shù)據(jù)庫，并通過路由規(guī)則訪問特定數(shù)據(jù)庫。

⑤數(shù)據(jù)平臺化

數(shù)據(jù)平臺化是指針對應用程序和數(shù)據(jù)架構進行重組、規(guī)劃和調(diào)整，將業(yè)務數(shù)據(jù)和狀態(tài)數(shù)據(jù)與業(yè)務流程和應用程序分離，實現(xiàn)應用的輕量化、無狀態(tài)；構建統(tǒng)一的數(shù)據(jù)訪問層以實現(xiàn)對數(shù)據(jù)的共享訪問。數(shù)據(jù)平臺化是數(shù)據(jù)處理線性擴展的前提和基礎。

（2）中海油PaaS 平臺

中海油PaaS 平臺采用紅帽開源容器云OpenShift[7]，OpenShift 構建基于Kubernetes 的企業(yè)應用云平臺。

PaaS 平臺服務具備快速愈合能力，即當一個服務壞掉，OpenShift 會自動發(fā)現(xiàn)并部署一個新的服務。OpenShift 容器平臺是一個以開發(fā)人員為中心的PaaS平臺，支持各行業(yè)各種規(guī)模公司的應用開發(fā)團隊。OpenShift 容器平臺及其相關程序構成了PaaS 包，為企業(yè)IT 開發(fā)人員提供了多種平臺選擇，實施開發(fā)活動，支持現(xiàn)有或重構的云應用程序。該PaaS 平臺專注于三個主要領域：應用開發(fā)和交付、應用架構、基礎設施及應用平臺[13]。

OpenShift 提供了大量的核心軟件組件。它結合了Docker 和Kubernetes 集群管理，可用于開發(fā)人員生命周期自動化（Lifecycle Automation）和容器管理。生命周期自動化提供預置模板、產(chǎn)品和構建計劃，使開發(fā)人員能夠簡化應用程序的構建和部署過程。

首先介紹ROS的基礎概念以及導航相關的功能包；然后按照實驗的研究步驟分別介紹了定位方法、機器人運動模型、卡爾曼濾波和機器人控制策略；進而論述實現(xiàn)定位的算法和相關函數(shù)；最后分析在Rovio移動機器人平臺上所獲得的測試數(shù)據(jù)和結果，論證研究方法的有效性和算法優(yōu)化的思路。

2 基于微服務的稅務管理系統(tǒng)的設計

2.1 采用DevOps開發(fā)模式

DevOps[8-9]可以使開發(fā)團隊和運營團隊之間高效協(xié)作。隨著協(xié)作關系的改善，整個組織的效率得到提高，同時可以降低由反復變化帶來的生產(chǎn)環(huán)境的風險。

應用程序發(fā)布是一項涉及多個團隊的高容量高風險活動。但是，在有DevOps 功能的組織中，應用發(fā)布的風險卻很低，原因如下：

（1）減少變更范圍，每次發(fā)布包含的變化更少，服務與服務之間藕合性低。

（2）加強發(fā)布協(xié)調(diào)，即開發(fā)、測試、運維通過云平臺可以一體化協(xié)調(diào)管理。

（3）自動化熱部署，實時掌控服務狀態(tài)。

與大規(guī)模，不經(jīng)常發(fā)布的傳統(tǒng)開發(fā)方法相比，敏捷方式大大提升了發(fā)布頻率。

使用DevOps 開發(fā)模型可以實現(xiàn)開發(fā)運維一體化體系：

（1）開發(fā)方面：需要前后端分離，前端專注頁面展顯，個性化界面快速開發(fā)，后端專注業(yè)務服務層開發(fā)。

（2）運維方面：高效自動化部署，靈活發(fā)布、局部更新，同時資源要能彈性伸縮。

（3）安全方面：內(nèi)外部服務分區(qū)管理，服務能自動恢復，實時掌控服務狀態(tài)，OpenShift 平臺具備服務自愈。

2.2 系統(tǒng)架構

系統(tǒng)設計理念是輕前端，強中臺，穩(wěn)后臺：

輕前端：以最終用戶為中心，個性化（可定義），角色化（門戶）、場景化（工作臺），前端化（PC+Mobile）。

強中臺：用Spring Cloud 微服務架構打造強

大的中臺服務，專注業(yè)務服務開發(fā)。

穩(wěn)后臺：以OpenShift 產(chǎn)品為平臺，容器技術、移動技術、互聯(lián)網(wǎng)中間件、DevOps、OpenAPI 為基礎。本文提出了基于微服務的稅務系統(tǒng)的總體架構，如圖1所示。

圖1 基于微服務架構的稅務系統(tǒng)總體架構圖

圖1 中，系統(tǒng)后臺架構采用Spring Cloud 微服務架構，PC 前端采用流行的VueJS+Element+KendoUi 技術，實現(xiàn)前后端完全分離，同時系統(tǒng)需要支持移動端和電腦PC 端同時使用，后臺統(tǒng)一開發(fā)服務，實現(xiàn)后端服務復用，減少開發(fā)工作量。

API 服務平臺：所有的前端服務請求必須經(jīng)過API服務平臺進行調(diào)用，平臺包括：API 網(wǎng)關，Euerka 注冊中心，Zipkin 鏈路監(jiān)控功能。

鑒權認證服務：所有的服務請求都必須經(jīng)過授權認證才能進行訪問，授權認證采用OAuth 2.0 技術，通過token 進行授權認證，同時采用Redis 進行分步式存儲管理。

業(yè)務服務劃分：后端服務根據(jù)業(yè)務的類型進行拆分，基礎數(shù)據(jù)、用戶權限、配置類信息為一類服務，企業(yè)所得稅、增值稅、房產(chǎn)稅、印花稅等稅種分別進行拆分，同時把銷項發(fā)票、進項發(fā)票、電子發(fā)票等所有發(fā)票相關的建立發(fā)票池服務。

基礎組件服務：某些共享服務是分開的并用做基本技術組件服務，例如：消息推送服務、資源存儲服務、分布式JOB 架構、郵件短信服務、緩存服務、API 認證授權服務等。

以上服務可以系統(tǒng)內(nèi)部調(diào)用，也可以授權給第三方系統(tǒng)調(diào)用，平臺可以通過API 過濾、白名單或公鑰授權的方式供第三方調(diào)用或進行集群。

平臺同時提供Job service 服務，API HUB，對外部一些旅游網(wǎng)站訂票開具發(fā)票情況進行數(shù)據(jù)抽取分析。

平臺具備系統(tǒng)監(jiān)控功能，如版本管理、服務監(jiān)控、運維監(jiān)控、BI 分析平臺、數(shù)據(jù)挖掘平臺。

3 關鍵技術與實現(xiàn)

3.1 微服務注冊網(wǎng)關及實現(xiàn)請求機制

Eureka 的客戶端是自行注冊的，客戶端負責處理服務實例的注冊和注銷。使用SpringBoot 集成微服務時，結合SpringCloud 項目可以很方便地實現(xiàn)自動注冊。將注釋@EnableEurekaClient 添加到服務器啟動類，以便在服務實例啟動時向配置的Eureka 服務器注冊服務[10]。客戶端的負載均衡由Netflix Ribbon 實現(xiàn)。服務網(wǎng)關使用Netflix Zuul，熔斷器使用Netflix Hystrix。服務注冊網(wǎng)關及實現(xiàn)請求邏輯圖如圖2 所示。

3.2 微服務治理及交互機制

移動和PC 端通過調(diào)用Rest 服務，請求后端服務，那么多服務是如何管理和智能路由選擇，則是通過服務網(wǎng)關控制。

服務網(wǎng)關是實現(xiàn)微服務可能必不可少的一個非常重要的組件。網(wǎng)關負責安全檢查、認證授權、路由分發(fā)、流量控制和熔斷保護。API 網(wǎng)關是整個微服務平臺的核心，API 請求響應必經(jīng)之路[11]。服務治理及交互機制如圖3 所示。

圖2 注冊網(wǎng)關及實現(xiàn)請求邏輯圖

圖3 服務治理及交互機制圖

3.3 分步式事務一致性處理機制

這么多的分步式微服務，并且是分庫存儲，就必須要有相關的機制來保持事務的一致性。目前我們通過MQ 消息對隊同步來保證事務一致性同步。

可靠消息最終一致性方案：這是一種目前比較常用的方案，其原理與上述方法類似，借助MQ，只是不再借助數(shù)據(jù)庫的消息表，而是由系統(tǒng)發(fā)起一條預發(fā)送消息，當系統(tǒng)本身的事務執(zhí)行完畢后再將MQ 中的消息變?yōu)榇_認消息，同樣其他系統(tǒng)接收到MQ 的消息后開始處理本地事務，根據(jù)處理情況決定事務是否需要回滾。相對來說優(yōu)點是事務控制較為靈活，確定是不穩(wěn)定因素較多。

3.4 建立大數(shù)據(jù)分析BI智能報表工具

建立大數(shù)據(jù)分析BI 報表工具，確保進入系統(tǒng)的數(shù)據(jù)能通過報表方式按需展現(xiàn)出來。實現(xiàn)邏輯：申報表數(shù)據(jù)，日常稅務數(shù)據(jù)，發(fā)票數(shù)據(jù)，財務數(shù)據(jù)，通過ETL 數(shù)據(jù)抽取進行過濾、清洗、轉化到數(shù)據(jù)倉庫，數(shù)據(jù)倉庫通過數(shù)據(jù)挖掘、多維數(shù)據(jù)集成形數(shù)據(jù)集市，再通過BI 可視化工具，工具支持數(shù)據(jù)可視化界面配置、智能鉆取手段、實現(xiàn)自助分析、形成分析報告。

3.5 系統(tǒng)實現(xiàn)

基于微服務的稅務系統(tǒng)部署于PaaS 平臺上，入口界面如圖4 所示。平臺提供日志查詢功能，方便問題的排查和上線檢查。同時平臺還提供服務器監(jiān)控、應用監(jiān)控、錯誤報警、Bug 管理、性能分析、用戶行為分析、安全漏洞分析、時間管理等服務，供開發(fā)人員方便地使用，使開發(fā)人員更專注于開發(fā)過程，提升了開發(fā)效率，縮短了應用上線周期。平臺的彈性伸縮性能很好地支持了業(yè)務并發(fā)。

圖4 系統(tǒng)入口界面圖

基于PaaS 平臺的稅務管理系統(tǒng)開發(fā)模式與傳統(tǒng)開發(fā)模式，從數(shù)據(jù)準備時間、應用部署時間、資源利用率及開發(fā)工具準備時間等方面均有大幅提升。如表2所示。

表1 開發(fā)模式對比

系統(tǒng)展示效果如圖5 所示。

圖5

4 結語

本文通過對稅務管理系統(tǒng)的應用背景、微服務架構和PaaS 平臺技術的研究，設計并實現(xiàn)了基于微服務架構的稅務管理系統(tǒng)，并將系統(tǒng)部署于PaaS 平臺。通過具體的實現(xiàn)，提升了系統(tǒng)的開發(fā)演化的穩(wěn)定性，縮短了應用發(fā)布更新時間，提高了稅務管理的工作效率。