如何在技术上实现MES微服务架构

MES系统微服务是目前比较流行的架构方案，很多大型MES厂商都为工厂提供分布式服务的软件系统。

传统的服务应用的开发方式是将整个服务应用的数据库、接口、页面等进行分层设计、统一开发，然后逐层实现。在这些模块或接口中，只要有一个没有完成开发，那么整个应用系统将无法正常运行。SOA提出在对软件进行架构设计时，把整个应用服务根据业务细化成多个独立的小的服务，即低耦合及面向服务流程的思想。但是在SOA的架构中，企业服务总线（EBS）仍处于非常重要的位置，致使整个系统的SOA架构仍很难实现完全的面向服务以及完全的组件化，SOA的应用存在一定的局限性。

微服务架构（micro service architecture，MSA）是在2012年被提出的，其思想本质上和SOA一脉相承，是SOA的变体，它把SOA的理念进行了进一步的升华。MSA的核心思想是在系统设计开发阶段，将单个应用划分为一系列微小服务来实现系统的所有功能。MSA是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常有自己的堆栈，包括数据库和数据模型；通过REST API，事件流和消息代理的组合相互通信；它们是按业务能力组织的，分隔服务的线通常称为边界上下文。相比于SOA，MSA有如下特点：

（1）MSA强调去ESB、去中心化、分布式，所以MSA能带来更大的灵活性，为开发系统提供更加轻量级、效率更高的设计模式。而SOA还是以ESB服务总线为核心，MSA则使用轻量级协议，如HTTP、REST等。数据存储层面，SOA是共享数据存储，MSA则是每个微服务有独立的数据存储。

（2）从划分服务粒度而言，MSA侧重于服务划分的细粒度、可重用性，每个方法都可以成为一个独立的微服务，每个微服务负责明确的任务，并且将处理任务的结果以轻量级API的形式返回给外部；相比之下，SOA对服务的划分没有这么细致，主要是根据MES的业务功能来划分服务，以减少服务数量，简化服务调用以及服务管理。

（3）在软件开发模式上，SOA注重共同治理和标准，MSA则更注重团队协作和自由选择，团队可以为不同的组件使用不同的堆栈，可以更轻松地更新代码。SOA的目标最大化应用程序服务的可重用性，重点关注业务功能重用，当系统改变时需要修改程序；MSA则专注于解耦，更关注边界上下文，系统的改变是创建一个新的服务。MSA的组件可以彼此独立地进行缩放，从而减少了因必须缩放整个应用程序而产生的浪费和成本。

（4）从部署方式上，MSA应用Docker技术不依赖于任何服务器和数据模型，是一个可自动化部署的全栈应用，每个微服务都运行在自己的进程里。而SOA则通过不同层进行打包，比如展现层打包war包，业务层打包为jar包等。

MES微服务架构如图6所示。该架构主要由表示层、微服务管理层、微服务层和数据库层组成。

（1）微服务层：主要提供MES业务功能所需要的所有独立的微服务，包括制造过程管理微服务、文档管理微服务、日志管理微服务等。每个微服务可能有自己的数据库或者多个微服务公用一个数据库。每个微服务需要对外提供轻量级API接口。

（2）微服务管理层：通过微服务管理层来完成对微服务的管理以及处理逻辑，包括微服务网关、微服务注册与发现、微服务接口与微服务代理等。当微服务启动时，会自动将其信息注册到服务注册表中，比如每个服务的IP和端口。当微服务客户端表示层发出请求时，将请求发送到微服务网关中，微服务网关读取请求数据，并从服务注册表中获取对应服务的信息(IP与端口)。最后微服务网关主动去调用下面对应的微服务。

（3）微服务客户端表示层：主要是通过微服务管理层中相应MES业务模块的服务代理向微服务服务端发送请求，经过微服务管理层内部处理后再将请求传递给相应模块服务的服务接口进行MES服务端处理，完成后将相应信息按照相反顺序依次传递给MES客户端，这种传递一般都是通过调用API来实现的。

相比于传统的单体架构，基于微服务架构的MES实现功能服务化，在系统设计开发、应用与维护等方面具有明显优势，其设计开发模式是对现有复杂大型单体应用架构以业务为单元进行拆分，每个拆分的微服务应用都可以单独部署和测试，可以采用单独的技术架构、独立的数据存储、独立的开发运营团队支撑，快速以微服务应用为单位进行弹性扩展，通过降低各个业务单元之间的耦合关系以简化开发过程，降低开发成本。此外，MES微服务架构支持工业云商业新模式，并提供广泛的移动化支持。