面向數(shù)字化生產的執(zhí)行制造系統(tǒng)設計與實現(xiàn)

陳華品,朱望純

(桂林電子科技大學 電子工程與自動化學院,廣西 桂林 541004)

近年來,隨著中國制造業(yè)迅猛發(fā)展,越來越多的人意識到制造業(yè)信息化在智能制造的關鍵地位,其中數(shù)字化工業(yè)軟件深入到制造業(yè)信息化的各個環(huán)節(jié)。以執(zhí)行制造系統(tǒng)(MES)為代表的生產調度與過程管理類工業(yè)軟件迎來了巨大的需求空間。隨著智能制造理念深入人心及工業(yè)互聯(lián)網、大數(shù)據、云計算等技術不斷向前推進,MES系統(tǒng)正沿著跨平臺、網絡化、智能化、虛擬化的方向發(fā)展,并涌現(xiàn)出一系列研究成果。

制造業(yè)越來越精細化、復雜化,導致執(zhí)行制造系統(tǒng)復雜度攀升。在實際應用中面臨生產數(shù)據如何互聯(lián)互通、數(shù)據展示不直觀、業(yè)務迭代與運維困難等諸多障礙[1],中外許多企業(yè)和研究人員做出了積極探索。陸文虎等[2]將微服務體系架構應用于MES系統(tǒng)業(yè)務功能設計,對MES系統(tǒng)微服務架構中的關鍵技術進行研究,通過微服務劃分、統(tǒng)一調度、服務管理解決系統(tǒng)模塊耦合度高、靈活性差的問題,并驗證了微服務架構應用于復雜MES系統(tǒng)中的可行性。張祖軍等[3]開發(fā)了一套基于B/S架構的MES系統(tǒng),分析和實現(xiàn)了智能制造生產線下的業(yè)務功能和邏輯。黃啟啟等[4]基于微服務架構將復雜的倉儲管控系統(tǒng)劃分為多個協(xié)同、自治的微服務單元,通過消息中間件對多個微服務協(xié)同管理,實現(xiàn)系統(tǒng)的高性能、高可用。

目前,企業(yè)一般采用內部部署MES系統(tǒng),自備服務器和機房,專人維護。在集群環(huán)境下,安裝人員逐一進行環(huán)境配置、安裝,存在重復性勞動、工作量巨大、部署效率低、資源浪費等問題,且在后期運行階段,硬件設備更換、系統(tǒng)功能升級、版本維護都很困難。付琳琳等[5]研究了微服務特性和Docker虛擬化技術,對微服務容器化部署的需求和可行性進行分析,通過Dockerfile制作微服務鏡像,使用容器編排工具Docker-Compose實現(xiàn)部署的容器化、自動化。上述研究在MES系統(tǒng)開發(fā)中引入微服務架構,在微服務部署時引入容器化方面做出了一系列深入的探索,對構建面向復雜業(yè)務的MES系統(tǒng)有一定的借鑒意義[6]。

為滿足MES系統(tǒng)跨平臺化、智能化、云化的需求,結合微服務架構,開發(fā)了一套按功能劃分微服務單元的MES系統(tǒng),通過SpringCloud微服務組件完成獨立、非耦合的微服務業(yè)務單元之間的信息交互,結合Jenkins和Docker實現(xiàn)持續(xù)集成和容器化部署,實現(xiàn)執(zhí)行制造系統(tǒng)的可擴展、高可用。

1 基于微服務的MES系統(tǒng)架構

1.1 軟件設計架構的演變

隨著企業(yè)級應用系統(tǒng)業(yè)務規(guī)模和復雜度的持續(xù)攀升,軟件架構隨著需求端的變化不斷發(fā)展與迭代,前后經歷了從最初的單體式架構、分布式系統(tǒng)過渡到面向服務的架構(serviceorientedarchitecture,簡稱SOA),再到流行的微服務架構的演變[7]。

SOA 基于面向服務的思想,將可重用功能抽取為組件,以服務的方式進行調用,項目與服務之間采用企業(yè)服務總線(ESB)進行通信。由于ESB在SOA中仍處于核心位置,這種中心化致使SOA 難以實現(xiàn)真正的面向服務和組件化[8]。而微服務是一組功能職責單一、低內聚高耦合的服務組件化解決方案,組件之間通過輕量級的通信機制進行通信,組件由注冊中心統(tǒng)一管理服務列表,通過服務調用的方式向其他組件開放服務地址和服務功能。相比于SOA,微服務架構強調去ESB,去中心化,具有更大的靈活性,其劃分的細粒度更小,可重用性更高,數(shù)據獨立存儲[9]。SOA與微服務架構的特性對比如表1所示。

表1 SOA與微服務架構對比

基于微服務的MES系統(tǒng)將系統(tǒng)功能微服務化,通過WEB API向外部提供服務。不同的微服務具有平臺無關性,微服務的調用與位置、編程語言、系統(tǒng)配置無關,具有高度的可重用性,易于對業(yè)務功能與模塊水平垂直拆分、切割[10]。

1.2 MES平臺總體架構設計

本系統(tǒng)基于微服務架構開發(fā),結合持續(xù)集成和容器化部署的MES系統(tǒng),總體架構如圖1所示。

最上層是用戶訪問層,主要用于用戶交互和后臺管理,提供用戶友好界面并簡化操作邏輯,根據用戶請求指令向用戶展示結果。網關層是整個MES平臺系統(tǒng)的唯一入口,通過Nginx放置前端靜態(tài)資源,并接收用戶Http請求,將用戶的請求按照Nginx配置的路由規(guī)則分發(fā)到不同的網關服務器上,可避免系統(tǒng)單點故障,提高可用性。

中間層是業(yè)務層,基于數(shù)據驅動將MES系統(tǒng)提供的服務劃分為獨立運行部署的5個核心微服務單元,分別是系統(tǒng)管理微服務、物料BOM 管理微服務、工藝管理微服務、計劃管理微服務、數(shù)據可視化微服務。每個微服務單元都相互獨立,通過提供RESTful風格的API接口對外發(fā)布應用服務接口,當接收到用戶的合法服務請求指令時,會調用相應的微服務實例,并返回調用結果。

數(shù)據層負責存儲MES系統(tǒng)的所有數(shù)據,由Redis緩存和MySQL數(shù)據庫組成。為減少數(shù)據庫的訪問量,提高系統(tǒng)并發(fā)能力,引入Redis緩存機制,將用戶數(shù)據和熱門數(shù)據放在緩存中,通過緩存將大多數(shù)請求攔截在訪問數(shù)據庫之前,提高了響應時間,大大降低了MySQL數(shù)據庫訪問壓力。

基礎設施層主要包括服務器、存儲、網絡等物理硬件,系統(tǒng)采用阿里云ECS作為生產部署服務器,為整個系統(tǒng)運行提供環(huán)境支撐[11]。

2 微服務在MES系統(tǒng)中的應用

2.1 MES微服務劃分

MES系統(tǒng)主要功能包括系統(tǒng)管理、物料BOM管理、工藝管理、工單計劃管理、數(shù)據可視化顯示等微服務單元。

1)系統(tǒng)管理微服務。系統(tǒng)主要面向后臺管理,包括對用戶、部門、角色、權限信息的維護。使用基于角色的訪問控制模型對用戶身份進行校驗和授權,管理云平臺中各類角色用戶的在本平臺中的各種訪問權限的賦予和撤銷,保證了內部資源的安全性。

2)物料管理模塊。模塊主要進行原材料的統(tǒng)一編碼、數(shù)量核算,物料屬性的定義、修改、維護、查詢等基本操作,按照配料計劃中生成的配料單指定某個生產線的所有原材料,并按照入庫、出庫、轉移等物料流轉關鍵點對每一類物料的交接數(shù)量、物料種類、名稱、轉移時間、所在位置信息等進行詳細的記錄,實現(xiàn)原材料的有效追溯與統(tǒng)計。

3)工藝管理微服務。工藝管理模塊針對離散制造業(yè)工藝流程不連續(xù)的特點,根據不同產品的特點進行工藝調整。按照生產工序,一個完整的加工流程可以分解成若干子過程,根據訂單需求以及具體產線情況進行設計。

4)計劃管理微服務。工單計劃管理模塊綜合考慮客戶訂單信息和設備數(shù)量、產線數(shù)量、人員班組等信息,對各類產品進行合理的分配、排產,將工單分配到具體的產線和工作班組進行生產。

5)數(shù)據可視化微服務。模塊設計包括設備狀態(tài)、生產計劃完成率分析和最終產品質量分析。系統(tǒng)通過二維或三維柱形圖、折線圖和表格等多種表現(xiàn)形式,以數(shù)字化大屏方式對MES系統(tǒng)中實時數(shù)據或統(tǒng)計數(shù)據的展示。

2.2 MES系統(tǒng)微服務組件的治理實現(xiàn)

基于SpringCloudAlibaba搭配Springcloud相關組件進行服務治理,整個MES系統(tǒng)服務治理流程如圖2所示。系統(tǒng)中將所有微服務單元注冊并發(fā)布到注冊中心(NacosServer);服務調用方通過API網關查找注冊中心的服務列表信息;根據獲取的服務地址直接調用相關服務[13],進而完成MES系統(tǒng)數(shù)據的交互。

微服務治理組件主要包括Gateway網關路由、Nacos服務注冊與配置中心、OpenFeign遠程服務調用,Sentinel限流熔斷4個部分。

1)Gateway網關路由。網關作為內部微服務的唯一入口,通過Gateway整合NacosDiscovery,完成面向服務的動態(tài)路由轉發(fā)。API網關將自身參數(shù)信息注冊到NacosServer注冊中心,并通過整合Nacos獲取系統(tǒng)中所有serviceId與實例地址的映射關系;通過匹配application.yml文件對RouteId、URI、Predicate和Filter參數(shù)配置路由規(guī)則,并將外部請求路由到相應的的serviceId。

2)Nacos服務注冊發(fā)現(xiàn)和配置中心。Nacos組件兼具傳統(tǒng)微服務組件中的注冊中心和配置中心的功能。在pom 文件中引入Maven依賴后,在應用啟動類中添加@EnableDiscoveryClient注解開啟服務注冊功能。在yaml配置文件中添加服務名稱和Nacos地址等信息,Nacos 啟動時就將所有MES微服務的元數(shù)據信息(如Host、Port、健康檢查URL等)集中注冊到NacosServer(服務注冊中心)中,在服務調用時通過查詢NacosServer維護的服務列表獲取服務實例[14]。

3)OpenFeign遠程服務調用。OpenFeign是一種聲明式的REST客戶端組件。引入OpenFeign的Maven 依賴后,在Application 類中添加@EnableFeignClients注解掃描可調用的服務端;利用@FeignClient注解的Name或Value屬性可以在服務調用接口上添加指定服務名稱,在控制訪問層Controller通過注解@RequestMapping綁定服務提供的的REST 接口;在服務調用方創(chuàng)建調用類,通過@Autowired引入定義好的接口并創(chuàng)建調用方法,通過服務名稱即可實現(xiàn)聲明式調用。

4)Sentinel限流熔斷。Sentinel是保障微服務高可用的流量控制組件。服務模塊引入Sentinel的Maven依賴后,在配置文件application.yml中配置SentinelDashboard的地址就可以啟動項目,并在SentinelDashboard中新建流控規(guī)則,當函數(shù)調用異常時,也可以設置服務熔斷對應方法。通過@SentinelResource注解的Value值設置限流規(guī)則,通過配置fallback屬性,異常時執(zhí)行fallback=“handlefallback”指定方法優(yōu)化錯誤界面。

2.3 基于Nginx反向代理和Redis緩存高可用設計

2.3.1 基于Nginx和keepalive的高可用負載均衡

Nginx是開源、高性能的Web服務器,將靜態(tài)資源部署在Nginx上,以提高訪問速度。Nginx接收用戶http請求時進行反向代理,按照配置的fair策略(按照響應時間優(yōu)先分配)將請求分發(fā)給相應的網關服務器,對API網關集群進行負載均衡,增加系統(tǒng)穩(wěn)定性。

使用Nginx+keepalive雙主配置實現(xiàn)集群的高可用,兩臺機器互為主備。當出現(xiàn)某臺Nginx宕機時,Keepalived檢測到故障以后將其關閉,另一臺Nginx通過獲取VIP(虛擬IP)繼續(xù)對外提供服務,實現(xiàn)Nginx集群的高可用;當其中一臺機器故障時,通過VRRP協(xié)議(虛擬路由冗余協(xié)議)為基礎使用2個VIP的自動切換,實現(xiàn)故障轉移和自動恢復[15]。

2.3.2 Redis緩存設計

為提高系統(tǒng)的并發(fā)能力,系統(tǒng)設計使用Redis數(shù)據庫作為MySQL數(shù)據庫的緩存,以減輕數(shù)據庫的訪問壓力。對于一些公共接口數(shù)據例如用戶信息、物料信息、訂單信息等不會發(fā)生頻繁變化的熱點數(shù)據,做緩存配置即可。Redis緩存實現(xiàn)讀寫操作的流程如圖3所示。

圖3 Redis緩存處理流程

Jedis是Redis官方推薦的用于實現(xiàn)Redis操作的客戶端。JedisClient接口包含Redis的CURD 操作方法,JedisClentPool類對JedisClient接口的抽象方法進行實現(xiàn),然后通過Mapper接口進行相應的數(shù)據庫操作。當請求到達Redis后,進行讀寫操作的判斷,讀操作首先用JedisClient.get()方法查詢緩存,根據返回的JSON是否為空確定是否查詢數(shù)據庫并添加到緩存;寫操作直接操作數(shù)據庫后更新緩存。

3 數(shù)據可視化技術研究

3.1 基于Echarts的生產數(shù)據可視化

Echarts開源可視化庫提供了一種簡單易用,快速配置圖表的方法,具有直觀、可交互、個性化定制等諸多優(yōu)點,利用Echarts提供的多維的、多種形態(tài)的圖表類型,非常適合MES系統(tǒng)中實時數(shù)據或統(tǒng)計數(shù)據的展示。在使用Echarts實現(xiàn)數(shù)據可視化時,首先引入Echarts的依賴庫,即在標簽中引入＜scriptsrc="js/ECharts.js"＞＜/script＞,然后基于所需的圖表準備合適寬高的DOM 節(jié)點,獲取DOM 容器后通過Echarts.init()方法完成初始化[16]。Echarts動態(tài)數(shù)據可視化流程如圖4所示。

圖4 Echarts動態(tài)數(shù)據可視化流程

生產數(shù)據可視化需要獲取動態(tài)數(shù)據,實時刷新,獲取圖表數(shù)據必然要和數(shù)據庫建立連接。在前臺通過ajax技術按照一定頻率發(fā)出異步請求,由后臺服務器查詢數(shù)據庫數(shù)據,得到后臺JSON 數(shù)據,前臺得到返回值;將通過數(shù)據庫獲取的動態(tài)JSON數(shù)據用于配置Echarts的series屬性,最后調用set-option方法按照動態(tài)數(shù)據繪制曲線。

4 微服務MES系統(tǒng)容器化部署

4.1 微服務容器化部署整體流程

將MES系統(tǒng)按照業(yè)務功能劃分為獨立的微服務之后,每個微服務單元獨立部署,將會面臨重復進行手動部署效率低下、如何實現(xiàn)自動化部署的問題。Docker容器技術的出現(xiàn)為解決微服務應用部署難題提供了新的思路,結合持續(xù)集成工具Jenkins的自動化構建與自動化部署功能,簡化人工部署測試的繁瑣流程,可以有效解決MES系統(tǒng)微服務部署難題[17]。MES系統(tǒng)基于持續(xù)集成和容器化部署時序如圖5所示。

圖5 持續(xù)集成容器化部署時序

4.2 Jenkins構建插件配置

Jenkins持續(xù)集成工具擁有的強大功能源自于其龐大的插件資源庫,可按需配置,制定個性化部署方案。在MES微服務系統(tǒng)的部署中需用到Maven插件和Gitee 插件。GiteeJenkinsPlugin 插件通過WebHook機制設置事件觸發(fā),Jenkins自動拉取最新代碼,并將結果的狀態(tài)碼返回給Gitee平臺。Maven Integration插件對獲得的代碼進行編譯和打包,并生成Maven構建報告。

4.3 微服務容器鏡像構建

鏡像構建是通過Docker將開發(fā)完成的微服務實例和依賴打包并構建輕量級、可移植的微服務容器鏡像。構建鏡像的方法有多種,最常用的是通過Dockerfile基本操作命令編寫dockerfile文本,在Alpine基礎鏡像上結合微服務Jar包定制個性化Docker鏡像,使用Dockerbuild命令執(zhí)行Dockerfile文本即可得到新的鏡像[18],最終完成微服務容器鏡像的構建。

4.4 鏡像管理與分發(fā)

通過系統(tǒng)的微服務構建多個鏡像后,將會面臨容器鏡像管理問題。Docker官方開源了DockerRegistry,用于構建私有鏡像倉庫。通過DockerHub創(chuàng)建私有倉庫,將構建好的微服務鏡像通過Dockerpush命令上傳到私有倉庫,通過DockerPull命令在生產服務器端拉取鏡像,完成鏡像的集中管理與分發(fā)[19]。

4.5 部署實例

系統(tǒng)選用阿里云ECS作為生產部署服務器,結合Gitee插件和Maven插件,通過Jenkins持續(xù)集成工具完成MES系統(tǒng)代碼的拉取、編譯和構建;將微服務Jar包制作成Docker鏡像,并上傳到遠程Docker倉庫中,方便鏡像管理和分發(fā);根據Jenkinsfile流水線腳本依次將項目代碼自動部署到生產服務器,并按順序啟動。與傳統(tǒng)部署方式相比,本系統(tǒng)采用的部署方法大大提升了部署效率,有利于最終實現(xiàn)持續(xù)交付[20]。

5 MES系統(tǒng)的實現(xiàn)與性能測試

5.1 MES系統(tǒng)的實現(xiàn)

基于微服務架構與上述關鍵技術對MES系統(tǒng)進行功能實現(xiàn),按照功能對MES系統(tǒng)進行微服務劃分,結合相關微服務組件進行微服務治理,從而實現(xiàn)按需組件化開發(fā),并在阿里云ECS服務器遠程成功運行。總體應用開發(fā)效果如圖6所示。

圖6 總體應用的開發(fā)效果

5.2 MES系統(tǒng)的性能測試

系統(tǒng)測試服務器型號為阿里云ECS通用性ga6,規(guī)格為4核16Gib內存,操作系統(tǒng)為Centos8.0、64位,JDK 版本為1.8,數(shù)據庫為Redis2.8.4 和MySQL8.0,部署服務器采用Tomcat7.0版本,對單體架構和微服務拆分的MES系統(tǒng)進行單臺服務器獨立部署,使用壓測工具Jmeter分別發(fā)送請求,記錄下二者在相同并發(fā)條件下的測試數(shù)據。

實驗條件:使用ApacheJmeter作為壓力測試工具,設置線程數(shù)為100,模擬100個用戶,所有線程啟動時間Ramp-UpPeriod為1s,循環(huán)次數(shù)分別為1、2、5、8、10,用于模擬并發(fā)數(shù)分別為100、200、500、800、1000時訪問接口的響應時間,設置持續(xù)時間60 s,觀察響應時間、標準差、請求錯誤率等指標的變化情況。不同開發(fā)架構下的響應時間數(shù)據如圖7所示。

圖7 Jmeter響應時間性能對比

5.3 MES系統(tǒng)的測試結果分析

在并發(fā)測試結果中,通過數(shù)據對比可知,在線程數(shù)為100 時,通過改變循環(huán)次數(shù),在并發(fā)量(簡稱QPS)相同的情況下,微服務架構下系統(tǒng)平均響應時間均遠小于單體架構下系統(tǒng)平均響應時間。從錯誤率數(shù)據來看,隨著單體架構并發(fā)數(shù)的增加,錯誤率隨之增加,但始終小于5%。微服務架構較為穩(wěn)定,在并發(fā)量達到1000時仍沒有出現(xiàn)請求出錯的情況,且各個業(yè)務正常訪問的平均響應時間都控制在1s以內。結合響應時間標準差、吞吐量等指標可知,用微服務架構設計發(fā)開的系統(tǒng)多項性能都得到了提升。

6 結束語

根據MES系統(tǒng)業(yè)務特點,分析以往單體架構、SOA架構下系統(tǒng)的性能瓶頸問題。采用基于微服務架構設計全新的MES系統(tǒng),按照業(yè)務功能劃分微服務實例并設計獨立的數(shù)據庫,通過Redis緩存機制來提高數(shù)據庫訪問能力,結合微服務組件實現(xiàn)微服務治理;結合微服務應用部署效率低、版本維護困難的痛點,設計基于Jenkins和Docker的自動化持續(xù)集成部署方案。實際應用效果和實驗說明所提方案相比傳統(tǒng)設計架構在并發(fā)性能、部署維護效率方面有大幅提升,并能更好的支持業(yè)務擴展。后期可探索通過對相關微服務搭建集群來提高可用性,配合集群部署,以在企業(yè)級開發(fā)中發(fā)揮更大作用。