面向數字化生產的執行制造系統設計與實現

陳華品,朱望純

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

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

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

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

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

1 基于微服務的MES系統架構

1.1 軟件設計架構的演變

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

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

表1 SOA與微服務架構對比

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

1.2 MES平臺總體架構設計

本系統基于微服務架構開發,結合持續集成和容器化部署的MES系統,總體架構如圖1所示。

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

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

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

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

2 微服務在MES系統中的應用

2.1 MES微服務劃分

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

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

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

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

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

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

2.2 MES系統微服務組件的治理實現

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

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

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

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

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

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

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

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

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

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

2.3.2 Redis緩存設計

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

圖3 Redis緩存處理流程

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

3 數據可視化技術研究

3.1 基于Echarts的生產數據可視化

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

圖4 Echarts動態數據可視化流程

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

4 微服務MES系統容器化部署

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

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

圖5 持續集成容器化部署時序

4.2 Jenkins構建插件配置

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

4.3 微服務容器鏡像構建

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

4.4 鏡像管理與分發

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

4.5 部署實例

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

5 MES系統的實現與性能測試

5.1 MES系統的實現

基于微服務架構與上述關鍵技術對MES系統進行功能實現,按照功能對MES系統進行微服務劃分,結合相關微服務組件進行微服務治理,從而實現按需組件化開發,并在阿里云ECS服務器遠程成功運行?？傮w應用開發效果如圖6所示。

圖6 總體應用的開發效果

5.2 MES系統的性能測試

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

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

圖7 Jmeter響應時間性能對比

5.3 MES系統的測試結果分析

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

6 結束語

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