基于微服務(wù)架構(gòu)FPGA 云平臺(tái)的并發(fā)請(qǐng)求調(diào)度機(jī)制

奚智雯，蔡晶晶，陽文敏，柴志雷，3

（1.江南大學(xué) 人工智能與計(jì)算機(jī)學(xué)院，江蘇 無錫 214122；2.江蘇虎甲蟲計(jì)算技術(shù)有限公司，江蘇 無錫 214000；3.江蘇省模式識(shí)別與計(jì)算智能工程實(shí)驗(yàn)室，江蘇無錫 214122）

0 概述

現(xiàn)場(chǎng)可編程門陣列（Field Programmable Gate Array，F(xiàn)PGA）是一種可由用戶定義其硬件架構(gòu)的“空白芯片”，廣泛應(yīng)用于專用硬件設(shè)計(jì)、芯片驗(yàn)證等領(lǐng)域，并在計(jì)算機(jī)組成原理、集成電路設(shè)計(jì)等課程實(shí)驗(yàn)中大量使用［1-2］。但是，傳統(tǒng)基于FPGA 的實(shí)驗(yàn)通常依賴于專用設(shè)備，需要人員在指定時(shí)間到指定地點(diǎn)完成，影響了實(shí)驗(yàn)教學(xué)和系統(tǒng)開發(fā)的效率。隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，出現(xiàn)了不同類型的FPGA 云平臺(tái)，從而推動(dòng)了FPGA 相關(guān)技術(shù)在更大范圍內(nèi)的應(yīng)用［3-5］，F(xiàn)PGA云平臺(tái)的系統(tǒng)架構(gòu)也由耦合度較高、靈活性較差、開發(fā)運(yùn)維成本較高的單體架構(gòu)逐漸向松耦合、可伸縮、易部署的微服務(wù)架構(gòu)轉(zhuǎn)變［6］。微服務(wù)最初由FOWLER等［7］定義，其是對(duì)傳統(tǒng)單體架構(gòu)的解耦，將功能拆分成多個(gè)不同的服務(wù)，便于設(shè)計(jì)、開發(fā)以及運(yùn)維部署。隨著用戶請(qǐng)求量的激增，F(xiàn)PGA 云平臺(tái)面臨高并發(fā)請(qǐng)求的應(yīng)用場(chǎng)景。單體架構(gòu)的調(diào)用請(qǐng)求都在本地，因此，其網(wǎng)絡(luò)延遲較低，但在，在高并發(fā)請(qǐng)求下，微服務(wù)架構(gòu)的調(diào)用可以同時(shí)進(jìn)行且不相互依賴，總執(zhí)行時(shí)間也較短，相較單體架構(gòu)性能顯著提高［8］。

目前，許多學(xué)者對(duì)微服務(wù)架構(gòu)的云平臺(tái)并發(fā)請(qǐng)求進(jìn)行了相關(guān)研究，這些研究主要分為2 個(gè)方面。一方面?zhèn)戎赜诒ＷC服務(wù)質(zhì)量（Quality of Service，QoS）［9］，例如：SHETTY等［10］提出一種具有服務(wù)分組的云服務(wù)選擇機(jī)制，基于改進(jìn)的層次分析法（Analytic Hierarchy Process，AHP）分組選擇算法來提高性能，但其僅適用于共享服務(wù)調(diào)度系統(tǒng)；MENGYU等［11］提出一種支持并發(fā)請(qǐng)求的物聯(lián)網(wǎng)服務(wù)組合優(yōu)化節(jié)能機(jī)制，該機(jī)制可以提高物聯(lián)網(wǎng)服務(wù)在并發(fā)請(qǐng)求間的可共享性，但其受限于不同服務(wù)之間的粒度影響；郭軍等［12］為提高整體的QoS，提出一種主動(dòng)式突發(fā)并發(fā)量應(yīng)對(duì)策略GMAC，該策略能預(yù)測(cè)用戶并發(fā)量，但其并未進(jìn)一步給出突發(fā)并發(fā)量的應(yīng)對(duì)策略。另一方面從負(fù)載均衡入手進(jìn)行研究，例如：AMAL等［13］為保證資源的有效使用，提出一種負(fù)載均衡算法，該算法對(duì)并發(fā)請(qǐng)求用戶進(jìn)行優(yōu)先級(jí)排序；LIU等［14］通過確定綜合負(fù)載值以衡量資源的利用率，但是其未在真實(shí)系統(tǒng)中處理并發(fā)請(qǐng)求；ZHOU等［15］提出一種基于微服務(wù)邊緣計(jì)算的負(fù)載建模方法，該方法能夠優(yōu)化資源配置和調(diào)度，但是其并不通用，局限于特定類型的應(yīng)用。

上述研究中的相關(guān)算法通過減少服務(wù)選擇的計(jì)算時(shí)間和重復(fù)的存儲(chǔ)庫訪問來提高并發(fā)性能，但僅適用于多服務(wù)共享調(diào)度系統(tǒng)，而FPGA 云平臺(tái)是基于單服務(wù)的調(diào)度系統(tǒng)，無需進(jìn)行服務(wù)選擇。因此，上述算法并不適用于處理FPGA 云平臺(tái)的并發(fā)請(qǐng)求問題。

本文基于單服務(wù)調(diào)度系統(tǒng)下的FPGA 云平臺(tái)，建立一種自定義參數(shù)響應(yīng)指數(shù)計(jì)算模型，用于計(jì)算高并發(fā)請(qǐng)求下每個(gè)用戶對(duì)應(yīng)的響應(yīng)指數(shù)，并基于該模型設(shè)計(jì)一種高并發(fā)請(qǐng)求調(diào)度（HCRS）算法。在真實(shí)運(yùn)營(yíng)的FPGA 云平臺(tái)中使用用戶數(shù)據(jù)進(jìn)行測(cè)試，以驗(yàn)證該算法的平均響應(yīng)延時(shí)、系統(tǒng)吞吐量等性能。

1 基于微服務(wù)架構(gòu)的FPGA 云平臺(tái)

微服務(wù)架構(gòu)按照業(yè)務(wù)邊界進(jìn)行細(xì)粒度的拆分以及部署，其將一個(gè)大型且復(fù)雜化的單體架構(gòu)應(yīng)用拆分出多個(gè)松耦合的微服務(wù)［16］。因此，本文在設(shè)計(jì)FPGA云平臺(tái)時(shí)根據(jù)實(shí)際業(yè)務(wù)需求從單體架構(gòu)模式下的平臺(tái)上拆分出節(jié)點(diǎn)資源管理這一核心功能，并將其作為一個(gè)獨(dú)立的微服務(wù)，它的特點(diǎn)是能夠隨時(shí)擁有整個(gè)集群的使用狀況，并且能以全局視角選擇合適的節(jié)點(diǎn)進(jìn)行任務(wù)分配。微服務(wù)通過輕量級(jí)通信框架REST（Representational State Transfer）與外界進(jìn)行通信［17］，同時(shí)支持通過不同技術(shù)或平臺(tái)來實(shí)現(xiàn)。

1.1 FPGA 云平臺(tái)架構(gòu)

FPGA 云平臺(tái)主要由Web 應(yīng)用層以及節(jié)點(diǎn)資源管理微服務(wù)組成，其系統(tǒng)架構(gòu)及關(guān)鍵組件如圖1 所示，終端用戶可以在不同設(shè)備上使用網(wǎng)絡(luò)瀏覽器訪問FPGA 云平臺(tái)、在云平臺(tái)上申請(qǐng)使用節(jié)點(diǎn)、檢查FPGA 硬件節(jié)點(diǎn)實(shí)時(shí)執(zhí)行狀態(tài)等。

圖1 FPGA 云平臺(tái)系統(tǒng)架構(gòu)Fig.1 FPGA cloud platform system architecture

Web 應(yīng)用層含有心跳機(jī)制［18］，該心跳機(jī)制用于檢查用戶申請(qǐng)到的節(jié)點(diǎn)是否長(zhǎng)時(shí)間處于未使用狀態(tài)，若用戶在一段時(shí)間內(nèi)未發(fā)送心跳包，則自動(dòng)釋放節(jié)點(diǎn)，未使用的這段時(shí)間即為用戶空置時(shí)間。節(jié)點(diǎn)資源管理微服務(wù)主要負(fù)責(zé)管理節(jié)點(diǎn)的狀態(tài)。上述兩者均使用ELK（Elasticsearch，Logstash，Kibana）［19］日志平臺(tái)進(jìn)行日志采集與分析，并通過RESTful API 進(jìn)行通信，客戶端發(fā)起請(qǐng)求經(jīng)過反向代理服務(wù)器（Nginx）處理，對(duì)微服務(wù)接口添加JWT（Json Web Token）訪問認(rèn)證機(jī)制，以保證接口的安全性，并對(duì)節(jié)點(diǎn)使用界面Jupyter notebook 配置安全策略，保障硬件節(jié)點(diǎn)使用安全。數(shù)據(jù)存儲(chǔ)層則使用關(guān)系型數(shù)據(jù)庫Mysql 以及非關(guān)系型數(shù)據(jù)庫Redis。

1.2 節(jié)點(diǎn)資源管理微服務(wù)

節(jié)點(diǎn)資源管理微服務(wù)包含6 個(gè)主要功能，分別為服務(wù)注冊(cè)發(fā)現(xiàn)、節(jié)點(diǎn)申請(qǐng)、節(jié)點(diǎn)釋放、節(jié)點(diǎn)實(shí)時(shí)狀態(tài)查詢、節(jié)點(diǎn)系統(tǒng)重置、節(jié)點(diǎn)定時(shí)測(cè)試。微服務(wù)架構(gòu)如圖2 所示，底層采用Python 編寫的Web 應(yīng)用框架Tornado（Tornado Web Server），控制層為RM Server節(jié)點(diǎn)狀態(tài)控制器。微服務(wù)為節(jié)點(diǎn)定義了6 種狀態(tài)，分別為Boo（t初始態(tài)）、Testing（測(cè)試態(tài)）、Valid（可用態(tài)）、Busy（占用態(tài)）、Resetting（重置態(tài)）、Broken（故障態(tài)），節(jié)點(diǎn)狀態(tài)控制器的作用即為管理這6 種狀態(tài)的邏輯轉(zhuǎn)換，其中，在申請(qǐng)和釋放這2 個(gè)操作時(shí)需加入互斥鎖來解決資源同步與互斥問題。業(yè)務(wù)邏輯層為上述各個(gè)功能的具體實(shí)現(xiàn)，并對(duì)功能進(jìn)行封裝，將封裝好的服務(wù)以接口的形式，利用通信層RESTful API 與Web 應(yīng)用層進(jìn)行通信，便于Web 應(yīng)用層調(diào)用接口。

圖2 節(jié)點(diǎn)資源管理微服務(wù)架構(gòu)Fig.2 Node resource management microservice architecture

1.3 并發(fā)請(qǐng)求應(yīng)用場(chǎng)景描述

在微服務(wù)架構(gòu)下的FPGA 云平臺(tái)實(shí)際應(yīng)用場(chǎng)景中，由于FPGA 服務(wù)器硬件節(jié)點(diǎn)個(gè)數(shù)有限，當(dāng)大量用戶在同一時(shí)間并發(fā)申請(qǐng)節(jié)點(diǎn)時(shí)，請(qǐng)求響應(yīng)時(shí)間將延長(zhǎng)，此時(shí)無法滿足所有用戶的請(qǐng)求，微服務(wù)節(jié)點(diǎn)資源被占滿甚至直接導(dǎo)致微服務(wù)宕機(jī)。高并發(fā)請(qǐng)求過程如圖3 所示。

圖3 高并發(fā)請(qǐng)求過程Fig.3 High concurrent request process

2 節(jié)點(diǎn)資源管理微服務(wù)高并發(fā)請(qǐng)求調(diào)度算法

本文從節(jié)點(diǎn)資源管理微服務(wù)的高并發(fā)請(qǐng)求實(shí)際應(yīng)用場(chǎng)景出發(fā)，建立自定義參數(shù)響應(yīng)指數(shù)計(jì)算模型，確保能夠準(zhǔn)確描述每個(gè)用戶申請(qǐng)節(jié)點(diǎn)請(qǐng)求的優(yōu)先級(jí)順序。在此基礎(chǔ)上，提出一種高并發(fā)請(qǐng)求調(diào)度算法HCRS，以實(shí)現(xiàn)節(jié)點(diǎn)資源合理分配并優(yōu)化微服務(wù)質(zhì)量。

2.1 參數(shù)設(shè)置及權(quán)重確定

2.1.1 參數(shù)設(shè)置

為解決FPGA 云平臺(tái)上的用戶申請(qǐng)節(jié)點(diǎn)高并發(fā)控制問題，本文從優(yōu)先級(jí)調(diào)度入手，分析用戶申請(qǐng)操作的關(guān)鍵影響因素，將這些影響因素作為自定義參數(shù)，具體如表1 所示，其中：用戶計(jì)劃使用時(shí)間表示被申請(qǐng)節(jié)點(diǎn)預(yù)計(jì)占用時(shí)長(zhǎng)；歷史使用平均時(shí)長(zhǎng)用來評(píng)估用戶歷史使用頻率；歷史空置時(shí)間用來衡量用戶是否高效使用節(jié)點(diǎn)。

表1 自定義參數(shù)及其含義Table 1 User-defined parameters and their meanings

2.1.2 自定義參數(shù)權(quán)重確定

本文采用AHP 確定自定義參數(shù)的權(quán)重。AHP是一種定性和定量分析相結(jié)合的決策方法，具有系統(tǒng)、靈活及簡(jiǎn)潔的優(yōu)點(diǎn)。在解決實(shí)際問題時(shí)，AHP 處理問題的思路與人的決策思維較為相似。AHP 有4 種權(quán)重計(jì)算方法，而4 種計(jì)算方法得出的權(quán)重向量一般比較接近，僅有細(xì)微差別［20］，因此，本文選取其中的算術(shù)平均法來計(jì)算權(quán)重。

結(jié)合本文應(yīng)用場(chǎng)景，AHP 可以根據(jù)各個(gè)自定義參數(shù)的重要級(jí)別對(duì)其進(jìn)行排名，從而得出參數(shù)的權(quán)重大小。AHP 定義的重要程度及其對(duì)應(yīng)數(shù)值如表2 所示。

表2 參數(shù)重要程度及其對(duì)應(yīng)的數(shù)值Table 2 Parameters importance and its corresponding value

根據(jù)表2 所示的比較標(biāo)準(zhǔn)，對(duì)上述自定義的5 個(gè)參數(shù)，即用戶計(jì)劃使用時(shí)間、是否為會(huì)員、用戶計(jì)劃申請(qǐng)節(jié)點(diǎn)數(shù)量、用戶歷史使用平均時(shí)長(zhǎng)以及用戶歷史空置時(shí)間進(jìn)行比較，得出如表3 所示的判斷矩陣。根據(jù)判斷矩陣［21］計(jì)算各個(gè)參數(shù)對(duì)應(yīng)的權(quán)重，本文使用Python 實(shí)現(xiàn)AHP 分析的完整過程，首先對(duì)判斷矩陣進(jìn)行一致性檢驗(yàn)，檢驗(yàn)通過方可進(jìn)行權(quán)重計(jì)算，AHP 計(jì)算權(quán)重的算法描述具體如算法1 所示。

表3 判斷矩陣Table 3 Judgment matrix

算法1AHP 計(jì)算權(quán)重算法

2.2 模型建立

2.2.1 響應(yīng)指數(shù)函數(shù)定義

FPGA 云平臺(tái)在上線運(yùn)行過程中將面臨海量用戶的注冊(cè)登錄以及申請(qǐng)節(jié)點(diǎn)等操作，此時(shí)會(huì)產(chǎn)生響應(yīng)速度慢、響應(yīng)延時(shí)長(zhǎng)、長(zhǎng)時(shí)間申請(qǐng)不到節(jié)點(diǎn)等問題。為此，本文建立一種自定義參數(shù)響應(yīng)指數(shù)計(jì)算模型，該模型主要用于對(duì)每個(gè)用戶的申請(qǐng)輸入?yún)?shù)進(jìn)行分析計(jì)算，對(duì)應(yīng)的申請(qǐng)節(jié)點(diǎn)請(qǐng)求響應(yīng)指數(shù)計(jì)算公式如式（1）所示：

其中：y為響應(yīng)指數(shù)；W1～W5為參數(shù)對(duì)應(yīng)的權(quán)重；Xplan、Xvip、Xnodenum、Xhisavg、Xempty分別為用戶計(jì)劃使用時(shí)間、是否為會(huì)員、用戶計(jì)劃申請(qǐng)節(jié)點(diǎn)數(shù)量、用戶歷史使用平均時(shí)長(zhǎng)、用戶歷史空置時(shí)間歸一化后的值。

2.2.2 響應(yīng)指數(shù)閾值定義

本文模型模擬用戶通過Web 應(yīng)用層發(fā)起申請(qǐng)節(jié)點(diǎn)請(qǐng)求，在傳遞相應(yīng)的請(qǐng)求參數(shù)后，需要根據(jù)響應(yīng)指數(shù)閾值對(duì)所有用戶進(jìn)行區(qū)分，設(shè)置最佳的上限和下限閾值極為重要，其有助于實(shí)現(xiàn)微服務(wù)的自動(dòng)伸縮［22］。因此，本文模擬5 組不同數(shù)量的用戶并發(fā)登錄及申請(qǐng)節(jié)點(diǎn)請(qǐng)求，分別計(jì)算其響應(yīng)指數(shù)，并使用IBM SPSS Statistics 開源工具對(duì)數(shù)據(jù)進(jìn)行分析，具體閾值數(shù)據(jù)分析結(jié)果如表4 所示。5 組數(shù)據(jù)均保留小數(shù)點(diǎn)后一位，則平均響應(yīng)指數(shù)α=0.2，最低響應(yīng)指數(shù)β=0.1。

表4 閾值分析結(jié)果Table 4 Threshold analysis results

2.3 衡量指標(biāo)

在FPGA 云平臺(tái)環(huán)境中，為了進(jìn)一步分析用戶高并發(fā)申請(qǐng)節(jié)點(diǎn)時(shí)系統(tǒng)的整體性能以及用戶申請(qǐng)節(jié)點(diǎn)情況，本文引入下列參數(shù)作為衡量指標(biāo)：

1）用戶請(qǐng)求響應(yīng)時(shí)間Tu，其計(jì)算公式如式（2）所示：

其中：Tcs為用戶從客戶端向服務(wù)器端發(fā)出請(qǐng)求的時(shí)間；Ts為服務(wù)器接受請(qǐng)求并處理所需的時(shí)間；Tsc為服務(wù)器端返回?cái)?shù)據(jù)給客戶端的時(shí)間；Tc為客戶端接收響應(yīng)數(shù)據(jù)并處理所需的時(shí)間。

2）吞吐量Qt，指單位時(shí)間內(nèi)系統(tǒng)處理請(qǐng)求的數(shù)量，其計(jì)算公式如式（3）所示：

其中：Snum為樣本總數(shù)量；Tlast為最后一個(gè)線程啟動(dòng)的時(shí)間；Tlasttime為最后一個(gè)線程持續(xù)的時(shí)間；Tfirst為第一個(gè)線程啟動(dòng)的時(shí)間。

3）平均響應(yīng)延時(shí)La，其計(jì)算公式如式（4）所示：

其中：li為單個(gè)請(qǐng)求的響應(yīng)延時(shí)。

4）并發(fā)度C，其計(jì)算公式如式（5）所示，對(duì)于一個(gè)系統(tǒng)而言，平均響應(yīng)延時(shí)為每個(gè)請(qǐng)求所需的時(shí)間，吞吐量為單位時(shí)間的請(qǐng)求數(shù)量，因此，兩者相乘即為并發(fā)度。

根據(jù)上述公式可以計(jì)算得出用戶請(qǐng)求響應(yīng)時(shí)間以及微服務(wù)的并發(fā)度，從而衡量FPGA 云平臺(tái)中節(jié)點(diǎn)資源管理微服務(wù)的服務(wù)質(zhì)量。從用戶請(qǐng)求響應(yīng)時(shí)間角度分析，響應(yīng)時(shí)間越小，用戶體驗(yàn)質(zhì)量越好；從系統(tǒng)的并發(fā)度角度分析，并發(fā)度越高，系統(tǒng)性能越好［23］。

2.4 算法設(shè)計(jì)

本文在上述自定義參數(shù)響應(yīng)指數(shù)計(jì)算模型的基礎(chǔ)上，提出一種高并發(fā)請(qǐng)求調(diào)度算法HCRS，根據(jù)上述定義的閾值將用戶響應(yīng)指數(shù)劃分為直接申請(qǐng)、加入隊(duì)列等待申請(qǐng)、掛起申請(qǐng)3 種執(zhí)行類型，并以此為標(biāo)準(zhǔn)分配用戶申請(qǐng)節(jié)點(diǎn)請(qǐng)求。

本文算法的執(zhí)行流程如圖4 所示，大量用戶同時(shí)發(fā)起申請(qǐng)節(jié)點(diǎn)請(qǐng)求，輸入對(duì)應(yīng)的參數(shù)，在傳遞輸入?yún)?shù)后，模型開始計(jì)算各個(gè)用戶對(duì)應(yīng)的響應(yīng)指數(shù)，并將其大小與閾值進(jìn)行比較，從而分類處理不同用戶的請(qǐng)求。

圖4 HCRS 算法執(zhí)行流程Fig.4 HCRS algorithm execution procedure

基于自定義參數(shù)響應(yīng)指數(shù)計(jì)算模型，本文設(shè)計(jì)的高并發(fā)請(qǐng)求調(diào)度算法描述具體如下：

算法2HCRS 算法

3 實(shí)驗(yàn)結(jié)果與分析

本文將HCRS 算法應(yīng)用到真實(shí)的FPGA 云平臺(tái)上，并通過在真實(shí)應(yīng)用場(chǎng)景下模擬同一組用戶高并發(fā)登錄及申請(qǐng)節(jié)點(diǎn)請(qǐng)求，以分析評(píng)估資源分配情況以及微服務(wù)的質(zhì)量。

3.1 實(shí)驗(yàn)環(huán)境

本文部署節(jié)點(diǎn)資源管理微服務(wù)的軟件環(huán)境為CentOS Linux release 7.8.2003（Core）+GCC V4.8.5，其底層框架為Tornado5.1，F(xiàn)PGA 云平臺(tái)使用的硬件節(jié)點(diǎn)為Xilinx 公司發(fā)布的PYNQ-Z2，節(jié)點(diǎn)系統(tǒng)為PYNQ Linux，based on Ubuntu 18.04+GCC V7.3.0。Web 應(yīng)用技術(shù)棧為Spring Boot、Apache Shiro、MyBatis、Thymeleaf。數(shù)據(jù)庫采用Mysql 5.5 與Redis 3.0 相結(jié)合的方式存儲(chǔ)管理數(shù)據(jù)。

測(cè)試部分首先使用可視化測(cè)試工具Badboy 將單個(gè)登錄以及申請(qǐng)節(jié)點(diǎn)的測(cè)試腳本直接導(dǎo)出生成Apache Jmeter 腳本，然后使用Apache Jmeter，根據(jù)具體測(cè)試要求修改測(cè)試腳本，添加用戶登錄信息以及用戶計(jì)劃使用時(shí)間，即輸入?yún)?shù)進(jìn)行測(cè)試。

3.2 實(shí)驗(yàn)結(jié)果

本文算法已在真實(shí)的FPGA 云平臺(tái)OpenHEC中實(shí)現(xiàn)，模擬1 000 個(gè)用戶分別在先來先服務(wù)（FCFS）調(diào)度算法以及本文HCRS 算法下執(zhí)行登錄及申請(qǐng)節(jié)點(diǎn)請(qǐng)求，同時(shí)考慮HCRS 算法中自定義參數(shù)的輸入，為保證實(shí)驗(yàn)過程更接近真實(shí)的用戶操作，所有參數(shù)設(shè)置如下：用戶歷史平均使用時(shí)間的權(quán)重較高，對(duì)實(shí)驗(yàn)影響較大，因此，需獲取其真實(shí)數(shù)據(jù)；用戶計(jì)劃使用時(shí)間具有較大的隨機(jī)性，因此，隨機(jī)生成1 000 個(gè)用戶的計(jì)劃使用時(shí)間并存入文本文件作為測(cè)試數(shù)據(jù)；是否為會(huì)員、用戶計(jì)劃申請(qǐng)節(jié)點(diǎn)數(shù)量、用戶歷史空置時(shí)間這3 個(gè)參數(shù)均設(shè)為默認(rèn)值。默認(rèn)用戶均為普通用戶，并且一次申請(qǐng)一個(gè)節(jié)點(diǎn)使用，默認(rèn)用戶歷史空置時(shí)間為零。

在不同算法下，1 000 個(gè)用戶登錄以及申請(qǐng)節(jié)點(diǎn)的請(qǐng)求通過率為100%，請(qǐng)求響應(yīng)時(shí)間如表5 所示，其中，“99%”表示99%請(qǐng)求的響應(yīng)時(shí)間。從表5 可以看出，與FCFS 算法相比，HCRS 算法申請(qǐng)節(jié)點(diǎn)的平均響應(yīng)時(shí)間縮短了12 605 ms。

表5 用戶請(qǐng)求響應(yīng)時(shí)間對(duì)比Table 5 Comparison of user request response time ms

2 種算法在吞吐量及網(wǎng)絡(luò)接收發(fā)送數(shù)據(jù)量上的對(duì)比結(jié)果如表6 所示，從表6 可以看出，在申請(qǐng)節(jié)點(diǎn)請(qǐng)求下，HCRS 算法的吞吐量以及網(wǎng)絡(luò)收發(fā)數(shù)據(jù)量均優(yōu)于FCFS 算法。

表6 吞吐量及網(wǎng)絡(luò)收發(fā)數(shù)據(jù)量對(duì)比Table 6 Comparison of throughput and network received and sent data volume

衡量微服務(wù)質(zhì)量的另一個(gè)指標(biāo)為用戶請(qǐng)求平均響應(yīng)延時(shí)，1 000 個(gè)用戶并發(fā)請(qǐng)求執(zhí)行完畢所需總時(shí)長(zhǎng)為2 min。圖5 對(duì)比顯示了2 種算法在總時(shí)長(zhǎng)內(nèi)每隔1 min 的平均響應(yīng)延時(shí)，從圖5 可以看出，HCRS 算法的請(qǐng)求平均響應(yīng)延時(shí)略高于FCFS 算法。

圖5 2 種算法的平均響應(yīng)延時(shí)對(duì)比Fig.5 Comparison of average response delay of two algorithms

3.3 結(jié)果分析

3.3.1 用戶請(qǐng)求響應(yīng)時(shí)間分析

從3.2 節(jié)實(shí)驗(yàn)結(jié)果可以看出，HCRS 算法申請(qǐng)節(jié)點(diǎn)請(qǐng)求平均響應(yīng)時(shí)間優(yōu)于FCFS 算法。2 種算法在不同響應(yīng)時(shí)間區(qū)間內(nèi)處理請(qǐng)求個(gè)數(shù)情況如圖6 所示，從圖6 可以看出，HCRS 算法大部分請(qǐng)求響應(yīng)時(shí)間處于40～80 s 之間，少部分請(qǐng)求處于80～120 s 之間，而FCFS 算法幾乎所有請(qǐng)求的響應(yīng)時(shí)間都處于80～120 s 之間。因此，在處理用戶并發(fā)申請(qǐng)節(jié)點(diǎn)請(qǐng)求上，HCRS 算法能有效降低請(qǐng)求響應(yīng)時(shí)間。

圖6 2 種算法在不同響應(yīng)時(shí)間區(qū)間內(nèi)處理請(qǐng)求個(gè)數(shù)對(duì)比Fig.6 Comparison of the number of requests processed by the two algorithms in different response time intervals

3.3.2 系統(tǒng)吞吐量分析

從3.2 節(jié)實(shí)驗(yàn)結(jié)果可知，HCRS 算法的系統(tǒng)吞吐量較FCFS 算法更優(yōu)。從圖7 各時(shí)刻系統(tǒng)吞吐量的對(duì)比情況可知，HCRS 算法更為穩(wěn)定，前期處于上升趨勢(shì)，中期最高能實(shí)現(xiàn)每秒處理11 個(gè)請(qǐng)求，后期回落到每秒處理6 個(gè)請(qǐng)求，而FCFS 算法的系統(tǒng)吞吐量到后半程才逐漸上升，最高達(dá)到每秒處理約16 個(gè)請(qǐng)求，相比之下，使用HCRS 算法的系統(tǒng)吞吐量更為穩(wěn)定并且性能更優(yōu)。

圖7 2 種算法各時(shí)刻的系統(tǒng)吞吐量對(duì)比Fig.7 Comparison of system throughput of two algorithms at each time

3.3.3 用戶請(qǐng)求平均響應(yīng)延時(shí)分析

從3.2 節(jié)實(shí)驗(yàn)結(jié)果可知，HCRS 算法下的用戶請(qǐng)求平均響應(yīng)延時(shí)高于FCFS 算法。從完成一個(gè)完整請(qǐng)求所需時(shí)間（即響應(yīng)延時(shí)）與每秒請(qǐng)求數(shù)的關(guān)系角度分析，2 種算法的實(shí)驗(yàn)結(jié)果分別如圖8、圖9 所示。從中可以看出，并發(fā)處理用戶請(qǐng)求的數(shù)量集中在250 個(gè)請(qǐng)求以內(nèi)，對(duì)比分析這段區(qū)間內(nèi)的響應(yīng)延時(shí)，F(xiàn)CFS 算法的響應(yīng)延時(shí)多數(shù)分布在80～100 s 之間，少數(shù)分布在0～50 s 之間，最高達(dá)到128 s 左右，而HCRS算法的響應(yīng)延時(shí)多數(shù)分布在50～100 s 之間，少數(shù)分布在0～20 s 之間，最高達(dá)到95 s。因此，HCRS 算法處理請(qǐng)求的延時(shí)普遍低于FCFS 算法。

圖8 FCFS 算法平均響應(yīng)延時(shí)與每秒請(qǐng)求數(shù)的關(guān)系Fig.8 The relationship between the average response delay of FCFS algorithm and the number of requests per second

圖9 HCRS 算法平均響應(yīng)延時(shí)與每秒請(qǐng)求數(shù)的關(guān)系Fig.9 The relationship between the average response delay of HCRS algorithm and the number of requests per second

對(duì)比2 種算法每秒處理相同數(shù)量（1、2、6、185）用戶請(qǐng)求時(shí)的響應(yīng)延時(shí)，結(jié)果如表7 所示，從中可以看出，HCRS算法平均響應(yīng)延時(shí)較FCFS算法降低29 074 ms。

表7 2 種算法每秒處理相同數(shù)量請(qǐng)求時(shí)的響應(yīng)延時(shí)對(duì)比Table 7 Comparison of response delay of the two algorithms when processing the same number of requests per second ms

3.3.4 并發(fā)度分析

由并發(fā)度公式可以計(jì)算出FCFS 算法與HCRS算法的并發(fā)度，2 種算法的吞吐量以及各時(shí)刻的平均響應(yīng)延時(shí)對(duì)比如表8 所示。

表8 2 種算法的吞吐量及各時(shí)刻的平均響應(yīng)延時(shí)對(duì)比Table 8 Comparison of throughput and average response delay at each time of the two algorithms

根據(jù)表8 數(shù)據(jù)計(jì)算在0、1、2 時(shí)刻下FCFS 算法的并發(fā)度分別為：C0=88.592 4；C1=389.703 6；C2=674.754 6。

2 種算法的總并發(fā)度為各時(shí)刻的并發(fā)度之和，具體為：CFCFS=1 153.050 6；CHCRS=1 562.525 3。

分析比較2 種算法各時(shí)刻的并發(fā)度以及總并發(fā)度可知，HCRS 算法的并發(fā)度均高于FCFS 算法，因此，本文HCRS 算法能有效提升系統(tǒng)并發(fā)度，從而提高微服務(wù)質(zhì)量。

3.4 實(shí)驗(yàn)結(jié)果總結(jié)

本文在真實(shí)FPGA 云平臺(tái)上進(jìn)行實(shí)驗(yàn)，模擬同一組數(shù)量為1 000 的用戶的登錄及申請(qǐng)節(jié)點(diǎn)操作，從而得到實(shí)際應(yīng)用場(chǎng)景中的用戶請(qǐng)求測(cè)試情況。對(duì)比分析2種算法的測(cè)試結(jié)果可知，在處理用戶并發(fā)申請(qǐng)節(jié)點(diǎn)請(qǐng)求時(shí)，HCRS 算法的請(qǐng)求響應(yīng)時(shí)間較FCFS 算法降低12 605 ms，并且HCRS 算法在提高系統(tǒng)吞吐量以及網(wǎng)絡(luò)接收發(fā)送數(shù)據(jù)量的同時(shí)使得系統(tǒng)更為穩(wěn)定；在每秒處理相同數(shù)量用戶請(qǐng)求的情況下，HCRS 算法的平均響應(yīng)延時(shí)較FCFS 算法降低29 074 ms，前者可以提高系統(tǒng)并發(fā)度并提升微服務(wù)質(zhì)量。

綜上，本文HCRS 算法能在滿足用戶高并發(fā)請(qǐng)求的情況下優(yōu)化系統(tǒng)性能，合理分配硬件節(jié)點(diǎn)資源，提升硬件節(jié)點(diǎn)的資源利用率。

4 結(jié)束語

本文針對(duì)微服務(wù)架構(gòu)下的FPGA 云平臺(tái)用戶請(qǐng)求并發(fā)控制問題，提出一種高并發(fā)請(qǐng)求調(diào)度算法HCRS。結(jié)合自定義參數(shù)響應(yīng)指數(shù)計(jì)算模型，計(jì)算各個(gè)用戶的響應(yīng)指數(shù)，根據(jù)響應(yīng)指數(shù)閾值劃分用戶類別，采取優(yōu)先級(jí)調(diào)度的模式處理用戶申請(qǐng)節(jié)點(diǎn)請(qǐng)求。實(shí)驗(yàn)結(jié)果表明，在高并發(fā)請(qǐng)求場(chǎng)景下，該算法能夠有效降低平均響應(yīng)延時(shí)和請(qǐng)求響應(yīng)時(shí)間，提升系統(tǒng)吞吐量以及網(wǎng)絡(luò)接收發(fā)送的數(shù)據(jù)量，同時(shí)提高系統(tǒng)并發(fā)度，優(yōu)化系統(tǒng)性能，此外，HCRS 算法能夠使得歷史行為較為友好以及使用頻率較高的用戶優(yōu)先使用節(jié)點(diǎn)，從而提升硬件節(jié)點(diǎn)的資源利用率。目前，本文算法已經(jīng)在改進(jìn)后的FPGA 云平臺(tái)中上線投入使用，有效解決了用戶并發(fā)申請(qǐng)節(jié)點(diǎn)的問題，并取得了較好的效果。為了進(jìn)一步優(yōu)化云平臺(tái)性能及微服務(wù)質(zhì)量，下一步將針對(duì)系統(tǒng)容錯(cuò)、網(wǎng)絡(luò)通信安全、服務(wù)監(jiān)控等方面進(jìn)行研究，并優(yōu)化微服務(wù)架構(gòu)中的負(fù)載均衡機(jī)制，通過不同的高并發(fā)原則來提升系統(tǒng)吞吐量。