基于微服务架构的生产线管控系统开发与应用

马典锋，黄海，姜腾

（1.北京能科瑞元数字技术有限公司，北京100193；2.北京能科云翼数据技术开发有限公司，北京100193）

0 引言

2020年5 月，综合传动装置箱体加工生产线项目启动，项目着力解决生产线工艺设计和仿真数字化、生产任务排程科学化、加工过程调整动态化、高精度测量在位化和误差补偿自动化等问题，通过建设一套智能化生产管控系统，支撑大型箱体机加生产排产精确化、生产调度智能化、生产管理透明化、资源利用合理化等，包括计划管理、生产排产、生产执行、质量管理、物流管理、仓储管理、基础数据管理等模块。在各阶段采用不同的方法构建，设计阶段构以领域驱动设计（Domain-Driven Design，DDD）及面向对象方法划分定义微服务，开发阶段采用Spring Boot框架编码实现微服务，实施阶段采用DevOps运营平台统一管控微服务，运维阶段通过快速更新与快速部署体现微服务架构的便捷，项目历时15个月完成，目前项目已进入试运行阶段。

图1总体架构

1 软件架构设计

1.1 软件功能架构

针对智能制造模式下综合传动装置箱体加工生产线运行过程中加工质量、加工周期和加工成本的控制要求，能科科技股份有限公司承担了箱体智能加工生产线系统集成应用验证，负责箱体智能加工生产线管控系统的开发。整个专题由江麓集团、清华大学、能科股份三方承担，具有明确分工协作，建设周期15个月，以Java技术路线为主，基于Spirng Cloud+Spring Boot+MyBatis开源框架进行开发，采用前后端分离的开发模式，整体架构采用微服务架构开发，数据库中间件采用ORM技术，同时引入了消息中间件、任务调度插件及ETL工具，项目开发总人数10人，采用Windows平台进行本地化部署。项目功能模块分为计划管理、生产排产、生产执行、质量管理、物流管理、仓储管理、基础数据管理等模块，是一套完整的机器加工行业自上而下的顶级车间智能管控平台。通过该项目的持续建设，围绕人、机、料、法、环的要求实现了整个从车间到产线的生产管控自动化、生产现场透明化，提升了计划编制的准确性及物料送达的准确性，彻底打通了信息流与物料同步的问题，为企业车间无人化生产奠定了基础。

1.2 软件技术架构

图2微服务架构

架构基于微服务架构进行开发，能够通过平台本身提供的快速代码构建工具实现功能的快速搭建，同时在微服务架构的基础上实现了自主化服务封装，为企业信息化进程提供有力的技术支持，提升企业平台化进程，每个微服务之间独立自动部署，微服务之间通过网关进行通信，使分布式部署更为成熟高效，大幅度降低大型系统耦合的同时，也使得系统整体更为稳定、安全、高效。

基于Spring Boot标准的Spring Cloud架构实现微服务编排和应用的分布式框架，同时平台具备分布式部署与负载均衡能力，每个业务模块（微服务）在硬件条件允许的情况下均多套部署，以此解决高并而引起发硬件瓶颈问题，通过注册中心、网关实现熔断机制，解决系统单点故障问题，提供完善的热备能力。

（1）基础平台能力先行，共性技术服务能力下沉，通过开发原子微服务构建微服务池，提升系统复用性，降低开发难度。

（2）提升系统容错，采用熔断降级技术，单个服务发生错误系统能够自动降级处理，增加系统可靠性。

（3）鉴权与认证分开，系统采用先认证再鉴权的权限管理模式，权限粒度更细，更易扩展，扩展企业“三员分立”的业务要求。

（4）内置六大管理中心，提升平台管控能力，提升开发效率，降低开发成本。

①配置中心，统一管控系统所有配置文件、配置参数；②注册中心，微服务统一注册、统一管理；③用户中心，用于对外统一提供用户数据支持；④认证中心，提供授权、鉴权的统一管理模式；⑤数据中心，提供强大的数据集成能力；⑥日志中心，对系统各种操作、运行记录进行跟踪记录。

（5）双中台服务理念，业务中台给前端提供业务支撑，数据中台实现企业级数据集成能力，消除信息孤岛。

（6）自带负载均衡能力，整个系统通过微服务开发，构建微服务池，通过系统提供的注册中心，实现单个微服务的注册同时提供系统负载均衡能力。

（7）天生负载均衡能力，通过Ribbon实现系统默认的高可用，客户端负载均衡能力。生产线核心数据层和业务层采用双机，一旦确认某台服务器已发生故障，双机软件控制另一台服务器及时地接管故障设备上的运行任务。

经过前期技术可行性分析及对比微服务架构和单体架构的优势，最终采用微服务架构进行开发，本文着重从“设计、开发、实施、运维”4个方面论述基于微服务架构系统的开发和应用。

2 软件项目阶段

2.1 设计阶段

单体应用的设计主要按照模块化方式进行软件的设计，包括概要设计和详细设计，概要设计依据需求分析的结果界定外围系统的接口，接口的契约，与外围系统之间的数据交互以系统及各模块之间的关系及数据走向等；详细设计主要是设计数据库表，各接口参数、调用方式及各模块内部逻辑，界面按钮后端的业务逻辑等。

图3 DDD领域模型

微服务的设计与之不同，首先要对已有的需求报告通过领域驱动设计（DDD）业务模型进行重新的划分形成一个个独立业务域，让软件专家和业务领域专家达成一致，结合面向对象构建业务模型，充分把已有功能与业务域对应起来，进而最终形成一个个独立业务单元的微服务，形成微服务详细设计文档。

2.2 开发阶段

业务微服务定义完成后，开发采用前后端分离的模式进行开发，后端开发工程师进行微服务的开发，同时详细设计文档中的要求进行物理模型的构建及各类辅助软件的安装，系统软件物理模块的构建、开发环境的构建、数据库的构建等，前端工程师按照原型进行前端界面的开发，包括布局及界面风格严格按照原型进行，原型按钮操作依据详细设计后台逻辑进行业务逻辑的编写；测试工程师依据需求及设计进行测试用例的编写。

测试环境的搭建，在开发过程中开一个模块测试进行一个模块的测试，多个模块进行集成测试，集成测试通过后邀请客户进行系统测试，让用户及早参与测试，通过多次的版本迭代与开发完成测试工作。

图4前后端分离开发

图5迭代发布

2.3 实施阶段

微服务的难点首先在于微服务的定义与划分，这块在设计阶段通过DDD领域驱动模型方式得以解决，另外一个难点就是由于采用微服务架构，那么定义出的微服务数量比单体应用的模块多了很多，微服务的管理及发布等是一件很麻烦的事情，这个问题我们通过公司的DevOps平台来进行管控，服务的发现与注册通过注册中心来管理，微服务的运行环境通过Docker容器来实现，解决了开发环境、测试环境、生产环境不一致的问题，最后用K8S来管理Docker，服务的发布通过CI/CD统一进行集成、发布，基于DevOps运营平台完美解决了微服务管理难的问题，极大提高了软件的发布与自动编译的能力。

图6 DevOps平台

2.4 运维阶段

一般运维阶段的问题主要有以下两类，最终用户和IT部门：

（1）最终用户遇到的问题包括：

①业务划分不准确、理解不正确，不是我想要的功能。②这个功能点沟通了很多次，怎么还是不明白？③你们对于我们的业务不熟悉，理解不到怎么可以开发成功？④这个功能昨天就开完完成，怎么还没有发布，我只是提了一个小功能，怎么发布需要这么久？⑤只是一个界面的内容，怎么会影响整个系统，而且时间这么久？⑥又要我们测试，这个功能模块之前测试过了啊？⑦我提出的修改不是这个模块的，怎么也要测试这个模块？

（2）IT部门遇到的问题包括：

①我们信息部门能不能自己改界面？最好少开发就能实现相关功能。②所有功能都要以这个为中心，产生瓶颈怎么解决？牵扯我们太多精力，日常工作都不能正常开展。③怎么要这么多服务器，每个服务器配置怎么这么高？④你们人员怎么又变化？好容易建立的沟通信任又要从头开始。

（3）解决途径。通过采用微服务开发的系统，针对上面的问题得到了很好的解决，由于采用领域来划定微服务，降低了对于业务难度，业务理解更加充分，采用微服务架构能够支持分布式部署，资源在线横向扩展，单个服务资源动态扩展，降低停机停系统带来的影响，去中心化的设计思想能够使系统各部分受力均衡，避免瓶颈的产生，系统更容易维护、升级，降低运维成本。同时通过系统诊断、链路追踪技术及时反映系统及服务器真实状态，为企业信息部门提供预知、预判能力，提高生产力，增强持续集成、持续交付能力，简化开发难度，提高开发效率，降低成本。

3 结语

综上所述，通过应用微服务架构，完成箱体智能加工生产管控系统开发，使软件具备良好的可扩展性，适应用户的集成需求和推广应用，降低了项目成本。智能加工生产管控系统的设计在落实“实用”和“实效”的同时，助力六二七厂在机加行业成为兵器智能制造的标杆企业，未来将在全厂推广微服务开发与应用成果。