基于微服務(wù)架構(gòu)的制造技術(shù)資源服務(wù)平臺(tái)架構(gòu)研究

薛皓辰，柳先輝

(同濟(jì)大學(xué)電子與信息工程學(xué)院，上海 201804)

1 問(wèn)題提出

現(xiàn)代制造業(yè)專業(yè)化分工越來(lái)越細(xì)，越來(lái)越多的制造企業(yè)將部分生產(chǎn)活動(dòng)交給更專業(yè)的外部協(xié)同加工資源完成，從而專注于自身核心業(yè)務(wù)，快速、高質(zhì)和低成本地生產(chǎn)市場(chǎng)所需的產(chǎn)品［1］；除此之外，很多教育機(jī)構(gòu)和實(shí)訓(xùn)基地也需要這樣的制造技術(shù)資源對(duì)學(xué)生和工人進(jìn)行初步培訓(xùn)。但是，制造資源突破了地理范圍的制約，分散在不同的物理區(qū)域內(nèi)，同時(shí)又相對(duì)獨(dú)立、功能和形式各異，要快速、靈活組織資源，就必須對(duì)其集成［2］。因此，需要制造技術(shù)資源服務(wù)平臺(tái)對(duì)分散的資源進(jìn)行集成，并匹配對(duì)應(yīng)的服務(wù)。傳統(tǒng)的制造技術(shù)資源平臺(tái)多采用單體應(yīng)用的架構(gòu)，但是隨著平臺(tái)業(yè)務(wù)要求的日趨多樣化和復(fù)雜化，單體架構(gòu)設(shè)計(jì)的局限性開(kāi)始顯現(xiàn)。存在的主要問(wèn)題如下：

（1）系統(tǒng)健壯性不足。在單體架構(gòu)的制造技術(shù)資源服務(wù)平臺(tái)中，很有可能因?yàn)閷?duì)某一特定服務(wù)訪問(wèn)人數(shù)的激增而導(dǎo)致特定服務(wù)的不可用。單體應(yīng)用的一個(gè)顯著缺點(diǎn)就是服務(wù)相互不獨(dú)立，所以單體應(yīng)用程序中某個(gè)模塊的癱瘓必將導(dǎo)致整個(gè)系統(tǒng)不可用［3］。

（2）部署復(fù)雜。制造技術(shù)資源平臺(tái)業(yè)務(wù)邏輯復(fù)雜，每一個(gè)資源服務(wù)的修改都需要重新編譯整個(gè)應(yīng)用，非常繁瑣。

（3）伸縮擴(kuò)展性不足。隨著制造技術(shù)資源平臺(tái)的訪問(wèn)人數(shù)增加，平臺(tái)會(huì)對(duì)其中的某個(gè)特定模塊調(diào)優(yōu)，在傳統(tǒng)的單體應(yīng)用中，如果出現(xiàn)性能瓶頸只能對(duì)軟件整體進(jìn)行擴(kuò)展，無(wú)法滿足動(dòng)態(tài)擴(kuò)展的要求［4］。

針對(duì)以上問(wèn)題，本研究提出一種新的微服務(wù)架構(gòu)來(lái)滿足制造技術(shù)資源與服務(wù)平臺(tái)高可用、敏捷開(kāi)發(fā)和動(dòng)態(tài)擴(kuò)展的要求。

2 關(guān)鍵技術(shù)研究

2.1 微服務(wù)基本概念

微服務(wù)是一個(gè)新興的軟件架構(gòu)，就是把一個(gè)大型的單個(gè)應(yīng)用程序和服務(wù)拆分為數(shù)十個(gè)的支持微服務(wù)［5］。微服務(wù)的策略可以使復(fù)雜的業(yè)務(wù)邏輯松耦合，從而實(shí)現(xiàn)敏捷開(kāi)發(fā)、動(dòng)態(tài)擴(kuò)展的目的。

2.2 關(guān)鍵技術(shù)研究

微服務(wù)應(yīng)用的一個(gè)最大的優(yōu)點(diǎn)是，它們往往比傳統(tǒng)的應(yīng)用程序更有效地利用計(jì)算資源［6］。功能瓶頸的問(wèn)題主要通過(guò)組件來(lái)解決，計(jì)算資源分配的最小單位是微服務(wù)，而不是應(yīng)用，這樣就意味著可以充分靈活地利用現(xiàn)有的計(jì)算資源。

微服務(wù)應(yīng)用程序的另一個(gè)好處是，它們更快且更容易更新［7］。在面對(duì)不同的需求時(shí)，可以讓不同的微服務(wù)承擔(dān)不同的職責(zé)，同時(shí)快速部署上線，讓用戶的需求盡早實(shí)現(xiàn)。

微服務(wù)應(yīng)用程序的第3 個(gè)好處是，基于微服務(wù)架構(gòu)的系統(tǒng)具備更高可用性和彈性［8］?；谖⒎?wù)架構(gòu)的系統(tǒng)是去中心化的，當(dāng)一個(gè)微服務(wù)下線時(shí)，其他同類的微服務(wù)將承擔(dān)相應(yīng)的功能，對(duì)外仍可以提供服務(wù)，不會(huì)造成整個(gè)系統(tǒng)無(wú)法訪問(wèn)。

2.3 Docker 基本概念

Docker 是用Go 語(yǔ)言開(kāi)發(fā)的，基于Linux 內(nèi)核的CGroup、Namespace 以及AUFS 類的Union FS 技術(shù)。Docker 通過(guò)容器虛擬化、共享內(nèi)核，把應(yīng)用需要的運(yùn)行環(huán)境、緩存環(huán)境、數(shù)據(jù)庫(kù)環(huán)境等封裝起來(lái)，以最簡(jiǎn)單的方式支持其運(yùn)行［9］。

2.4 容器技術(shù)優(yōu)勢(shì)

傳統(tǒng)的服務(wù)架構(gòu)應(yīng)用部署方式是通過(guò)插件或腳本來(lái)安裝應(yīng)用。這樣做的缺點(diǎn)是應(yīng)用的運(yùn)行、配置、管理、所有生存周期將與當(dāng)前操作系統(tǒng)綁定，不利于應(yīng)用的升級(jí)更新回滾等操作［10］。虛擬機(jī)是解決這一問(wèn)題的一種方法，但是傳統(tǒng)虛擬機(jī)的創(chuàng)建速度和資源利用率會(huì)遠(yuǎn)遠(yuǎn)低于Docker。

新的微服務(wù)架構(gòu)應(yīng)用部署方式是通過(guò)部署Docker 來(lái)實(shí)現(xiàn)快速發(fā)布、自動(dòng)運(yùn)維、自動(dòng)擴(kuò)容和微服務(wù)的動(dòng)態(tài)擴(kuò)展。Docker 在實(shí)際應(yīng)用中的作用主要體現(xiàn)在如下幾個(gè)方面：

（1）代碼管道化管理。使用Docker 能夠令代碼直接發(fā)布到生產(chǎn)環(huán)境中，實(shí)現(xiàn)端到端的發(fā)布流程管理。

（2）作為多租戶容器。Docker 有著靈活發(fā)布和運(yùn)維的管理機(jī)制，可以作為云平臺(tái)的多租戶容器。

（3）應(yīng)用隔離。在微服務(wù)架構(gòu)中，需要把一個(gè)單體應(yīng)用拆分為多個(gè)微服務(wù)，而多個(gè)應(yīng)用服務(wù)部署在多個(gè)Docker 上即可實(shí)現(xiàn)應(yīng)用間的隔離［11］。

3 總體架構(gòu)

微服務(wù)系統(tǒng)的整體架構(gòu)如圖1 所示，基于微系統(tǒng)的服務(wù)平臺(tái)架構(gòu)包含4 層：第一層為資源層，提供網(wǎng)絡(luò)協(xié)同制造過(guò)程中涉及的各類資源；第二層為服務(wù)層，建立虛擬資源池，實(shí)現(xiàn)對(duì)不同的資源與服務(wù)接入、感知、共享、協(xié)同和組合，形成微服務(wù)集群，并提供平臺(tái)引擎與工具；第三層為接口訪問(wèn)層，實(shí)現(xiàn)平臺(tái)高效的對(duì)外接口，使用戶能夠通過(guò)一個(gè)便捷方式來(lái)使用平臺(tái)的資源；第四層為用戶層，技術(shù)資源的使用者、提供者等不同類型的用戶都可以通過(guò)不同的終端與服務(wù)平臺(tái)進(jìn)行交互。

圖1 制造技術(shù)資源服務(wù)平臺(tái)架構(gòu)

4 平臺(tái)設(shè)計(jì)

4.1 資源層設(shè)計(jì)

針對(duì)技術(shù)資源分布分散、服務(wù)能力具有差異性、資源信息平臺(tái)間缺乏共享渠道等問(wèn)題，研究以數(shù)據(jù)抽象、數(shù)據(jù)映射、知識(shí)表示等為關(guān)鍵內(nèi)容的，基于本體的技術(shù)資源與服務(wù)能力虛擬化技術(shù)，實(shí)現(xiàn)對(duì)技術(shù)資源與服務(wù)能力的高效組織和管理，為技術(shù)資源以及服務(wù)能力的查詢、管理、選擇、聚合等提供支持，將現(xiàn)實(shí)生活中的多種資源，例如技術(shù)成果、技術(shù)方案、專利信息等，通過(guò)技術(shù)資源虛擬化和服務(wù)能力虛擬化，異構(gòu)為多種不同的資源池，并向上提供統(tǒng)一的數(shù)據(jù)接口，便于上層調(diào)用。

4.2 服務(wù)層設(shè)計(jì)

4.2.1 微服務(wù)集群

采用微服務(wù)技術(shù)降低服務(wù)間耦合程度，將粗粒度的應(yīng)用層面服務(wù)拆解成細(xì)粒度的微服務(wù)，構(gòu)建出由資源檢索、分析利用等構(gòu)成的微服務(wù)集群，提高服務(wù)的內(nèi)聚程度，使其具有隔離服務(wù)、按需彈性部署以及通信輕量化的特點(diǎn)，達(dá)到敏捷開(kāi)發(fā)和部署的效果，最終能更快地響應(yīng)服務(wù)動(dòng)態(tài)組織的調(diào)用。針對(duì)微服務(wù)化后帶來(lái)的功能分散、資源消耗嚴(yán)重以及運(yùn)維困難的問(wèn)題，采用容器化技術(shù)對(duì)微服務(wù)進(jìn)行編排管理，根據(jù)每個(gè)容器上部署微服務(wù)的不同進(jìn)行資源的合理分配，最大化地利用服務(wù)器資源實(shí)現(xiàn)對(duì)微服務(wù)應(yīng)用調(diào)度、資源管理、服務(wù)管理等多維度的統(tǒng)一管理，極大減少運(yùn)維成本，達(dá)到統(tǒng)一功能的效果。主要采用Spring Cloud 微服務(wù)框架體系中的各個(gè)組件來(lái)實(shí)現(xiàn)微服務(wù)集群，具體包括：

（1）服務(wù)發(fā)現(xiàn)。在服務(wù)發(fā)現(xiàn)這一部分，采用的是Spring Cloud 提供的Eureka 組件。Eureka 組件分為Eureka server 和Eureka client 兩種。Eureka server中存儲(chǔ)服務(wù)注冊(cè)表，將Eureka server 分別部署到多個(gè)不同的物理服務(wù)器上，當(dāng)一個(gè)Eureka 因?yàn)槲锢砘蚱渌豢赡嬉蛩卦斐蓳p壞時(shí)，可以利用其他服務(wù)器上的Eureka server 正常運(yùn)行，減輕運(yùn)維的壓力。每個(gè)服務(wù)和客戶端都有Eureka client，服務(wù)端的client在server 中注冊(cè)后，需要和server 保持“心跳”，即在規(guī)定時(shí)間內(nèi)確認(rèn)該服務(wù)正常運(yùn)行的狀態(tài)，否則該服務(wù)會(huì)被移除。客戶端的client 通過(guò)網(wǎng)關(guān)訪問(wèn)server，找到所需服務(wù)的接口，進(jìn)行訪問(wèn)。

（2）服務(wù)容錯(cuò)。在服務(wù)容錯(cuò)這一部分，采用的是Spring Cloud 提供的Hystrix 組件和鏈路追蹤的組件。微服務(wù)相比之前的單體應(yīng)用，最大的優(yōu)勢(shì)在于當(dāng)一個(gè)微服務(wù)出現(xiàn)調(diào)用異常時(shí)，可以及時(shí)地關(guān)閉當(dāng)前出現(xiàn)異常的微服務(wù)，避免影響其余可以正常運(yùn)行的微服務(wù)。利用Hystrix 組件，當(dāng)一個(gè)微服務(wù)出現(xiàn)一定次數(shù)的異常請(qǐng)求的時(shí)候，開(kāi)啟繼電器、關(guān)停當(dāng)前服務(wù)。在這里，對(duì)于時(shí)效性要求不高的服務(wù)請(qǐng)求，將從緩存中拿出數(shù)據(jù)，返回用戶，使得用戶擁有更好的用戶體驗(yàn)，之后等待一段時(shí)間后繼電器進(jìn)入半開(kāi)啟狀態(tài)，嘗試再次調(diào)用該服務(wù)，如果該服務(wù)可以正常調(diào)用，繼電器關(guān)閉，否則繼電器開(kāi)啟，繼續(xù)停用當(dāng)前服務(wù)；利用輔助鏈路追蹤的組件，當(dāng)服務(wù)調(diào)用失敗時(shí)，結(jié)合微服務(wù)的調(diào)用關(guān)系，快速確定出現(xiàn)問(wèn)題的微服務(wù)。

（3）服務(wù)配置。在制造技術(shù)資源云平臺(tái)中的服務(wù)眾多，每個(gè)服務(wù)的配置也不盡相同，并且在后續(xù)的維護(hù)過(guò)程中也會(huì)繼續(xù)擴(kuò)容、增加更多的微服務(wù)，而Spring Cloud 提供的Spring Cloud Config 組件可以統(tǒng)一管理每個(gè)微服務(wù)的配置信息［12］。

4.2.2 引擎及工具研發(fā)

圍繞技術(shù)資源服務(wù)平臺(tái)的構(gòu)建，根據(jù)微服務(wù)架構(gòu)的要求，本研究研發(fā)一系列公共套件、管控套件和運(yùn)營(yíng)管理套件，包括展現(xiàn)框架、可視化界面、消息隊(duì)列、數(shù)據(jù)緩存、系統(tǒng)日志等引擎以及服務(wù)注冊(cè)發(fā)現(xiàn)、統(tǒng)一數(shù)據(jù)訪問(wèn)、第三方服務(wù)管控等工具，通過(guò)這些構(gòu)件支撐微服務(wù)底層架構(gòu)穩(wěn)定運(yùn)行。

4.3 接口訪問(wèn)層設(shè)計(jì)

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

服務(wù)網(wǎng)關(guān)負(fù)責(zé)接收客戶端請(qǐng)求，并將請(qǐng)求轉(zhuǎn)發(fā)到業(yè)務(wù)層上去。服務(wù)網(wǎng)關(guān)的核心功能就是負(fù)責(zé)服務(wù)請(qǐng)求路由、組合及協(xié)議轉(zhuǎn)換［13］。首先，所有的客戶端請(qǐng)求都會(huì)經(jīng)過(guò)服務(wù)網(wǎng)關(guān)，然后服務(wù)網(wǎng)關(guān)再將服務(wù)請(qǐng)求路由到合適的微服務(wù)，以提供具體的服務(wù)處理，所以服務(wù)網(wǎng)關(guān)通常會(huì)通過(guò)編排多個(gè)微服務(wù)來(lái)處理一個(gè)服務(wù)請(qǐng)求。

4.3.2 請(qǐng)求處理過(guò)濾

服務(wù)網(wǎng)關(guān)作為整個(gè)系統(tǒng)與外界的門(mén)戶，負(fù)責(zé)外界對(duì)系統(tǒng)請(qǐng)求處理過(guò)程進(jìn)行過(guò)濾，主要實(shí)現(xiàn)了安全訪問(wèn)控制、監(jiān)控限流和自適應(yīng)路由等功能［14］。通過(guò)Spring Security 框架從接口層面實(shí)現(xiàn)權(quán)限管理的功能，當(dāng)某一用戶訪問(wèn)無(wú)權(quán)限的服務(wù)時(shí)，返回錯(cuò)誤信息，提示用戶無(wú)權(quán)訪問(wèn)；當(dāng)某一個(gè)接口在短時(shí)間內(nèi)訪問(wèn)量過(guò)大時(shí)，進(jìn)入等待隊(duì)列等待，直至該接口空閑可用時(shí)再進(jìn)行訪問(wèn)。

4.3.3 負(fù)載均衡

負(fù)載均衡模塊是通過(guò)Spring Cloud 框架中的Zuul網(wǎng)關(guān)組件和Ribbon 微服務(wù)組件并結(jié)合Eureka Server實(shí)現(xiàn)。Zuul 網(wǎng)關(guān)可以實(shí)現(xiàn)外部和內(nèi)部隔離，并保證后臺(tái)服務(wù)的安全性［15］；同時(shí)，識(shí)別用戶的訪問(wèn)權(quán)限，過(guò)濾不符合要求的請(qǐng)求。在用戶訪問(wèn)量過(guò)大的時(shí)候，也可以采用令牌環(huán)的策略對(duì)接口限流，因?yàn)樗械恼?qǐng)求都需要通過(guò)API Gateway，所以API Gateway 通常有著較高的負(fù)載。Ribbon 組件可以實(shí)現(xiàn)負(fù)載均衡的功能。如圖2 所示，客戶端通過(guò)http 請(qǐng)求的方式,訪問(wèn)微服務(wù)網(wǎng)關(guān)，Zuul 網(wǎng)關(guān)對(duì)來(lái)自客戶端的請(qǐng)求進(jìn)行過(guò)濾和轉(zhuǎn)發(fā)以及限流，防止短時(shí)間內(nèi)過(guò)多的http請(qǐng)求導(dǎo)致系統(tǒng)阻塞；Ribbon 組件則選取負(fù)載量相對(duì)較低的服務(wù)進(jìn)行組合，響應(yīng)用戶請(qǐng)求。

圖2 微服務(wù)系統(tǒng)中服務(wù)注冊(cè)與發(fā)現(xiàn)模塊結(jié)構(gòu)

4.4 接口訪問(wèn)層設(shè)計(jì)

針對(duì)技術(shù)資源服務(wù)平臺(tái)動(dòng)態(tài)擴(kuò)展、資源利用方式不斷衍生的需求，研究應(yīng)用服務(wù)（APP）動(dòng)態(tài)構(gòu)建技術(shù)，包括應(yīng)用服務(wù)功能規(guī)劃、人機(jī)交互接口定義、技術(shù)資源動(dòng)態(tài)抽取、功能模塊動(dòng)態(tài)封裝、基于服務(wù)平臺(tái)的動(dòng)態(tài)部署等，通過(guò)應(yīng)用服務(wù)動(dòng)態(tài)構(gòu)建技術(shù)實(shí)現(xiàn)技術(shù)，不斷擴(kuò)展平臺(tái)的功能，并支撐技術(shù)資源利用生態(tài)體系的形成。

圖3 技術(shù)資源生態(tài)體系

5 結(jié)論

本研究主要針對(duì)制造技術(shù)資源與服務(wù)，運(yùn)用虛擬化技術(shù)異構(gòu)各類資源池，探索使用微服務(wù)技術(shù)將龐大復(fù)雜的資源與服務(wù)進(jìn)行拆解，并利用Spring Cloud 中所提供的組件及一系列包括消息隊(duì)列、數(shù)據(jù)緩存的中間件進(jìn)行有效管理，使云平臺(tái)的開(kāi)發(fā)和運(yùn)維到達(dá)標(biāo)準(zhǔn)化、模塊化、組件化的目的，并利用Docker 技術(shù)實(shí)現(xiàn)對(duì)不同系統(tǒng)下的資源服務(wù)打包、移植，為應(yīng)用創(chuàng)建輕量化、秒級(jí)部署、彈性伸縮的容器，實(shí)現(xiàn)最終敏捷開(kāi)發(fā)的目的。最終通過(guò)應(yīng)用APP 動(dòng)態(tài)構(gòu)建技術(shù)，為制造企業(yè)和相關(guān)教育機(jī)構(gòu)提供統(tǒng)一的接口，實(shí)現(xiàn)各類資源的調(diào)用。

當(dāng)前，我國(guó)提出了實(shí)施制造強(qiáng)國(guó)發(fā)展戰(zhàn)略，制造業(yè)處于高速發(fā)展的階段，但是在資源管理方面往往存在管理人員復(fù)雜、管理方式混亂、自動(dòng)化程度低的問(wèn)題，而通過(guò)微服務(wù)及容器化技術(shù)對(duì)傳統(tǒng)單體資源管理系統(tǒng)的改造，可以在很大程度上解決這一問(wèn)題。