基于微服务的通信工程概预算系统的设计与研究

摘  要： 当前通信行业，已经有许多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.