薛皓辰，柳先輝

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

1 問題提出

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

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

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

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

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

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

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

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

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

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

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

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

2.3 Docker 基本概念

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

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

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

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

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

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

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

3 總體架構(gòu)

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

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

4 平臺設(shè)計(jì)

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

針對技術(shù)資源分布分散、服務(wù)能力具有差異性、資源信息平臺間缺乏共享渠道等問題，研究以數(shù)據(jù)抽象、數(shù)據(jù)映射、知識表示等為關(guān)鍵內(nèi)容的，基于本體的技術(shù)資源與服務(wù)能力虛擬化技術(shù)，實(shí)現(xiàn)對技術(shù)資源與服務(wù)能力的高效組織和管理，為技術(shù)資源以及服務(wù)能力的查詢、管理、選擇、聚合等提供支持，將現(xiàn)實(shí)生活中的多種資源，例如技術(shù)成果、技術(shù)方案、專利信息等，通過技術(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á)到敏捷開發(fā)和部署的效果，最終能更快地響應(yīng)服務(wù)動態(tài)組織的調(diào)用。針對微服務(wù)化后帶來的功能分散、資源消耗嚴(yán)重以及運(yùn)維困難的問題，采用容器化技術(shù)對微服務(wù)進(jìn)行編排管理，根據(jù)每個容器上部署微服務(wù)的不同進(jìn)行資源的合理分配，最大化地利用服務(wù)器資源實(shí)現(xiàn)對微服務(wù)應(yīng)用調(diào)度、資源管理、服務(wù)管理等多維度的統(tǒng)一管理，極大減少運(yùn)維成本，達(dá)到統(tǒng)一功能的效果。主要采用Spring Cloud 微服務(wù)框架體系中的各個組件來實(shí)現(xiàn)微服務(wù)集群，具體包括：

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

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

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

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

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

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

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

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

4.3.2 請求處理過濾

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

4.3.3 負(fù)載均衡

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

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

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

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

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

5 結(jié)論

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

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