基于微服務架構FPGA 云平臺的并發請求調度機制

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

（1.江南大學 人工智能與計算機學院，江蘇 無錫 214122；2.江蘇虎甲蟲計算技術有限公司，江蘇 無錫 214000；3.江蘇省模式識別與計算智能工程實驗室，江蘇無錫 214122）

0 概述

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

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

上述研究中的相關算法通過減少服務選擇的計算時間和重復的存儲庫訪問來提高并發性能，但僅適用于多服務共享調度系統，而FPGA 云平臺是基于單服務的調度系統，無需進行服務選擇。因此，上述算法并不適用于處理FPGA 云平臺的并發請求問題。

本文基于單服務調度系統下的FPGA 云平臺，建立一種自定義參數響應指數計算模型，用于計算高并發請求下每個用戶對應的響應指數，并基于該模型設計一種高并發請求調度（HCRS）算法。在真實運營的FPGA 云平臺中使用用戶數據進行測試，以驗證該算法的平均響應延時、系統吞吐量等性能。

1 基于微服務架構的FPGA 云平臺

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

1.1 FPGA 云平臺架構

FPGA 云平臺主要由Web 應用層以及節點資源管理微服務組成，其系統架構及關鍵組件如圖1 所示，終端用戶可以在不同設備上使用網絡瀏覽器訪問FPGA 云平臺、在云平臺上申請使用節點、檢查FPGA 硬件節點實時執行狀態等。

圖1 FPGA 云平臺系統架構Fig.1 FPGA cloud platform system architecture

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

1.2 節點資源管理微服務

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

圖2 節點資源管理微服務架構Fig.2 Node resource management microservice architecture

1.3 并發請求應用場景描述

在微服務架構下的FPGA 云平臺實際應用場景中，由于FPGA 服務器硬件節點個數有限，當大量用戶在同一時間并發申請節點時，請求響應時間將延長，此時無法滿足所有用戶的請求，微服務節點資源被占滿甚至直接導致微服務宕機。高并發請求過程如圖3 所示。

圖3 高并發請求過程Fig.3 High concurrent request process

2 節點資源管理微服務高并發請求調度算法

本文從節點資源管理微服務的高并發請求實際應用場景出發，建立自定義參數響應指數計算模型，確保能夠準確描述每個用戶申請節點請求的優先級順序。在此基礎上，提出一種高并發請求調度算法HCRS，以實現節點資源合理分配并優化微服務質量。

2.1 參數設置及權重確定

2.1.1 參數設置

為解決FPGA 云平臺上的用戶申請節點高并發控制問題，本文從優先級調度入手，分析用戶申請操作的關鍵影響因素，將這些影響因素作為自定義參數，具體如表1 所示，其中：用戶計劃使用時間表示被申請節點預計占用時長；歷史使用平均時長用來評估用戶歷史使用頻率；歷史空置時間用來衡量用戶是否高效使用節點。

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

2.1.2 自定義參數權重確定

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

結合本文應用場景，AHP 可以根據各個自定義參數的重要級別對其進行排名，從而得出參數的權重大小。AHP 定義的重要程度及其對應數值如表2 所示。

表2 參數重要程度及其對應的數值Table 2 Parameters importance and its corresponding value

根據表2 所示的比較標準，對上述自定義的5 個參數，即用戶計劃使用時間、是否為會員、用戶計劃申請節點數量、用戶歷史使用平均時長以及用戶歷史空置時間進行比較，得出如表3 所示的判斷矩陣。根據判斷矩陣［21］計算各個參數對應的權重，本文使用Python 實現AHP 分析的完整過程，首先對判斷矩陣進行一致性檢驗，檢驗通過方可進行權重計算，AHP 計算權重的算法描述具體如算法1 所示。

表3 判斷矩陣Table 3 Judgment matrix

算法1AHP 計算權重算法

2.2 模型建立

2.2.1 響應指數函數定義

FPGA 云平臺在上線運行過程中將面臨海量用戶的注冊登錄以及申請節點等操作，此時會產生響應速度慢、響應延時長、長時間申請不到節點等問題。為此，本文建立一種自定義參數響應指數計算模型，該模型主要用于對每個用戶的申請輸入參數進行分析計算，對應的申請節點請求響應指數計算公式如式（1）所示：

其中：y為響應指數；W1～W5為參數對應的權重；Xplan、Xvip、Xnodenum、Xhisavg、Xempty分別為用戶計劃使用時間、是否為會員、用戶計劃申請節點數量、用戶歷史使用平均時長、用戶歷史空置時間歸一化后的值。

2.2.2 響應指數閾值定義

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

表4 閾值分析結果Table 4 Threshold analysis results

2.3 衡量指標

在FPGA 云平臺環境中，為了進一步分析用戶高并發申請節點時系統的整體性能以及用戶申請節點情況，本文引入下列參數作為衡量指標：

1）用戶請求響應時間Tu，其計算公式如式（2）所示：

其中：Tcs為用戶從客戶端向服務器端發出請求的時間；Ts為服務器接受請求并處理所需的時間；Tsc為服務器端返回數據給客戶端的時間；Tc為客戶端接收響應數據并處理所需的時間。

2）吞吐量Qt，指單位時間內系統處理請求的數量，其計算公式如式（3）所示：

其中：Snum為樣本總數量；Tlast為最后一個線程啟動的時間；Tlasttime為最后一個線程持續的時間；Tfirst為第一個線程啟動的時間。

3）平均響應延時La，其計算公式如式（4）所示：

其中：li為單個請求的響應延時。

4）并發度C，其計算公式如式（5）所示，對于一個系統而言，平均響應延時為每個請求所需的時間，吞吐量為單位時間的請求數量，因此，兩者相乘即為并發度。

根據上述公式可以計算得出用戶請求響應時間以及微服務的并發度，從而衡量FPGA 云平臺中節點資源管理微服務的服務質量。從用戶請求響應時間角度分析，響應時間越小，用戶體驗質量越好；從系統的并發度角度分析，并發度越高，系統性能越好［23］。

2.4 算法設計

本文在上述自定義參數響應指數計算模型的基礎上，提出一種高并發請求調度算法HCRS，根據上述定義的閾值將用戶響應指數劃分為直接申請、加入隊列等待申請、掛起申請3 種執行類型，并以此為標準分配用戶申請節點請求。

本文算法的執行流程如圖4 所示，大量用戶同時發起申請節點請求，輸入對應的參數，在傳遞輸入參數后，模型開始計算各個用戶對應的響應指數，并將其大小與閾值進行比較，從而分類處理不同用戶的請求。

圖4 HCRS 算法執行流程Fig.4 HCRS algorithm execution procedure

基于自定義參數響應指數計算模型，本文設計的高并發請求調度算法描述具體如下：

算法2HCRS 算法

3 實驗結果與分析

本文將HCRS 算法應用到真實的FPGA 云平臺上，并通過在真實應用場景下模擬同一組用戶高并發登錄及申請節點請求，以分析評估資源分配情況以及微服務的質量。

3.1 實驗環境

本文部署節點資源管理微服務的軟件環境為CentOS Linux release 7.8.2003（Core）+GCC V4.8.5，其底層框架為Tornado5.1，FPGA 云平臺使用的硬件節點為Xilinx 公司發布的PYNQ-Z2，節點系統為PYNQ Linux，based on Ubuntu 18.04+GCC V7.3.0。Web 應用技術棧為Spring Boot、Apache Shiro、MyBatis、Thymeleaf。數據庫采用Mysql 5.5 與Redis 3.0 相結合的方式存儲管理數據。

測試部分首先使用可視化測試工具Badboy 將單個登錄以及申請節點的測試腳本直接導出生成Apache Jmeter 腳本，然后使用Apache Jmeter，根據具體測試要求修改測試腳本，添加用戶登錄信息以及用戶計劃使用時間，即輸入參數進行測試。

3.2 實驗結果

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

在不同算法下，1 000 個用戶登錄以及申請節點的請求通過率為100%，請求響應時間如表5 所示，其中，“99%”表示99%請求的響應時間。從表5 可以看出，與FCFS 算法相比，HCRS 算法申請節點的平均響應時間縮短了12 605 ms。

表5 用戶請求響應時間對比Table 5 Comparison of user request response time ms

2 種算法在吞吐量及網絡接收發送數據量上的對比結果如表6 所示，從表6 可以看出，在申請節點請求下，HCRS 算法的吞吐量以及網絡收發數據量均優于FCFS 算法。

表6 吞吐量及網絡收發數據量對比Table 6 Comparison of throughput and network received and sent data volume

衡量微服務質量的另一個指標為用戶請求平均響應延時，1 000 個用戶并發請求執行完畢所需總時長為2 min。圖5 對比顯示了2 種算法在總時長內每隔1 min 的平均響應延時，從圖5 可以看出，HCRS 算法的請求平均響應延時略高于FCFS 算法。

圖5 2 種算法的平均響應延時對比Fig.5 Comparison of average response delay of two algorithms

3.3 結果分析

3.3.1 用戶請求響應時間分析

從3.2 節實驗結果可以看出，HCRS 算法申請節點請求平均響應時間優于FCFS 算法。2 種算法在不同響應時間區間內處理請求個數情況如圖6 所示，從圖6 可以看出，HCRS 算法大部分請求響應時間處于40～80 s 之間，少部分請求處于80～120 s 之間，而FCFS 算法幾乎所有請求的響應時間都處于80～120 s 之間。因此，在處理用戶并發申請節點請求上，HCRS 算法能有效降低請求響應時間。

圖6 2 種算法在不同響應時間區間內處理請求個數對比Fig.6 Comparison of the number of requests processed by the two algorithms in different response time intervals

3.3.2 系統吞吐量分析

從3.2 節實驗結果可知，HCRS 算法的系統吞吐量較FCFS 算法更優。從圖7 各時刻系統吞吐量的對比情況可知，HCRS 算法更為穩定，前期處于上升趨勢，中期最高能實現每秒處理11 個請求，后期回落到每秒處理6 個請求，而FCFS 算法的系統吞吐量到后半程才逐漸上升，最高達到每秒處理約16 個請求，相比之下，使用HCRS 算法的系統吞吐量更為穩定并且性能更優。

圖7 2 種算法各時刻的系統吞吐量對比Fig.7 Comparison of system throughput of two algorithms at each time

3.3.3 用戶請求平均響應延時分析

從3.2 節實驗結果可知，HCRS 算法下的用戶請求平均響應延時高于FCFS 算法。從完成一個完整請求所需時間（即響應延時）與每秒請求數的關系角度分析，2 種算法的實驗結果分別如圖8、圖9 所示。從中可以看出，并發處理用戶請求的數量集中在250 個請求以內，對比分析這段區間內的響應延時，FCFS 算法的響應延時多數分布在80～100 s 之間，少數分布在0～50 s 之間，最高達到128 s 左右，而HCRS算法的響應延時多數分布在50～100 s 之間，少數分布在0～20 s 之間，最高達到95 s。因此，HCRS 算法處理請求的延時普遍低于FCFS 算法。

圖8 FCFS 算法平均響應延時與每秒請求數的關系Fig.8 The relationship between the average response delay of FCFS algorithm and the number of requests per second

圖9 HCRS 算法平均響應延時與每秒請求數的關系Fig.9 The relationship between the average response delay of HCRS algorithm and the number of requests per second

對比2 種算法每秒處理相同數量（1、2、6、185）用戶請求時的響應延時，結果如表7 所示，從中可以看出，HCRS算法平均響應延時較FCFS算法降低29 074 ms。

表7 2 種算法每秒處理相同數量請求時的響應延時對比Table 7 Comparison of response delay of the two algorithms when processing the same number of requests per second ms

3.3.4 并發度分析

由并發度公式可以計算出FCFS 算法與HCRS算法的并發度，2 種算法的吞吐量以及各時刻的平均響應延時對比如表8 所示。

表8 2 種算法的吞吐量及各時刻的平均響應延時對比Table 8 Comparison of throughput and average response delay at each time of the two algorithms

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

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

分析比較2 種算法各時刻的并發度以及總并發度可知，HCRS 算法的并發度均高于FCFS 算法，因此，本文HCRS 算法能有效提升系統并發度，從而提高微服務質量。

3.4 實驗結果總結

本文在真實FPGA 云平臺上進行實驗，模擬同一組數量為1 000 的用戶的登錄及申請節點操作，從而得到實際應用場景中的用戶請求測試情況。對比分析2種算法的測試結果可知，在處理用戶并發申請節點請求時，HCRS 算法的請求響應時間較FCFS 算法降低12 605 ms，并且HCRS 算法在提高系統吞吐量以及網絡接收發送數據量的同時使得系統更為穩定；在每秒處理相同數量用戶請求的情況下，HCRS 算法的平均響應延時較FCFS 算法降低29 074 ms，前者可以提高系統并發度并提升微服務質量。

綜上，本文HCRS 算法能在滿足用戶高并發請求的情況下優化系統性能，合理分配硬件節點資源，提升硬件節點的資源利用率。

4 結束語

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