基于微服务的纺织信息化平台改造与实现

龚 琦，江 豪，冯立增，王 锦，王永华

(郑州轻工业大学电气信息工程学院，河南 郑州 450002)

0 引言

新时期，传统制造业需要快速应对外部环境的变化，调整经营策略，促进生产。这些都需要对原有的信息化平台进行更新。纺织企业对信息化平台的可扩展性要求也越来越高。纺织业两化融合在未来将会不断加深，物联网技术也开始在物联网上大规模应用。这对服务端提出了更高的要求：服务端需要提供高并发、高负载、高可用的服务[1]，并且可以快速迭代。传统的单块应用基于现有的服务需求，架设较为稳固的纺织信息化平台。这种稳固的架构设计与技术、需求快速迭代之间的矛盾，已逐渐成为制约纺织企业发展的重要因素，所以需要用一套更加灵活的技术架构来解决现有系统的不足。

1 微服务介绍

微服务概念出现于2012年，由于其加快Web和移动应用程序开发进程的的特性，自2014年开始受到各方的关注。微服务是把一个大型的单块应用程序和服务拆分为数个甚至数十个的较为独立的微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足企业产品快速迭代需求[2]。微服务在应用的过程中已经形成了一整套技术标准。

①单一职责：每个服务都专注于一件事，通过服务相互调用完成应用构建。

②微：每个服务都具有较为完整的结构，如拥有数据层、服务层和控制层。

③面向服务：每一个服务都具有对外HTTP接口，可以在没有任何配置、不会破坏原程序的情况下调用这些服务。

④自治：服务与服务是隔离的，可以自由选择技术栈。

⑤易扩展：由于服务之间的松耦合，可以很容易地扩展应用，而不用担心影响原来服务的使用。

⑥流程化：业务的难度可以分解到多个服务中，通过分步来稀释复杂度，降低每个服务的业务难度，使应用开发更加方便、更易理解、更好维护。

微服务可以实现系统敏捷开发、部署；可以更好地进行系统分布式处理，对服务器要求更低，高并发、响应速度更快；没有整体式系统对技术栈限制，可以用更恰当的技术实现服务。微服务架构非常适用于云计算平台，可以根据企业需求快速部署到云平台提供服务，具有更强的灵活性[3]。总结来说，微服务应用具有组件化、快速、可复用、机动灵活的优点。这些特点在系统规模快速膨胀、业务系统快速迭代的当下无疑是可贵的。所以，纺织MES的微服务化改造是一种必然选择。

2 关键技术介绍

2.1 服务间通信技术

所有的微服务都是独立的Java进程运行在独立的Docker容器中。这种沙盒机制一方面保证了服务的安全性与可重用性，另一方面也加大了服务间通信(inter process communication,IPC)难度。服务间通信已经有很多成熟的解决方案，按照阻塞情况可以分成以下两大类。

2.1.1 同步调用

同步调用是目前服务间通信常见的选择，采用访问/应答模式，消息的延迟更小。在同步调用中，又分成了两大技术流派。

①REST HTTP，作为SpringBoot平台推荐的服务间调用方式，通过Json文件实现消息传递。其实现简单，无平台依耐性，可以跨语言调用，能跨防火墙，适用性好。

②远程过程调用(remote procedure call,RPC)协议需要在服务调用者和接收者之间统一编码与解码过程，定制性好、通信效率高，通常用来实现企业内部服务间通信。Dobbo是当前微服务中的常用RPC通信协议。

2.1.2 异步消息调用

异步消息调用实现更为复杂，需要引入专门的消息中转，缓存发送者发送的数据，并由接收者到缓存区提取数据。企业常用的消息中间件包括Kafka、RabbitMQ和ActiveMQ。相比较同步调用方式，异步调用引入了中间层，使实时性更差，从而可以缓冲尖峰数据流、提高数据处理效率。

每种通信方式都有其自身的优势和不足。在企业微服务架构中，通常按照应用场合灵活选择：在数据量较大时，选择异步消息调用来缓冲数据；在企业内部的通信采用速度更高的RPC通信；在出现跨防火墙或跨平台的应用场景时，选择耦合更小的REST HTTP通信[4]。

2.2 服务网关

传统纺织信息化系统开发过程中，所有的服务都构建在Tomcat服务器中。客户端可以直接访问服务器的IP与接口。采用微服务架构后，纺织信息化系统由许多独立的服务构成。每个服务都运行在独立的虚拟机中，拥有独立的IP地址。客户端如何访问这些服务已成为一个较为严重的问题，因为客户端不可能记住所有服务的地址。而且在微服务应用中，服务上下线是较为正常的现象，前台不可能一直维护这些后台服务的地址。本文采用Zuul集群提供网关服务，主要有以下几个功能。①为所有后台服务提供统一的服务入口，不管后台服务的地址如何改变，这个入口的地址不变。②为用户提供更好的服务体验，客户端与后台服务通信需要经过各种路由跳转，通信难度与时间延迟要远远超过后台服务间的调用，通过网关可以降低客户端与后台通信次数，节流提效。③保护后台系统不受非法访问，通过网关可以方便实现权限鉴定，过滤不合法的访问。

网关也可能给系统带来单点故障。一旦网关停止服务，整个系统就不能提供服务。本文采用Zuul技术框架。Zuul是专为解决单点故障而设计的服务网关，可以通过集群的方式提供服务。

2.3 服务注册与发现技术

拆分后的服务运行时需要其他服务提供支持。但在微服务架构中，一般每一个服务都是基于容器部署的，会有多个拷贝来实现负载均衡。一个服务随时可能下线，也可能应对临时访问压力而增加新的服务节点。服务消费者需要调用服务提供者的某个方法，需要有一个地方找到服务提供者的位置信息；服务提供者也需要暴露相关方法供消费者调用。这就涉及到服务发现的实现。常用的方法是通过zookeeper等技术做服务注册信息的分布式管理[5-6]。当服务上线时，服务提供者将自己的服务信息注册到zookeeper集群，并通过心跳机制维持长链接，实时更新链接信息。服务消费者通过zookeeper，根据可定制算法找到服务后，还可以将服务信息缓存在本地以提高性能。当服务下线时，zookeeper会发通知给服务客户端。

zookeeper集群作为服务注册中心的最大问题是：当Master节点出现网络故障而变得不可用之后，其他节点需要进行leader选举。这个过程为30～120 s，期间zookeeper集群不再对外提供注册服务。而Eureka集群各个节点都是平等的，只要有一个节点可用就可对外提供服务。Eureka集群提供了一种高可用与数据最终一致性的服务，允许各节点数据存在不一致以保证系统高可用。服务注册与发现可以容忍获得地址一定错误，可以通过报告失效节点、重新获取新的服务地址来保证整体服务稳定运行。

2.4 服务的容错机制

整体式开发存在一个很大的风险：应用部署在一个服务器上，一荣俱荣，一损俱损。而微服务的相互间调用在系统内部组成了一个较为复杂的链路网络。一个环节出现问题，会通过传导影响其他系统使用。所以需要一定的容错机制来保障系统整体可用。相应的方法如下所示。①重试机制，访问失败后重试服务。②限流，超过设定访问数后拒绝新的服务申请。③熔断机制，服务多次访问故障后对其进行熔断保护。④负载均衡，使服务访问按照设定权重分配。⑤服务降级，服务器访问过大时关闭一部分非主要业务来保证主业务顺利进行。

重试机制能解决一部分问题。但值得注意的是，重试机制作用域是有限制的。它只能作用于幂等性问题(不管发起多少次请求，结果都一致的请求)，如数据读取、修改、删除操作。这一限制是为了防止误操作。比如对一个数据添加操作，如果使用重试机制，可能导致数据重复添加。通常，为了保障系统的健壮性，所有的服务容错手段都是一起使用的，可保证单个服务出现问题时不会影响其他服务。

3 设计与实现

3.1 业务需求分析

改进现有纺织信息化平台服务端的系统架构，使现有系统具有更加灵活的扩展能力与更好的数据承载能力。纺纱车间包括清花、梳棉、并条、精梳、粗纱、细纱、络筒、倍捻、整经、浆纱、织布、整理等工序，工序复杂，员工流动大，管理较为复杂，责任认定困难。所以需要对纺纱信息化平台系统原材料、产品、设备与员工之间的关系进行映射，明确不合格品的产生原因，快速定位问题和解决问题，以方便企业管理。

3.2 系统业务拆分

系统拆分是微服务架构设计中的重要一步，直接关系到系统的性能与开发难度[7]。拆分的粒度过粗，达不到系统想要的耦合度；拆分的粒度过细，系统开发、运维难度过大。微服务架构的系统主要按照功能进行拆分。

相比传统的模型-视图-控制(model view controller,MVC)架构横向拆分，微服务是将工程纵向拆分，每个服务都是可独立运行的。在纺织制造执行系统(manufacturing execution system,MES)中，拆分过程中需要遵循一些原则。较为重要、关键的业务是拆分的重点。如领导较为关注的质量管理业务是需要拆分出来的。另外，需要注意服务调用链路长度。过长的链路调用会导致系统出现“雪崩”现象，破坏系统稳定性。纺织MES业务拆分如图1所示。

图1 纺织MES业务拆分图

在纺织信息化平台架构设计中:业务系统主要可以分为面向用户访问的产品服务、给产品服务提供服务的基础服务；信息化系统可以按照工序对系统进行拆分。此外，也可以按照功能进行拆分。但拆分不是越细越好，如权限管理模块在业务发展中是不会经常变化的，而且本身独立性较强，如果没有必要，可以整体作为一个服务来构建。这也对系统起到了较好的保护作用。所以拆分是一个适度选择的问题，粒度过细或过粗都不好。

3.3 架构实现

基于微服务的纺织MES架构如图2所示。为了实现图2微服务架构设计，选择SpringBoot+SpringCloud作为纺织信息化平台核心框架。SpringBoot是基于Java开发的简化配置工具，可以简化部分配置，与微服务架构的大量服务开发相贴合，是实现快速开发的首选技术。SpringCloud是微服务技术工具整合在Spring平台的一个微服务开发工具集，包括服务发现、服务治理、服务配置、链路追踪等工具[8]。有了SpringCloud，就可以使用其中的工具管理微服务，不用再自行设计相关服务，简化了微服务的开发流程。

图2 基于微服务的纺织MES架构图

在SpringCloud中，选择NetflexZuul作为API Gateway，实现访问接口统一化管理和负载均衡；选择Netflex Eureka作为服务注册与发现中心，通过服务的注册实现生产者与消费者服务间调用注册；选择Netflex Ribbon作为服务提供者端的负载均衡器；选择SpringCloud Config作为服务配置中心配置服务。

纺织MES是一个有较大数据写入的系统。为了保障写入系统的稳定，采用RabbitMQ缓存写入数据，消除写入的数据流抖动；采用虚拟化容器Docker技术来实现资源的虚拟化，保障开发、测试、运维环境的一致性。为了达到对Docker容器的部署与管理，采用Kubernetes对Docker容器进行部署与管理，实现多台廉价服务器的集群管理[9]。

3.4 使用效果

为了验证微服务架构纺织MES相比传统MES的优势，按照上述步骤构建微服务纺织信息化系统，并且对其进行仿真测试试验。本次试验数据由一个采集数据模拟程序模拟车间采集数据发送给纺织MES，然后利用爬虫程序模拟浏览器端访问服务端，比较微服务架构与单块架构MES的数据访问。仿真试验结果如表1所列。

表1 仿真试验结果

从表1中可以得出以下结论。①微服务架构解决了模块复用困难的问题，加快了项目开发。单块架构由于系统间耦合，模块复用性不强。而微服务架构由于微服务容器化部署，可以一次构建，多处使用，加速开发。②微服务架构有更好的容错能力，用微服务架构构建的纺织MES，可以自适应熔断不可用的服务，使系统更加安全。③微服务为纺织MES带来了更高的并发处理能力。作为分布式的架构，微服务构建的MES可以并发处理请求，适用于大规模数据实时分析，使系统的时间延迟更小。

4 结束语

本文实现了基于纺织信息化平台的微服务架构设计。在项目更新频率越来越快、项目越来越复杂的纺织信息化平台开发中，微服务架构具有更强的扩展能力与容错能力，能使纺织信息化平台更加灵活、健壮，满足纺织企业快速构建信息化平台与快速迭代的需求，也为纺织MES带来了更强的并发处理能力与更低的时延。本研究对纺织系统的设计、开发具有一定的借鉴价值。