基于微服務(wù)架構(gòu)的稅務(wù)管理系統(tǒng)在PaaS 平臺上的設(shè)計(jì)與實(shí)現(xiàn)

王夏洋

（中國海洋石油集團(tuán)有限公司，北京100010）

0 引言

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

（1）模塊之間耦合度高（前后端一體化），其中一個(gè)模塊升級需要其余全部升級，升級部署風(fēng)險(xiǎn)高。

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

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

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

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

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

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

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

1 相關(guān)工作

1.1 微服務(wù)架構(gòu)

（1）微服務(wù)架構(gòu)概念

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

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

（2）微服務(wù)架構(gòu)技術(shù)

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

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

（3）微服務(wù)部署

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

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

（4）服務(wù)容錯(cuò)

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

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

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

1.2 PaaS平臺

（1）PaaS 平臺特點(diǎn)

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

通過應(yīng)用程序和數(shù)據(jù)分離以及集群部署，系統(tǒng)可實(shí)現(xiàn)快速的在線擴(kuò)展、處理能力的線性擴(kuò)展和自動故障處理?？梢造`活地?cái)U(kuò)展相對獨(dú)立的應(yīng)用程序主機(jī)。其特點(diǎn)有：

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

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

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

②應(yīng)用集群化部署

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

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

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

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

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

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

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

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

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

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

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

（2）中海油PaaS 平臺

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

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

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

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

2 基于微服務(wù)的稅務(wù)管理系統(tǒng)的設(shè)計(jì)

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

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

應(yīng)用程序發(fā)布是一項(xiàng)涉及多個(gè)團(tuán)隊(duì)的高容量高風(fēng)險(xiǎn)活動。但是，在有DevOps 功能的組織中，應(yīng)用發(fā)布的風(fēng)險(xiǎn)卻很低，原因如下：

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

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

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

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

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

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

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

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

2.2 系統(tǒng)架構(gòu)

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

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

強(qiáng)中臺：用Spring Cloud 微服務(wù)架構(gòu)打造強(qiáng)

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

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

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

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

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

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

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

基礎(chǔ)組件服務(wù)：某些共享服務(wù)是分開的并用做基本技術(shù)組件服務(wù)，例如：消息推送服務(wù)、資源存儲服務(wù)、分布式JOB 架構(gòu)、郵件短信服務(wù)、緩存服務(wù)、API 認(rèn)證授權(quán)服務(wù)等。

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

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

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

3 關(guān)鍵技術(shù)與實(shí)現(xiàn)

3.1 微服務(wù)注冊網(wǎng)關(guān)及實(shí)現(xiàn)請求機(jī)制

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

3.2 微服務(wù)治理及交互機(jī)制

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

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

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

圖3 服務(wù)治理及交互機(jī)制圖

3.3 分步式事務(wù)一致性處理機(jī)制

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

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

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

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

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

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

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

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

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

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

圖5

4 結(jié)語

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