1. 引言
我国的模具公司，主要是在最近十几年里不断发展壮大起来的，但他们却天天都忙于接单、忙于制造、忙于完成、忙于建设，一味追求表面的规模和公司的形式，却忽略了现代公司的信息化管理水平 [1]。模具制造行业中一般都是以小型企业居多，它既是典型的精密铸造类行业，也是典型的面向订单式生产企业，具有大量单件无重复制造，对车间生产工艺路线的手工程度要求较高，以机器化生产占据了主导地位，按单制造的优点明显 [2]。现有的模具生产管理系统大多是以ERP (Enterprise Resource Planning，即企业资源计划)系统为辅，主要以表单为介质进行信息的传递，效率极其低下，对人员以及模具的调度较为混乱。
本文为了解决以上问题，开发出一套完全信息化的系统，选取前后端分离的风格作为本系统的开发模式，松解前后端耦合。后端选取Spring Cloud作为核心框架，以微服务的风格构建。微服务的架构风格就是将一个服务整体按照功能的不同分解成多个单独的模块；前端选取Vue.js作为核心框架，建立该系统的前端整体架构；前端通过ajax发送请求到后端，后端进行处理，然后将得到数据返回给前端，前端根据需求将需要展示的数据，采用相关组件来进行渲染，展现在页面上。将该系统部署到企业的服务器上，经过用户的使用反馈，系统能很好地解决企业在业务上的需求，大大提高了企业对模具的调度效率和对产品的产出效率。
2. 微服务架构
随着互联网技术的不断迭代发展，软件开发技术已由第一代的单体架构发展到面向服务的体系结构(SOA) [3]，再到现在的微服务架构。单体架构是指整个系统需要创建一个独立单元作为所有功能模块的基础。所有数据库的操作、后台的业务逻辑以及对后台代码的处理都集中在该独立单元中，后续对后端业务进行扩展与优化也都在该独立单元中进行。随着业务量的不断增加，系统会变得十分臃肿，代码也会十分冗余。以至于处理起来十分困难，让开发人员无从下手。如果其中某个模块存在问题，那么整个系统将崩溃，导致用户无法使用。
SOA是面向服务的一种体系结构。SOA架构将系统里的每一个功能模块划分开来，并通过这些模块之间定义清晰的接口和约束将它们连接起来。SOA结构根据服务功能的不同将最初的一个结构分解为不同的子结构，SOA结构如图1所示。
由上图可知，将一个完整的项目划分为多个模块，并且数据库进行主库与从库设计与数据同步，以解决单体式架构所遗留下的问题。
SOA架构一般会建立一个模块来主导其他模块的集中式管理模式，并且被管理的模块使用的语言与技术集可以是一致的，也可以是不一致的，十分灵活。但是SOA也存在一个弊端，就是对系统和服务的定义不清晰，除此之外，SOA对接口的协议也没有一个统一的规定，开发人员维护起来十分繁琐。
基于SOA架构出现的弊端，从而衍生出了一种变体——微服务体系架构。微服务架构，提倡将整个服务模块按照各自功能的不同分解为一组组小型服务，这些被分解后的小型服务通过Http通信机制，相互协调合作，互不干扰。每项服务都基于特定的业务，可以在生产环境、类生产环境等中独立运行。微服务架构示意图如图2所示。
Figure 2. Schematic diagram of microservice architecture
图2. 微服务架构示意图
3. 系统相关技术选型
本系统采用前后端分离的开发模式，前后端各负其责，提高开发效率。后端采用的是Spring Boot框架，结合Spring Cloud构建微服务，数据库采用MySQL 8.0.18实现，数据缓存采用Redis实现，消息队列采用RabbitMQ实现，前端架构采用Vue.js开发框架 [4]。
Spring是一个开源且轻量的框架，任何的基于Java的程序都可以从该框架中获得好处，降低代码耦合度与复杂性。但随着程序功能越来越丰富，越来越复杂，Spring也逐渐力不从心，满足不了日益增多的需求。所以Spring Boot在这种场景下横空出世。Spring Boot是基于Spring4.0设计的，既有Spring框架的出色能力，而且在此之上还简化了Spring的配置，更进一步降低了应用程序的构建以及开发过程 [5]。
Spring Cloud并不是一个独立的框架，它是一系列框架的集合。Spring Cloud必须依赖于Spring Boot，它利用Spring Boot操作简便的风格高明地使分布式系统基础设施的开发变得更加容易，像服务注册与发现、路由中心、配置中心、消息总线、负载均衡等，都可以做到一键启动和部署 [6]。Spring Cloud通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包 [7]。
Redis (Remote Dictionary Server)，即远程字典服务，是一个开源的使用C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API [8]。它支持存储的value类型有很多，包括string (字符串)、list (链表)、set (集合)、zset (sorted set--有序集合)和hash (哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。为了保证效率，数据都是缓存在内存中。区别的是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave (主从)同步。开发者可将短期内不会发生变化的数据存入Redis中，从而减轻数据库的压力，提高系统响应速度，增强用户体验。
RabbitMQ是实现了高级消息队列协议(AMQP)的开源消息代理软件(亦称面向消息的中间件)。RabbitMQ服务器是用Erlang语言编写的，而集群和故障转移是构建在开放电信平台框架上的 [9]。所有主要的编程语言均有与代理接口通讯的客户端库。开发者可以使用RabbitMQ来进行服务间的通信，松解服务与服务之间的耦合度。与此同时，RabbitMQ还可以对服务进行流量削峰，缓解服务器压力。
4. 系统设计与实现
4.1. 系统总体架构设计
本系统总体架构图如图3所示。
各个模块详细职能如下：
1) 系统前端
本系统前端主要使用Vue.js框架、Element UI和Echarts实现，以图表的形式完整清晰地展示相关数据。
2) 数据库、Redis缓存
本系统数据库采用MySQL 8.0.18，将本系统的所有数据都放在其中。MySQL是最流行的数据库之一，是一个免费开源的关系型数据库管理系统。MySQL不仅可以在Windows系列的操作系统上运行，还可以在UNIX、Linux和Mac OS等操作系统上运行。所以MySQL的跨平台性保证了其在Web应用方面的优势 [10]。本系统将用户、部门、商品生产订单、生产订单、派工表、模具申请记录、出入库记录等所有模具生产数据信息都存储在数据库中。由于在模具生产的过程中所产生的数据信息都会存在数据库中，经过长时间的积累，数据量已十分庞大，从而会导致数据库检索的速度慢等问题。为了解决该问题，在系统设计初期，将访问频率高、体量庞大的数据以缓存的形式存入Redis中，并设置相关限定条件，如数据过期时间等，从而实时可控地更新数据，增强数据读写性，提升系统响应速度。
Figure 3. System overall architecture diagram
图3. 系统总体架构图
3) 服务端
微服务框架无论是对于技术开发，还是对于企业业务需求，都能够贴切地满足，不仅在开发阶段易于上手，而且在维护升级阶段也具有易维护与可拓展的特性。针对企业采购成本节约问题与库存压力，利用 JIT 采购模式调整采购与库存关系，再进行采购、生产、库存成本建模，整体求得最优并给出采购建议与计划调度，有利于企业资源调度与辅助决策。根据模具生产流程划分出四个微服务，分别是采购中心管理服务、仓储中心管理服务、生产中心管理服务、客户中心管理服务，各个模块对应模具生产管理的各个流程。
4.2. 系统数据库设计
本系统数据库采用MySQL 8.0.18，在此仅对部分库表的结构设计进行说明。数据库部分表设计如图4和图5所示，其中产品生产订单表(pdm_production_order)存放企业的所有的生产订单信息，产品销售订单(pdm_sale_order)存放企业的所有销售订单，产品分类表(pdm_product_category)存放企业生产所有的产品分类信息，计划生产表单(pdm_plan_schedule)存放生产中心的计划生产信息，计划生产派工表(psm_assign_process)存放生产中心的派工信息，派工后报工表(psm_report_process)存放生产中心进行派工后的报工信息，工序工价表(fdm_process_price)存放生产中心的工价工序信息，产品打样表(pdm_product_proof)存放对即将要生产的产品进行打样的信息，首件确认报告基本信息(qc_report)存放的是对首件产品进行确认后的信息，首件报告检查项(qc_reportdtl)存放的是对首件确认报告的补充信息，巡检记录表详情(qc_inspection_orderdtl)存放的是对生产的产品进行巡检时记录详情。pdm_production_order表和pdm_sale_order表是一对多的关系，每一张产品生产订单包含多张销售订单，两表通过外键work_order_id关联。pdm_product_proof表和qc_report表是一对多的关系，每张产品打样表对应多条首件确认报告信息，两表通过外键proof_id关联。
Figure 4. Part of the database table and the corresponding diagram
图4. 数据库部分表及对应关系图
Figure 5. Part of the database table and the corresponding diagram
图5. 数据库部分表及对应关系图
4.3. 系统服务端设计与实现
4.3.1
. 微服务框架设计
本系统微服务框架采用Spring Cloud的微服务架构进行搭建。Spring Cloud全家桶包括服务注册与发现——Netflix Eureka、负载均衡：客户端负载均衡——Netflix Ribbon，服务端负载均衡——Feign (其也是依赖于Ribbon，只是将调用方式RestTemplete 更改成Service接口)、断路器——Netflix Hystrix、服务网关——Netflix Zuul、分布式配置——Spring Cloud Config [11]。
数据缓存采用Redis，它是一个开源的高性能的key-value非关系型数据库。Redis通过RDB和AOF两种方式来实现数据持久化，可以将内存中的数据存入磁盘，再次加载时可以使用；Redis不仅有key-value类型，还有string、set、zset、list等数据类型；Redis读数据的速度可达到110,000次/秒，写数据的速度可达到81,000次/秒。在本系统中，运用Redis实现业务数据的缓存，将体量庞大且短时间内不会发生变化的数据存入其中，减小了数据库压力，提升了系统响应速度，增强了用户体验。
4.3.2. 微服务功能设计
根据模具生产管理整体流程，本系统划分出四个微服务，分别是仓储中心管理微服务、采购中心管理微服务、生产中心微服务、客户关系中心管理微服务，以下为各个微服务具体的功能描述。
1) 仓储中心
仓储中心主要包括模具仓储、原料仓储、成品仓储三部分。
模具仓储负责模具类别与模具基本信息的维护；对生产任务中，上下模具申请进行审批并伴随模具相关文件的发放、回收；记录模具出入库；审批过后需要追踪模具与生产活动。物料仓储负责物料类别与物料基本信息的维护；对物料出入库进行记录；对物料设置安全库存。成品仓储主要负责成品的信息维护以及成品出入库记录。
2) 采购中心
采购中心主要负责供应商基本信息的管理，包括供应商基本信息、供应商合同、供应商发票信息维护；采购过程发生的物料采购订单信息维护。
3) 生产中心
工厂管理：工厂的基本产能信息维护如员工、车间、班组、机器、工序工价等。计划管理：依据销售订单制定产品生产订单与物料需求单，此时需要判断库存水位，以此判断是否需要进行物料采购计划；依据生产订单制定主生产计划；主生产计划审核后进行车间派工、任务下达。生产调度：车间领班接收到派工单后，依据派工单进行生产，生产后需要 QC质检员进行物料标识，检验是否合格。由于厨电产品生产需要模具与机器的配合，在此之前需要进行上模申请，一批半成品生产结束后需要下模并归还模具；该批订单完工后可报工核算工资。需要注意的是，某些新产品需要打样，经 QC 质检员首件确认后方可开机生产。
4) 客户关系中心
一方面负责客户管理即客户信息维护；另一方面客户的销售订单、销售合同、销售发票的管理；此外还需要维护产品的基本信息、相关经营信息等。
4.4. 系统前端设计与实现
PC端和移动端共设计了五个模块，分别是仓储中心管理、采购中心管理、生产中心管理、客户关系中心管理。
5. 结论
本系统对模具的生产管理系统进行了在数据结构和功能上的设计实现，在设计过程中充分考虑了系统的实际应用情况，从系统数据架构方面和系统的功能两个方面对系统进行了详细的设计实现，与试点单位现有的模具管理ERP系统相比，在一定程度上实现了企业完全信息化，脱离了纸质文件传递信息的弊端。通过系统的相应功能，有助于模具的设计与产品生产的全面集成，并提高了客户的满意度。