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

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

1 引言

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

2 Spring Cloud微服務框架

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

2.1 網(wǎng)關層

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

2.2 配置中心

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

2.3 Feign組件

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

3 任務設計整體思想

3.1 任務核心處理層

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

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

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

4 任務處理

4.1 任務生成器

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

4.1.1 任務拆開

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

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

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

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

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

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

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

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

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

4.2 任務分配器

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

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

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

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

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

4.3 任務監(jiān)視器

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

4.3.1 僵尸任務獲取

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

4.3.2 僵尸任務處理

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

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

5 結(jié)語

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