


摘 ?要: 當前通信行業,已經有許多WEB工具平臺來進行預算。但是,它們預算方式不統一,無法統一管控。并且一旦工信部頒發相關定額或者計價方式的變更,各種系統需要重新改造,無疑加大了整體預算的成本。所以使用基于微服務架構的通信工程概預算系統不但可以統一各個省份及地市的預算,而且一旦發生變化可以快速迭代、快速集成,能夠第一時間使用戶使用上最新的系統。當前基于Spring Cloud的微服務架構已經在業內比較成熟,它為本系統的實現提供了很好的技術支持。另外,Kubernetes和Jenkins也大大的簡化了系統的運維成本,可以做到自動化的構建、測試及部署。
關鍵詞: 通信工程概預算;微服務;Spring Cloud;Kubernetes;Jenkins
中圖分類號: TP311 ? ?文獻標識碼: A ? ?DOI:10.3969/j.issn.1003-6970.2019.12.039
本文著錄格式:鄭明釗,張建強,張高毓. 基于微服務的通信工程概預算系統的設計與研究[J]. 軟件,2019,40(12):174177
Design and Research of Budget System for the Telecommunication
Engineering Based on Micro-Service
ZHENG Ming-zhao, ZHANG Jian-qiang, ZHANG Gao-yu
(China Mobile Group Design Institute Co., LTD Shandong, Jinan 250101, China)
【Abstract】: In the current communications industry, there are many Web tools platform for budgeting. However, their budget methods are not unified and cannot be controlled uniformly. In addition, once the MIIT releases relevant quota or change of valuation method, all kinds of systems need to be remolded, which undoubtedly increases the cost of the overall budget. Therefore, the budget system for the telecommunication engineering based on micro-service architecture can not only unify the budgets of various provinces and municipalities, but also unify the budgets of every provinces and citys once changes occur. And once changes occuring, it can be rapidly iterated and rapidly integrated. And the users can use the latest system in the first time. Currently, the micro-service architecture based on Spring Cloud has been relatively mature in the industry, which provides good technical support for the implementation of this system. In addition, Kubernetes and Jenkins also greatly simplified the operation and save costs of the system. And it enables the system can be built and deployed automatically.
【Key words】: Budget for the telecommunication engineering; Micro-service; Spring Cloud; Kubernetes; Jenkins
0 ?引言
隨著我國社會的經濟發展,為了滿足我國信息通信建設行業的發展要求,工信部頒布了最新的信息通信建設工程預算定額、工程費用定額及工程概預算編制規程,以規范通信建設工程的計價行為。
當前,通信業內存在著很多相關的通信工程概預算系統[1],每次工信部在頒布最新定額,都需要重新調整系統以適應最新的定額及計價方式。這無疑增加了系統維護人員的工作量,而且系統的重新改造開發都需要花費大量的人力物力資源。且在當前互聯網高速發展的時代,快速響應快速迭代的需求也越來越高。所以,以往按部就班系統整體改造、開發、測試及部署的方式嚴重影響了系統的迭代能力。除此之外,不同省份與地市對于概預算的需求也有些不一致,一套固定的系統很難滿足全國所有通信行業的需求。
綜上兩個問題,使用微服務[2]架構設計的通信工程概預算系統能夠對于突發的變化做出快速應對,通過修改個別服務做到快速迭代,且不需要整體部署,只需對發生改變的服務進行重新部署即可。另外,使用微服務架構[8]可以通過部署多種服務來滿足不同的業務需求。
1 ?需求分析
基于微服務的通信工程概預算系統主要功能需要完成對定額工日、使用材料、設備及機械等信息的計算得出最終的工程概預算計價結果。除了完成正常的概預算之外,由于系統使用微服務架構,則需要系統中有一個統一的服務注冊及發現中心,且概預算服務的部署都比較復雜,需要一個強大的自動化運維服務功能。基于以上,可以將系統的需求分為功能性需求和非功能性需求兩部分。
1.1 ?系統用例分析
本系統主要功能需求分為功能性需求及非功能性需求兩大部分。功能性需求主要有:概預算費用計算、標準信息維護、概預算文件導出等功能;非功能系需求主要針對服務注冊發現、系統運維方面,主要包括:服務注冊與發現、監控與告警、系統運行日志、自動化構建及部署等。系統用力分析圖如下圖1所示。
圖1 ?系統用例圖
Fig.1 ?System use case diagrams
1.2 ?核心功能需求
基于微服務的通信工程概預算系統其核心功能需要完成對項目工程的概預算計算以及完成對預算結果按照工信部標準出版格式生成Excel編制文件。主要包括:概預算費用計算、標準信息維護、概預算文件導出等功能。
概預算費用計算:根據錄入的基礎定額、材料、設備、儀表和機械等信息計算出表一至表五的費用數據。
標準信息維護:按照工信部下發標準定額信息,結合個人需求在系統內維護工日、材料、機械、儀表等標準基礎數據。
概預算文件導出:按照工信部標準出版格式,生成概預算表格文件。
1.3 ?非核心功能需求
基于微服務的通信工程概預算系統由于使用的微服務方式部署,所以服務的數量和種類都會比較多,在部署的時候若要使用人工部署的方式會非常的麻煩和復雜。
基于系統能夠自動化的快速部署的目的,其所需的非功能性需求有:服務注冊與發現、系統監控與告警、系統日志功能以及系統自動化構建及部署功能。
服務注冊與發現:注冊與發現概預算系統的計算服務、文件生成服務,以及信息維護等服務。
系統監控與告警:監控系統的資源使用、服務運行等情況,若發現異常會發出實時告警。
系統日志功能:記錄系統中硬件、軟件和系統問題的信息,記錄系統操作過程,同時還可以監視系統中發生的事件。
系統自動化構建及部署:研發人員通過上傳代碼庫最新源碼,該功能會自動對最新的源碼進行構建打包部署,使服務一直保持最新狀態。
2 ?系統架構設計
根據上述需求分析,可以總結得出系統整體架構設計如下圖所示。從下圖2可以看出本系統總共可以分為四大部分:接入網關、系統服務、注冊中心、系統運維模塊。
2.1 ?系統數據存儲
通信工程概預算系統對數據進行操作如下圖3所示都是相互獨立的,各個服務之間都是通過相互調用Restful[3]接口來達到數據交互。
通過上圖可以知道基于微服務的通信工程概預算系統總共分為五種數據:系統基本設置數據、基礎數據、文件數據、費用計算數據以及標準信息數據。下面將對這幾種數據進行分別的詳細闡述。
圖2 ?系統架構圖
Fig.2 ?System architecture diagram
圖3 ?通信工程概預算系統數據流圖
Fig.3 ?Data flow diagram of communication engineering budget system
系統基本設置數據:包括系統的計算精度、高原系統、運送距離以及分段等信息;
基礎數據:包括單項工程名稱、表格編號字頭、建設項目名稱、建設單位以及設計單位、定額及自定義公式等信息;
文件數據:概預算結果文件導出時,需要按照一定的標準格式生成,則文件數據即為這些標準格式文件;
費用計算數據:包括各個表格計算時涉及的相關費率,以及計價方式等一些數據;
標準信息數據:標準信息,即工信部頒布的工日、材料、機械、儀表等信息。
2.2 ?系統業務邏輯
基于微服務的通信工程概預算系統主要依托于Spring Cloud[4]的框架來實現,其中費用計算為業務邏輯為核心模塊,其業務實現的邏輯圖如下圖4所示。
3 ?關鍵問題及解決方案
現實系統開發過程中,由于有很多的系統服務,若要保證每個服務都有一個單獨的數據庫是非常不現實的,其中保證數據同步這一件事就會使得系統非常復雜。
圖4 ?費用計算業務邏輯圖
Fig.4 ?Cost calculation business logic diagram
針對此問題,提出兩種解決方案:第一,即每種服務使用一個數據庫,這樣的話相同服務之間會保證數據同步,且不同種類服務之間數據也是隔離的,不同服務之間相互調用通過restful方式來發送消息;第二,即沿用以前傳統的方式,整個系統使用單個數據庫[10-11],這樣保證了整個系統的數據同步,而且不會造成不同服務之間的數據差異。
基于本系統業務邏輯并非那么復雜,而且各個服務之間的調用數據傳輸量比較大,所以使用單個數據庫的方式,每個服務之間僅發送必要的請求即可,數據讀取通過數據庫即可。這樣既降低了系統
圖5 ?系統數據庫改造方案
Fig.5 ?System database reconstruction scheme
復雜度,也很好的遵循了微服務的架構設計模式。其改造方案圖如下圖5所示。
4 ?關鍵技術
Spring Cloud: Spring Cloud是很多程序框架的組合。它大體包括服務發現注冊、負載均衡、斷路器,使用Spring Boot開發屏蔽掉了很多繁瑣的配置,大大簡化了開發工作。另外使用整個技術路線,可以很方便的搭建起微服務的系統架構平臺。
Eureka:Eureka集成于Spring Cloud,它實現了服務發現功能。Eureka包含兩個部分:Eureka Server和Eureka Client。Eureka Server用來進行服務注冊,Eureka Client用于簡化與Eureka Server的交互,在本系統中負責概預算服務的注冊與發現。
Zuul:它是一個API Gateway服務器,在本系統中使用zuul來實現接入網關,對外部請求進行過濾等操作。
Restful API:RESTful[9]是一種標準的通信接口,在本系統中使用Restful API統一的接口來訪問數據庫從而獲取到相同的數據。
Docker容器:Docker[5,12]是一種應用容器,可封裝應用及運行環境,進而輕松的移植到其他系統上。
Jenkins:Jenkins[6]是一種自動化的持續集成工具,可自動化的重復構建發布軟件,使得繁瑣的程序構建打包過程變得自動化,從而減輕了人工操作的壓力。
Kubernetes(k8s):Kubernetes[7]提供自動化容器的部署和復制能力,根據系統實際應用情況擴展或收縮容器的數量和部署,且它還可以實現容器的負載均衡。
5 ?結束語
本文提出了使用微服務的架構思想來統一構建一套概預算系統的架構方案,該方案不但在理論上進行了介紹,而且還在具體的架構實現進行了分析,具有非常高的可行性。通過使用微服務的架構不但規避了各種預算的差異,而且提升了計算的速度。如果真的應用到實際的平臺環境中將會大大節約我們的開發成本,而且還會提高我們的工作效率。
參考文獻
[1]張延彬. 通信工程概預算編制系統的設計與實現[D]. 山東大學, 2010.
[2]郭棟, 王偉, 曾國蓀. 一種基于微服務架構的新型云件PaaS平臺[J]. 信息網絡安全, 2015(11): 15-20.
[3]潘冰. 面向資源的RESTful Web應用研究[J]. 微計算機應用, 2010, 31(07): 38-43.
[4]梁安健, 胡寧, 羅劍武, 陳泫文. 基于Spring Cloud的微服務構建及軟件云化應用研究[J]. 電子產品可靠性與環境試驗, 2018, 36(S1): 105-109.
[5]劉思堯, 李強, 李斌. 基于Docker技術的容器隔離性研究[J]. 軟件, 2015, 36(04): 110-113.
[6]陶鎮威. 基于Jenkins的持續集成研究與應用[D]. 華南理工大學, 2012.
[7]杜軍. 基于Kubernetes的云端資源調度器改進[D]. 浙江大學, 2016.
[8]郝振強. 終端管理系統北向對接中微服務的應用研究[J]. 軟件, 2018, 39(11): 101-104.
[9]黃沛. 基于RESTful架構的科技信息共享接口系統的設計[J]. 軟件, 2018, 39(7): 170-172.
[10]趙正旭, 白英杰, 吳曉進. 國產操作系統JSP服務器部署策略的設計與實現[J]. 軟件, 2018, 39(6): 196-200.
[11]韓凌波. 基于mvc 架構的普法考試系統設計與實現[J]. 軟件, 2015, 36(3): 132-134.
[12]劉思堯, 李強, 李斌. 基于Docker 技術的容器隔離性研究[J]. 軟件, 2015, 36(4): 110-113.