基于微服務的紡織信息化平臺改造與實現

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

(鄭州輕工業大學電氣信息工程學院，河南 鄭州 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帶來了更強的并發處理能力與更低的時延。本研究對紡織系統的設計、開發具有一定的借鑒價值。