基于Spring Cloud的任務調度微服務化的設計與實現

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

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

1 引言

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

2 Spring Cloud微服務框架

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

2.1 網關層

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

2.2 配置中心

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

2.3 Feign組件

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

3 任務設計整體思想

3.1 任務核心處理層

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

3.2 任務調度中心

本文采用制定分布式任務列表區分待處理任務及已處理任務，并按照任務列表的任務順序將待處理任務轉發到不同的功能模塊中進行任務處理，同時使用系統的注冊中心的編譯功能，通過修改源代碼重新運行腳本，從而完善功能模塊的運行體系。在功能模塊中，服務器針對任務需求采用不同的方式對任務進行處理，以滿足用戶多種多樣的請求需求，并在任務處理結束后將完成的任務信息傳輸到核心處理層，由核心處理層進行反饋匯總，并在分布式任務列表中及時更新當前任務的處理狀態，避免任務的重復多次處理。

4 任務處理

4.1 任務生成器

任務生成器由任務拆開和任務狀態解析兩部分組成。

4.1.1 任務拆開

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

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

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

4.1.2 任務狀態解析

任務狀態可區分如下幾類。

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

（2）處理中狀態。當處理任務在任務分配器調配性離開數據庫時，核心處理器默認該任務狀態為處理狀態，處于該狀態下的任務不可進行任務分配。

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

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

4.2 任務分配器

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

4.2.1 可執行任務獲取

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

4.2.2 可處理任務分發執行

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

4.3 任務監視器

任務監視器包含僵尸任務獲取、僵尸任務處理兩部分。

4.3.1 僵尸任務獲取

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

4.3.2 僵尸任務處理

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

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

5 結語

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