何毅平，吳元杰，陳 庚，朱曉慶

（長江工程職業(yè)技術(shù)學院 湖北 武漢 430212）

1 引言

互聯(lián)網(wǎng)技術(shù)的快速發(fā)展促進了數(shù)字化生活的改革，微服務(wù)作為常見的網(wǎng)絡(luò)架構(gòu)設(shè)計風格逐漸成為網(wǎng)絡(luò)架構(gòu)的設(shè)計主流，其所受到的關(guān)注熱度也逐漸上升。微服務(wù)的優(yōu)勢是能夠解決復(fù)雜的任務(wù)分配、處理等問題，傳統(tǒng)的網(wǎng)絡(luò)架構(gòu)采用多種任務(wù)集中處理的方式，不僅處理效率低且誤差率較高。而微服務(wù)能夠?qū)⒁粋€完整的系統(tǒng)分為多個功能模塊，開發(fā)人員可以對某一模塊進行單獨編譯，且不影響其他模塊的運行，即可以自由選擇設(shè)計技術(shù)，在滿足API標準的情況下對單個服務(wù)進行獨立調(diào)整，但在調(diào)整過程中要重視網(wǎng)絡(luò)協(xié)議，并采用相應(yīng)的溝通渠道進行，實現(xiàn)多個功能模塊之間的數(shù)據(jù)交流問題，本文所研究的基于Spring Cloud實現(xiàn)任務(wù)調(diào)度微服務(wù)化使用調(diào)度機制，把多個微服務(wù)的功能進行串聯(lián)，實現(xiàn)整個程序的聯(lián)動，從而提高整體性能[1]。

2 Spring Cloud微服務(wù)框架

應(yīng)用微服務(wù)進行網(wǎng)絡(luò)架構(gòu)設(shè)計的目的是將一個完整的系統(tǒng)拆分成多個可獨立運行的功能模塊，模塊間相互協(xié)作共同實現(xiàn)系統(tǒng)運行，每個功能模塊遵照對應(yīng)的網(wǎng)絡(luò)協(xié)議進行工作，且為便于模塊間的信息交流，通常采用HTTP 的 Restful API進行模塊交流及數(shù)據(jù)共享。

2.1 網(wǎng)關(guān)層

網(wǎng)關(guān)層外部系統(tǒng)請求的接收端口，且是唯一的一個接受端口，用來接收來自第三方應(yīng)用端口的客戶請求的同時，封閉系統(tǒng)運行體系，有利于提升系統(tǒng)安全性。在識別正確的客戶請求后，通過HTTP的Restful API將任務(wù)請求傳輸?shù)胶诵奶幚韺樱覟檫M一步提升任務(wù)處理的安全性，采用請求加密措施，即對用戶的請求內(nèi)容進行隱藏，避免在請求傳輸過程中發(fā)生信息泄露[2]。除此之外，網(wǎng)管層還具有身份識別、負載考察等功能，用戶必須輸入正確的身心信息才能獲取請求響應(yīng)，且為保證系統(tǒng)運行的穩(wěn)定性，網(wǎng)管層能夠控制系統(tǒng)負載，當請求人數(shù)超過規(guī)定數(shù)量時，會給予用戶“稍后嘗試”的建議。

2.2 配置中心

配置中心是網(wǎng)絡(luò)架構(gòu)層次總所有服務(wù)器的核心配置平臺，配置中心通過獲取各個服務(wù)器的實際服務(wù)信息，根據(jù)其運行需求，計算出適合該服務(wù)器的運行參數(shù)，并將運行參數(shù)以特殊格式存儲在數(shù)據(jù)庫中，標注配置參數(shù)更新日期，計算出的參數(shù)要求能夠保證服務(wù)器穩(wěn)定、安全運行的同時，提升業(yè)務(wù)處理效率。本文設(shè)計的基于Spring Cloud實現(xiàn)任務(wù)調(diào)度微服務(wù)化應(yīng)用Spring Cloud Config作為配置中心，實現(xiàn)對系統(tǒng)服務(wù)器的統(tǒng)一配置。

2.3 Feign組件

本文應(yīng)用Feign組件實現(xiàn)Spring Cloud微服務(wù)框架模塊之間的調(diào)用，在各個模塊的控制層設(shè)計接口，關(guān)聯(lián)Feign的路由配置信息和控制層的路由，路由就可以獲取所調(diào)用的控制層的控制方法[3]。

3 任務(wù)設(shè)計整體思想

3.1 任務(wù)核心處理層

任務(wù)設(shè)計的整體思想如下，用戶經(jīng)過第三方應(yīng)用的身份識別后，通過第三方應(yīng)用端口請求輸入欄輸入任務(wù)請求，請求從外部觸發(fā)后，經(jīng)過網(wǎng)關(guān)層的請求接入轉(zhuǎn)發(fā)到核心處理層，由核心處理層對請求內(nèi)容進行解析，并根據(jù)請求類型進行分類，根據(jù)每一類的請求內(nèi)容進行任務(wù)生成和分解，通過功能模塊間的傳輸通道，將生成的任務(wù)傳輸至各大功能模塊中進行任務(wù)處理，最后集成功能模塊的處理結(jié)果通過網(wǎng)關(guān)層反饋給用戶。

3.2 任務(wù)調(diào)度中心

本文采用制定分布式任務(wù)列表區(qū)分待處理任務(wù)及已處理任務(wù)，并按照任務(wù)列表的任務(wù)順序?qū)⒋幚砣蝿?wù)轉(zhuǎn)發(fā)到不同的功能模塊中進行任務(wù)處理，同時使用系統(tǒng)的注冊中心的編譯功能，通過修改源代碼重新運行腳本，從而完善功能模塊的運行體系。在功能模塊中，服務(wù)器針對任務(wù)需求采用不同的方式對任務(wù)進行處理，以滿足用戶多種多樣的請求需求，并在任務(wù)處理結(jié)束后將完成的任務(wù)信息傳輸?shù)胶诵奶幚韺樱珊诵奶幚韺舆M行反饋匯總，并在分布式任務(wù)列表中及時更新當前任務(wù)的處理狀態(tài)，避免任務(wù)的重復(fù)多次處理。

4 任務(wù)處理

4.1 任務(wù)生成器

任務(wù)生成器由任務(wù)拆開和任務(wù)狀態(tài)解析兩部分組成。

4.1.1 任務(wù)拆開

任務(wù)拆分集中在核心處理層進行處理，針對復(fù)雜的任務(wù)類型，采用任務(wù)拆分的方式進行任務(wù)生成，若該任務(wù)涉及一個功能模塊，則系統(tǒng)默認為單一任務(wù)，單一任務(wù)不需進行任務(wù)拆分。若該任務(wù)需要多個功能模塊進行處理，則系統(tǒng)根據(jù)所需應(yīng)用的模塊數(shù)量拆分任務(wù)。

（1）只能拆成一個任務(wù)。一個功能模塊就能完成對任務(wù)的處理工作，不需進行任務(wù)匯總工作，可直接將任務(wù)處理結(jié)果反饋給用戶。

（2）可拆分成多個任務(wù)。根據(jù)核心處理層對不同用戶提出的個性化請求的分析，針對分析結(jié)果考慮該請求處理所需應(yīng)用的功能模塊，根據(jù)模塊數(shù)量生成多個任務(wù)，并將任務(wù)分配到對應(yīng)的功能模塊中，在分配時，要注意不同任務(wù)量的大小，按照處理原則，首先分配任務(wù)量大的任務(wù)，便于節(jié)省匯總時間，最后通過各個模塊反饋的任務(wù)處理結(jié)果，對該結(jié)果進行匯集和精煉，反饋給用戶。

4.1.2 任務(wù)狀態(tài)解析

任務(wù)狀態(tài)可區(qū)分如下幾類。

（1）待處理狀態(tài)。當用戶的請求提交到網(wǎng)管層，首先會經(jīng)過核心處理層的請求分析，根據(jù)不同用戶提出的個性化問題，要針對這些問題形成不同種類的任務(wù)，生成單一任務(wù)或多個任務(wù)，并將任務(wù)按照先后順序生成分布式任務(wù)列表，表明任務(wù)狀態(tài)，并將待處理任務(wù)存儲在對應(yīng)數(shù)據(jù)庫中。產(chǎn)生一條或者多條任務(wù)，對任務(wù)進行入庫處理，這時的任務(wù)狀態(tài)是初始狀態(tài)。

（2）處理中狀態(tài)。當處理任務(wù)在任務(wù)分配器調(diào)配性離開數(shù)據(jù)庫時，核心處理器默認該任務(wù)狀態(tài)為處理狀態(tài)，處于該狀態(tài)下的任務(wù)不可進行任務(wù)分配。

（3）完結(jié)狀態(tài)。任務(wù)分配器根據(jù)分布式任務(wù)列表將任務(wù)按照先后順序分配到不同的功能以后，各個功能模塊再把自己處理任務(wù)的結(jié)果反饋給核心處理層，當核心處理層完成處理結(jié)果匯總后，標記該狀態(tài)為完結(jié)狀態(tài)。

（4）失敗狀態(tài)。各個功能將自己的處理結(jié)果反饋給核心處理器，若核心處理器無法識別或識別錯位，則標記該任務(wù)為失敗狀態(tài)。

4.2 任務(wù)分配器

任務(wù)分配器主要由可執(zhí)行任務(wù)獲取和可執(zhí)行任務(wù)分配執(zhí)行兩部分組成。

4.2.1 可執(zhí)行任務(wù)獲取

對于沒有開始處理（即任務(wù)狀態(tài)為待處理狀態(tài)）的任務(wù)，要觸發(fā)任務(wù)定時器對任務(wù)分配請求進行統(tǒng)一處理，得到待執(zhí)行標簽的任務(wù)這時候就可以轉(zhuǎn)到功能模塊中去，然后再由功能根據(jù)任務(wù)類型進行模塊區(qū)分處理。要注意的是，在執(zhí)行不同類型的任務(wù)時，需要考慮到它們彼此之間是否有關(guān)聯(lián)，要根據(jù)它們之間的關(guān)系來對執(zhí)行順序進行排序，并且把相關(guān)聯(lián)的任務(wù)進行入庫處理，方便以后的操作。有關(guān)聯(lián)關(guān)系的任務(wù)在進行分配之前需要進行檢驗，驗證它的前置條件是否符合標準，如果前置標準全部符合，就可以進行下一步，以任務(wù)C和任務(wù)D為例，在執(zhí)行任務(wù)D之前必須要保證已經(jīng)執(zhí)行完任務(wù)C了，任務(wù)之間存在關(guān)聯(lián)關(guān)系，在獲取任務(wù)時，只有任務(wù)C完成了才能獲得任務(wù)D。

4.2.2 可處理任務(wù)分發(fā)執(zhí)行

在可處理任務(wù)離開其所在數(shù)據(jù)庫之后，系統(tǒng)默認把任務(wù)的狀態(tài)設(shè)置為處理中狀態(tài)，以任務(wù)類型為依據(jù)把任務(wù)分發(fā)到不同的模塊功能進行處理，任務(wù)之間的交互使用Feign，服務(wù)F、服務(wù)G、服務(wù)H都處理著不同類型的任務(wù)，當用戶的請求設(shè)計新功能模塊時，開發(fā)者需要對網(wǎng)絡(luò)結(jié)構(gòu)進行重新規(guī)劃，在功能模塊層增加一個新類型功能模塊，且在開發(fā)過程中，不影響其他層次的運行。任務(wù)下發(fā)到任務(wù)處理模塊之后，如果出現(xiàn)異常情況、執(zhí)行成功、執(zhí)行失敗都需要給核心處理層進行一個反饋，若核心處理層無法判斷任務(wù)的處理狀態(tài)，默認該任務(wù)為僵尸任務(wù)，也就是沒有任何處理結(jié)果，需要專業(yè)的系統(tǒng)進行處理。

4.3 任務(wù)監(jiān)視器

任務(wù)監(jiān)視器包含僵尸任務(wù)獲取、僵尸任務(wù)處理兩部分。

4.3.1 僵尸任務(wù)獲取

僵尸任務(wù)獲取的第一步是判斷該任務(wù)是否為僵尸任務(wù)。當一個任務(wù)長時間處于處理中狀態(tài)的時候，且處理時間遠遠超過預(yù)期處理時間，則說明當前任務(wù)已經(jīng)處于僵尸狀態(tài)，處于僵尸狀態(tài)下的任務(wù)無法完成任務(wù)處理工作，也無法將自身狀態(tài)反饋給任務(wù)核心處理層，如果不對僵尸任務(wù)進行單獨處理，僵尸任務(wù)會永遠停留在功能模塊的處理區(qū)內(nèi)，不僅占用處理位置，降低了功能模塊的處理效率，且易造成系統(tǒng)堵塞，使系統(tǒng)運行紊亂。獲取僵尸任務(wù)方式為利用處理時間進行任務(wù)劃分，針對任務(wù)大小，設(shè)置了相應(yīng)處理時間范圍，在任務(wù)的處理過程中，實時記錄任務(wù)的開始時間和任務(wù)處理結(jié)束時間，若處理時間超過規(guī)定范圍，則認為該任務(wù)為僵尸任務(wù)。

4.3.2 僵尸任務(wù)處理

（1）設(shè)置為初始狀態(tài)。把僵尸任務(wù)的狀態(tài)設(shè)置成待處理狀態(tài)，任務(wù)調(diào)度器通過核心控制的控制重新獲取當前任務(wù)信息，即對當前任務(wù)進行二次分發(fā)，由功能模塊對其進行二次處理。

（2）設(shè)置為失敗狀態(tài)。把僵尸任務(wù)狀態(tài)設(shè)置為失敗狀態(tài)，由核心處理層向第三方應(yīng)用端口發(fā)送請求失敗端口，提醒用戶重新發(fā)送任務(wù)請求，刪除原有失敗任務(wù)的信息，按照請求處理步驟進行重新處理。

5 結(jié)語

本文通過對Spring Cloud微服務(wù)框架進行深入研究，設(shè)計并實現(xiàn)了一種基于Spring Cloud實現(xiàn)任務(wù)調(diào)度微服務(wù)化，通過在任務(wù)核心處理層應(yīng)用Spring Cloud實現(xiàn)的微服務(wù)任務(wù)分析和分配機制，集成配置中心對功能模塊進行參數(shù)配置，應(yīng)用聲明式Web服務(wù)客戶端Feign，實現(xiàn)了用戶請求的一系列處理功能。但在實際設(shè)計中，在核心處理層的控制下，協(xié)調(diào)任務(wù)分配器和功能模塊，維護Spring Cloud微服務(wù)框架與第三方用戶網(wǎng)端的溝通協(xié)議，打破了傳統(tǒng)集中式任務(wù)處理模式，提升了任務(wù)處理效率的同時，促進了Spring Cloud微服務(wù)的進一步發(fā)展，為其他任務(wù)處理系統(tǒng)的構(gòu)建提供了借鑒。