龔 琦，江 豪，馮立增，王 錦，王永華

(鄭州輕工業(yè)大學(xué)電氣信息工程學(xué)院，河南 鄭州 450002)

0 引言

新時(shí)期，傳統(tǒng)制造業(yè)需要快速應(yīng)對(duì)外部環(huán)境的變化，調(diào)整經(jīng)營(yíng)策略，促進(jìn)生產(chǎn)。這些都需要對(duì)原有的信息化平臺(tái)進(jìn)行更新。紡織企業(yè)對(duì)信息化平臺(tái)的可擴(kuò)展性要求也越來(lái)越高。紡織業(yè)兩化融合在未來(lái)將會(huì)不斷加深，物聯(lián)網(wǎng)技術(shù)也開始在物聯(lián)網(wǎng)上大規(guī)模應(yīng)用。這對(duì)服務(wù)端提出了更高的要求：服務(wù)端需要提供高并發(fā)、高負(fù)載、高可用的服務(wù)[1]，并且可以快速迭代。傳統(tǒng)的單塊應(yīng)用基于現(xiàn)有的服務(wù)需求，架設(shè)較為穩(wěn)固的紡織信息化平臺(tái)。這種穩(wěn)固的架構(gòu)設(shè)計(jì)與技術(shù)、需求快速迭代之間的矛盾，已逐漸成為制約紡織企業(yè)發(fā)展的重要因素，所以需要用一套更加靈活的技術(shù)架構(gòu)來(lái)解決現(xiàn)有系統(tǒng)的不足。

1 微服務(wù)介紹

微服務(wù)概念出現(xiàn)于2012年，由于其加快Web和移動(dòng)應(yīng)用程序開發(fā)進(jìn)程的的特性，自2014年開始受到各方的關(guān)注。微服務(wù)是把一個(gè)大型的單塊應(yīng)用程序和服務(wù)拆分為數(shù)個(gè)甚至數(shù)十個(gè)的較為獨(dú)立的微服務(wù)，可擴(kuò)展單個(gè)組件而不是整個(gè)應(yīng)用程序堆棧，從而滿足企業(yè)產(chǎn)品快速迭代需求[2]。微服務(wù)在應(yīng)用的過(guò)程中已經(jīng)形成了一整套技術(shù)標(biāo)準(zhǔn)。

①單一職責(zé)：每個(gè)服務(wù)都專注于一件事，通過(guò)服務(wù)相互調(diào)用完成應(yīng)用構(gòu)建。

②微：每個(gè)服務(wù)都具有較為完整的結(jié)構(gòu)，如擁有數(shù)據(jù)層、服務(wù)層和控制層。

③面向服務(wù)：每一個(gè)服務(wù)都具有對(duì)外HTTP接口，可以在沒有任何配置、不會(huì)破壞原程序的情況下調(diào)用這些服務(wù)。

④自治：服務(wù)與服務(wù)是隔離的，可以自由選擇技術(shù)棧。

⑤易擴(kuò)展：由于服務(wù)之間的松耦合，可以很容易地?cái)U(kuò)展應(yīng)用，而不用擔(dān)心影響原來(lái)服務(wù)的使用。

⑥流程化：業(yè)務(wù)的難度可以分解到多個(gè)服務(wù)中，通過(guò)分步來(lái)稀釋復(fù)雜度，降低每個(gè)服務(wù)的業(yè)務(wù)難度，使應(yīng)用開發(fā)更加方便、更易理解、更好維護(hù)。

微服務(wù)可以實(shí)現(xiàn)系統(tǒng)敏捷開發(fā)、部署；可以更好地進(jìn)行系統(tǒng)分布式處理，對(duì)服務(wù)器要求更低，高并發(fā)、響應(yīng)速度更快；沒有整體式系統(tǒng)對(duì)技術(shù)棧限制，可以用更恰當(dāng)?shù)募夹g(shù)實(shí)現(xiàn)服務(wù)。微服務(wù)架構(gòu)非常適用于云計(jì)算平臺(tái)，可以根據(jù)企業(yè)需求快速部署到云平臺(tái)提供服務(wù)，具有更強(qiáng)的靈活性[3]?？偨Y(jié)來(lái)說(shuō)，微服務(wù)應(yīng)用具有組件化、快速、可復(fù)用、機(jī)動(dòng)靈活的優(yōu)點(diǎn)。這些特點(diǎn)在系統(tǒng)規(guī)?？焖倥蛎洝I(yè)務(wù)系統(tǒng)快速迭代的當(dāng)下無(wú)疑是可貴的。所以，紡織MES的微服務(wù)化改造是一種必然選擇。

2 關(guān)鍵技術(shù)介紹

2.1 服務(wù)間通信技術(shù)

所有的微服務(wù)都是獨(dú)立的Java進(jìn)程運(yùn)行在獨(dú)立的Docker容器中。這種沙盒機(jī)制一方面保證了服務(wù)的安全性與可重用性，另一方面也加大了服務(wù)間通信(inter process communication,IPC)難度。服務(wù)間通信已經(jīng)有很多成熟的解決方案，按照阻塞情況可以分成以下兩大類。

2.1.1 同步調(diào)用

同步調(diào)用是目前服務(wù)間通信常見的選擇，采用訪問/應(yīng)答模式，消息的延遲更小。在同步調(diào)用中，又分成了兩大技術(shù)流派。

①REST HTTP，作為SpringBoot平臺(tái)推薦的服務(wù)間調(diào)用方式，通過(guò)Json文件實(shí)現(xiàn)消息傳遞。其實(shí)現(xiàn)簡(jiǎn)單，無(wú)平臺(tái)依耐性，可以跨語(yǔ)言調(diào)用，能跨防火墻，適用性好。

②遠(yuǎn)程過(guò)程調(diào)用(remote procedure call,RPC)協(xié)議需要在服務(wù)調(diào)用者和接收者之間統(tǒng)一編碼與解碼過(guò)程，定制性好、通信效率高，通常用來(lái)實(shí)現(xiàn)企業(yè)內(nèi)部服務(wù)間通信。Dobbo是當(dāng)前微服務(wù)中的常用RPC通信協(xié)議。

2.1.2 異步消息調(diào)用

異步消息調(diào)用實(shí)現(xiàn)更為復(fù)雜，需要引入專門的消息中轉(zhuǎn)，緩存發(fā)送者發(fā)送的數(shù)據(jù)，并由接收者到緩存區(qū)提取數(shù)據(jù)。企業(yè)常用的消息中間件包括Kafka、RabbitMQ和ActiveMQ。相比較同步調(diào)用方式，異步調(diào)用引入了中間層，使實(shí)時(shí)性更差，從而可以緩沖尖峰數(shù)據(jù)流、提高數(shù)據(jù)處理效率。

每種通信方式都有其自身的優(yōu)勢(shì)和不足。在企業(yè)微服務(wù)架構(gòu)中，通常按照應(yīng)用場(chǎng)合靈活選擇：在數(shù)據(jù)量較大時(shí)，選擇異步消息調(diào)用來(lái)緩沖數(shù)據(jù)；在企業(yè)內(nèi)部的通信采用速度更高的RPC通信；在出現(xiàn)跨防火墻或跨平臺(tái)的應(yīng)用場(chǎng)景時(shí)，選擇耦合更小的REST HTTP通信[4]。

2.2 服務(wù)網(wǎng)關(guān)

傳統(tǒng)紡織信息化系統(tǒng)開發(fā)過(guò)程中，所有的服務(wù)都構(gòu)建在Tomcat服務(wù)器中?？蛻舳丝梢灾苯釉L問服務(wù)器的IP與接口。采用微服務(wù)架構(gòu)后，紡織信息化系統(tǒng)由許多獨(dú)立的服務(wù)構(gòu)成。每個(gè)服務(wù)都運(yùn)行在獨(dú)立的虛擬機(jī)中，擁有獨(dú)立的IP地址。客戶端如何訪問這些服務(wù)已成為一個(gè)較為嚴(yán)重的問題，因?yàn)榭蛻舳瞬豢赡苡涀∷蟹?wù)的地址。而且在微服務(wù)應(yīng)用中，服務(wù)上下線是較為正常的現(xiàn)象，前臺(tái)不可能一直維護(hù)這些后臺(tái)服務(wù)的地址。本文采用Zuul集群提供網(wǎng)關(guān)服務(wù)，主要有以下幾個(gè)功能。①為所有后臺(tái)服務(wù)提供統(tǒng)一的服務(wù)入口，不管后臺(tái)服務(wù)的地址如何改變，這個(gè)入口的地址不變。②為用戶提供更好的服務(wù)體驗(yàn)，客戶端與后臺(tái)服務(wù)通信需要經(jīng)過(guò)各種路由跳轉(zhuǎn)，通信難度與時(shí)間延遲要遠(yuǎn)遠(yuǎn)超過(guò)后臺(tái)服務(wù)間的調(diào)用，通過(guò)網(wǎng)關(guān)可以降低客戶端與后臺(tái)通信次數(shù)，節(jié)流提效。③保護(hù)后臺(tái)系統(tǒng)不受非法訪問，通過(guò)網(wǎng)關(guān)可以方便實(shí)現(xiàn)權(quán)限鑒定，過(guò)濾不合法的訪問。

網(wǎng)關(guān)也可能給系統(tǒng)帶來(lái)單點(diǎn)故障。一旦網(wǎng)關(guān)停止服務(wù)，整個(gè)系統(tǒng)就不能提供服務(wù)。本文采用Zuul技術(shù)框架。Zuul是專為解決單點(diǎn)故障而設(shè)計(jì)的服務(wù)網(wǎng)關(guān)，可以通過(guò)集群的方式提供服務(wù)。

2.3 服務(wù)注冊(cè)與發(fā)現(xiàn)技術(shù)

拆分后的服務(wù)運(yùn)行時(shí)需要其他服務(wù)提供支持。但在微服務(wù)架構(gòu)中，一般每一個(gè)服務(wù)都是基于容器部署的，會(huì)有多個(gè)拷貝來(lái)實(shí)現(xiàn)負(fù)載均衡。一個(gè)服務(wù)隨時(shí)可能下線，也可能應(yīng)對(duì)臨時(shí)訪問壓力而增加新的服務(wù)節(jié)點(diǎn)。服務(wù)消費(fèi)者需要調(diào)用服務(wù)提供者的某個(gè)方法，需要有一個(gè)地方找到服務(wù)提供者的位置信息；服務(wù)提供者也需要暴露相關(guān)方法供消費(fèi)者調(diào)用。這就涉及到服務(wù)發(fā)現(xiàn)的實(shí)現(xiàn)。常用的方法是通過(guò)zookeeper等技術(shù)做服務(wù)注冊(cè)信息的分布式管理[5-6]。當(dāng)服務(wù)上線時(shí)，服務(wù)提供者將自己的服務(wù)信息注冊(cè)到zookeeper集群，并通過(guò)心跳機(jī)制維持長(zhǎng)鏈接，實(shí)時(shí)更新鏈接信息。服務(wù)消費(fèi)者通過(guò)zookeeper，根據(jù)可定制算法找到服務(wù)后，還可以將服務(wù)信息緩存在本地以提高性能。當(dāng)服務(wù)下線時(shí)，zookeeper會(huì)發(fā)通知給服務(wù)客戶端。

zookeeper集群作為服務(wù)注冊(cè)中心的最大問題是：當(dāng)Master節(jié)點(diǎn)出現(xiàn)網(wǎng)絡(luò)故障而變得不可用之后，其他節(jié)點(diǎn)需要進(jìn)行l(wèi)eader選舉。這個(gè)過(guò)程為30～120 s，期間zookeeper集群不再對(duì)外提供注冊(cè)服務(wù)。而Eureka集群各個(gè)節(jié)點(diǎn)都是平等的，只要有一個(gè)節(jié)點(diǎn)可用就可對(duì)外提供服務(wù)。Eureka集群提供了一種高可用與數(shù)據(jù)最終一致性的服務(wù)，允許各節(jié)點(diǎn)數(shù)據(jù)存在不一致以保證系統(tǒng)高可用。服務(wù)注冊(cè)與發(fā)現(xiàn)可以容忍獲得地址一定錯(cuò)誤，可以通過(guò)報(bào)告失效節(jié)點(diǎn)、重新獲取新的服務(wù)地址來(lái)保證整體服務(wù)穩(wěn)定運(yùn)行。

2.4 服務(wù)的容錯(cuò)機(jī)制

整體式開發(fā)存在一個(gè)很大的風(fēng)險(xiǎn)：應(yīng)用部署在一個(gè)服務(wù)器上，一榮俱榮，一損俱損。而微服務(wù)的相互間調(diào)用在系統(tǒng)內(nèi)部組成了一個(gè)較為復(fù)雜的鏈路網(wǎng)絡(luò)。一個(gè)環(huán)節(jié)出現(xiàn)問題，會(huì)通過(guò)傳導(dǎo)影響其他系統(tǒng)使用。所以需要一定的容錯(cuò)機(jī)制來(lái)保障系統(tǒng)整體可用。相應(yīng)的方法如下所示。①重試機(jī)制，訪問失敗后重試服務(wù)。②限流，超過(guò)設(shè)定訪問數(shù)后拒絕新的服務(wù)申請(qǐng)。③熔斷機(jī)制，服務(wù)多次訪問故障后對(duì)其進(jìn)行熔斷保護(hù)。④負(fù)載均衡，使服務(wù)訪問按照設(shè)定權(quán)重分配。⑤服務(wù)降級(jí)，服務(wù)器訪問過(guò)大時(shí)關(guān)閉一部分非主要業(yè)務(wù)來(lái)保證主業(yè)務(wù)順利進(jìn)行。

重試機(jī)制能解決一部分問題。但值得注意的是，重試機(jī)制作用域是有限制的。它只能作用于冪等性問題(不管發(fā)起多少次請(qǐng)求，結(jié)果都一致的請(qǐng)求)，如數(shù)據(jù)讀取、修改、刪除操作。這一限制是為了防止誤操作。比如對(duì)一個(gè)數(shù)據(jù)添加操作，如果使用重試機(jī)制，可能導(dǎo)致數(shù)據(jù)重復(fù)添加。通常，為了保障系統(tǒng)的健壯性，所有的服務(wù)容錯(cuò)手段都是一起使用的，可保證單個(gè)服務(wù)出現(xiàn)問題時(shí)不會(huì)影響其他服務(wù)。

3 設(shè)計(jì)與實(shí)現(xiàn)

3.1 業(yè)務(wù)需求分析

改進(jìn)現(xiàn)有紡織信息化平臺(tái)服務(wù)端的系統(tǒng)架構(gòu)，使現(xiàn)有系統(tǒng)具有更加靈活的擴(kuò)展能力與更好的數(shù)據(jù)承載能力。紡紗車間包括清花、梳棉、并條、精梳、粗紗、細(xì)紗、絡(luò)筒、倍捻、整經(jīng)、漿紗、織布、整理等工序，工序復(fù)雜，員工流動(dòng)大，管理較為復(fù)雜，責(zé)任認(rèn)定困難。所以需要對(duì)紡紗信息化平臺(tái)系統(tǒng)原材料、產(chǎn)品、設(shè)備與員工之間的關(guān)系進(jìn)行映射，明確不合格品的產(chǎn)生原因，快速定位問題和解決問題，以方便企業(yè)管理。

3.2 系統(tǒng)業(yè)務(wù)拆分

系統(tǒng)拆分是微服務(wù)架構(gòu)設(shè)計(jì)中的重要一步，直接關(guān)系到系統(tǒng)的性能與開發(fā)難度[7]。拆分的粒度過(guò)粗，達(dá)不到系統(tǒng)想要的耦合度；拆分的粒度過(guò)細(xì)，系統(tǒng)開發(fā)、運(yùn)維難度過(guò)大。微服務(wù)架構(gòu)的系統(tǒng)主要按照功能進(jìn)行拆分。

相比傳統(tǒng)的模型-視圖-控制(model view controller,MVC)架構(gòu)橫向拆分，微服務(wù)是將工程縱向拆分，每個(gè)服務(wù)都是可獨(dú)立運(yùn)行的。在紡織制造執(zhí)行系統(tǒng)(manufacturing execution system,MES)中，拆分過(guò)程中需要遵循一些原則。較為重要、關(guān)鍵的業(yè)務(wù)是拆分的重點(diǎn)。如領(lǐng)導(dǎo)較為關(guān)注的質(zhì)量管理業(yè)務(wù)是需要拆分出來(lái)的。另外，需要注意服務(wù)調(diào)用鏈路長(zhǎng)度。過(guò)長(zhǎng)的鏈路調(diào)用會(huì)導(dǎo)致系統(tǒng)出現(xiàn)“雪崩”現(xiàn)象，破壞系統(tǒng)穩(wěn)定性。紡織MES業(yè)務(wù)拆分如圖1所示。

圖1 紡織MES業(yè)務(wù)拆分圖

在紡織信息化平臺(tái)架構(gòu)設(shè)計(jì)中:業(yè)務(wù)系統(tǒng)主要可以分為面向用戶訪問的產(chǎn)品服務(wù)、給產(chǎn)品服務(wù)提供服務(wù)的基礎(chǔ)服務(wù)；信息化系統(tǒng)可以按照工序?qū)ο到y(tǒng)進(jìn)行拆分。此外，也可以按照功能進(jìn)行拆分。但拆分不是越細(xì)越好，如權(quán)限管理模塊在業(yè)務(wù)發(fā)展中是不會(huì)經(jīng)常變化的，而且本身獨(dú)立性較強(qiáng)，如果沒有必要，可以整體作為一個(gè)服務(wù)來(lái)構(gòu)建。這也對(duì)系統(tǒng)起到了較好的保護(hù)作用。所以拆分是一個(gè)適度選擇的問題，粒度過(guò)細(xì)或過(guò)粗都不好。

3.3 架構(gòu)實(shí)現(xiàn)

基于微服務(wù)的紡織MES架構(gòu)如圖2所示。為了實(shí)現(xiàn)圖2微服務(wù)架構(gòu)設(shè)計(jì)，選擇SpringBoot+SpringCloud作為紡織信息化平臺(tái)核心框架。SpringBoot是基于Java開發(fā)的簡(jiǎn)化配置工具，可以簡(jiǎn)化部分配置，與微服務(wù)架構(gòu)的大量服務(wù)開發(fā)相貼合，是實(shí)現(xiàn)快速開發(fā)的首選技術(shù)。SpringCloud是微服務(wù)技術(shù)工具整合在Spring平臺(tái)的一個(gè)微服務(wù)開發(fā)工具集，包括服務(wù)發(fā)現(xiàn)、服務(wù)治理、服務(wù)配置、鏈路追蹤等工具[8]。有了SpringCloud，就可以使用其中的工具管理微服務(wù)，不用再自行設(shè)計(jì)相關(guān)服務(wù)，簡(jiǎn)化了微服務(wù)的開發(fā)流程。

圖2 基于微服務(wù)的紡織MES架構(gòu)圖

在SpringCloud中，選擇NetflexZuul作為API Gateway，實(shí)現(xiàn)訪問接口統(tǒng)一化管理和負(fù)載均衡；選擇Netflex Eureka作為服務(wù)注冊(cè)與發(fā)現(xiàn)中心，通過(guò)服務(wù)的注冊(cè)實(shí)現(xiàn)生產(chǎn)者與消費(fèi)者服務(wù)間調(diào)用注冊(cè)；選擇Netflex Ribbon作為服務(wù)提供者端的負(fù)載均衡器；選擇SpringCloud Config作為服務(wù)配置中心配置服務(wù)。

紡織MES是一個(gè)有較大數(shù)據(jù)寫入的系統(tǒng)。為了保障寫入系統(tǒng)的穩(wěn)定，采用RabbitMQ緩存寫入數(shù)據(jù)，消除寫入的數(shù)據(jù)流抖動(dòng)；采用虛擬化容器Docker技術(shù)來(lái)實(shí)現(xiàn)資源的虛擬化，保障開發(fā)、測(cè)試、運(yùn)維環(huán)境的一致性。為了達(dá)到對(duì)Docker容器的部署與管理，采用Kubernetes對(duì)Docker容器進(jìn)行部署與管理，實(shí)現(xiàn)多臺(tái)廉價(jià)服務(wù)器的集群管理[9]。

3.4 使用效果

為了驗(yàn)證微服務(wù)架構(gòu)紡織MES相比傳統(tǒng)MES的優(yōu)勢(shì)，按照上述步驟構(gòu)建微服務(wù)紡織信息化系統(tǒng)，并且對(duì)其進(jìn)行仿真測(cè)試試驗(yàn)。本次試驗(yàn)數(shù)據(jù)由一個(gè)采集數(shù)據(jù)模擬程序模擬車間采集數(shù)據(jù)發(fā)送給紡織MES，然后利用爬蟲程序模擬瀏覽器端訪問服務(wù)端，比較微服務(wù)架構(gòu)與單塊架構(gòu)MES的數(shù)據(jù)訪問。仿真試驗(yàn)結(jié)果如表1所列。

表1 仿真試驗(yàn)結(jié)果

從表1中可以得出以下結(jié)論。①微服務(wù)架構(gòu)解決了模塊復(fù)用困難的問題，加快了項(xiàng)目開發(fā)。單塊架構(gòu)由于系統(tǒng)間耦合，模塊復(fù)用性不強(qiáng)。而微服務(wù)架構(gòu)由于微服務(wù)容器化部署，可以一次構(gòu)建，多處使用，加速開發(fā)。②微服務(wù)架構(gòu)有更好的容錯(cuò)能力，用微服務(wù)架構(gòu)構(gòu)建的紡織MES，可以自適應(yīng)熔斷不可用的服務(wù)，使系統(tǒng)更加安全。③微服務(wù)為紡織MES帶來(lái)了更高的并發(fā)處理能力。作為分布式的架構(gòu)，微服務(wù)構(gòu)建的MES可以并發(fā)處理請(qǐng)求，適用于大規(guī)模數(shù)據(jù)實(shí)時(shí)分析，使系統(tǒng)的時(shí)間延遲更小。

4 結(jié)束語(yǔ)

本文實(shí)現(xiàn)了基于紡織信息化平臺(tái)的微服務(wù)架構(gòu)設(shè)計(jì)。在項(xiàng)目更新頻率越來(lái)越快、項(xiàng)目越來(lái)越復(fù)雜的紡織信息化平臺(tái)開發(fā)中，微服務(wù)架構(gòu)具有更強(qiáng)的擴(kuò)展能力與容錯(cuò)能力，能使紡織信息化平臺(tái)更加靈活、健壯，滿足紡織企業(yè)快速構(gòu)建信息化平臺(tái)與快速迭代的需求，也為紡織MES帶來(lái)了更強(qiáng)的并發(fā)處理能力與更低的時(shí)延。本研究對(duì)紡織系統(tǒng)的設(shè)計(jì)、開發(fā)具有一定的借鑒價(jià)值。