【技術實現步驟摘要】
本文屬于無服務計算領域，具體涉及一種面向云邊協同場景下的邊端無服務計算響應調度方法。
技術介紹
1、在無服務器計算(serverless?computing)場景下，應用程序的執行由云服務提供商完全管理，開發者只需專注于代碼編寫而無需關心底層基礎設施的運維。傳統的無服務框架，是將所有請求排列在一個中央隊列中，按到達的時間順序處理，這種情況下用時較短響應較快的函數請求往往會等待更改長時間。
2、隨著軟硬件技術的發展，無服務計算框架在后來則是分別收集每個函數各自的請求，如果函數存在持續的多個請求，則不會回收函數的資源，在完成所有請求前保持函數的持續運行，但執行周期較短的函數仍然會因為較長執行期的函數阻塞執行隊列，造成響應時間過長的問題。
3、在基于云-邊協同的場景下，無服務器計算是一種靈活且高效的計算模式，用戶無需管理底層服務器資源，只需關注代碼的運行和業務邏輯的實現，為請求(request)調用的函數分配資源，將其初始化為函數實例，由函數實例處理請求的響應。在云-邊協同的場景下，由于成本和場景限制等情況，邊端的資源池無法大量保持函數的實例，而完成函數實例初始化需要一定的時間，即函數冷啟動(cold?start)，會導致明顯的響應延遲，造成系統的響應時間邊長、請求響應吞吐量降低。
4、此外，由于無服務器計算的資源是動態分配的，不合理的調度策略可能會導致請求堵塞問題。當系統接收到大量請求時，需要根據調度策略及時有效地分配計算資源，處理待響應請求，避免部分請求可能會在隊列中等待較長時間，甚至超時失敗，
5、在云端場景下具有相對充足的資源，可以響應邊端系統無法及時處理的請求。但云邊之間溝通的網絡存在不確定性，在所有條件下都由云端處理請求并不合理，因此亟需一種新的技術技術方案以提高云邊協同場景下邊端無服務計算響應調度的效率。
技術實現思路
1、針對現有技術的上述問題，本文的目的在于，提供一種面向云邊協同場景下的邊端無服務計算響應調度方法，可以提高邊端無服務計算響應調度的效率。
2、為了解決上述技術問題，本文的具體技術方案如下：
3、一方面，本文提供一種面向云邊協同場景下的邊端無服務計算響應調度方法，應用于邊端-云端協同工作的無服務計算響應調度系統，所述方法包括：
4、根據函數調用請求指令，確定目標函數；
5、判斷目標函數請求等待隊列是否為空，且是否存在目標函數對應的空閑函數實例；
6、若是，則將所述函數調用請求指令發送至所述目標函數請求等待隊列，以完成函數創建流程；
7、若否，則當所述邊端的資源池容量小于目標函數對應函數實例數量，且未超過預設閾值時，則根據資源池容量和收到請求的數量將所述函數請求指令動態分配至邊端或云端響應；
8、當所述邊端的資源池容量小于目標函數對應函數實例數量，且超過預設閾值時，則將所述函數調用請求指令發送至云端響應；
9、當所述邊端的資源池容量大于目標函數對應的函數實例數量時，則根據函數冷啟動延時、函數執行用時以及目標函數請求等待隊列對所述函數調用請求指令進行響應。
10、進一步地，當所述邊端的資源池容量小于目標函數對應函數實例數量，且未超過預設閾值時，則根據資源池容量和收到請求的數量將所述函數請求指令動態分配至邊端或云端響應，包括：
11、根據所述資源池容量和收到請求的數量，按照動態分配公式確定交由云端響應的請求的比例，其中所述動態分配公式為：
12、其中，c為資源池容量，n表示當前狀態下無服務計算調度系統接收到的需要響應請求數量，threshold為預設閾值，表示超過c后仍不完全交由云端處理的額外響應請求數量的閾值大小，ratiocloud表示當待響應請求的數量為n時，超過c數量的待響應請求中需要交由云端處理的百分比；
13、根據確定的交由云端響應的請求的比例，確定由邊端響應處理的請求；
14、根據由邊端響應處理的請求，以及所述目標函數對應的函數實例集合，將函數實例集合中平均執行時間最長的函數實例替換為待響應的請求對應的目標函數。
15、進一步地，根據由邊端響應處理的請求，以及所述目標函數對應的函數實例集合，將函數實例集合中平均執行時間最長的函數實例替換為待響應的請求對應的目標函數，包括：
16、確定冷啟動新函數實例并回收已有函數實例后函數更新后的待響應請求數量，表示為：其中，為更新后的待響應請求數量，為平均冷啟動延遲、為平均閑置后回收時間、為平均執行用時，為獲取請求ri后函數fi的待響應請求數量；
17、當所述更新后的待響應請求數量大于零，且存在空閑狀態實例的函數實例集合時，對所述函數實例集合中的平均執行時間進行排序，將平均執行時間最大的函數實例進行初始化，以用于更新后待響應請求的函數實例創建。
18、進一步地，當所述邊端的資源池容量大于目標函數對應的函數實例數量時，則根據函數冷啟動延時、函數執行用時以及目標函數請求等待隊列對所述函數調用請求指令進行響應，包括：
19、根據所述函數冷啟動延時、函數執行用時以及目標函數請求等待隊列，確定經過冷啟動后的待響應請求數量；
20、當經過冷啟動后的待響應請求數量大于零時，則初始化新的函數實例，以用于待響應請求的函數實例創建；
21、當經過冷啟動后的待響應請求數量小于等于零時，將函數調用請求指令加入目標函數請求等待隊列中。
22、進一步地，經過冷啟動后的待響應請求數量通過如下公式表示：
23、其中，為經過冷啟動后的待響應請求數量，，|ai|為函數fi存在的實例集合ai中包含的實例數量，為平均冷啟動延遲、為平均執行用時，為獲取請求ri后函數fi的待響應請求數量。
24、進一步地，所述方法還包括：
25、在函數實例完成響應后，分別計算完成響應的函數實例的權重，以及待響應請求中每個函數實例的權重；
26、將完成響應的函數實例的權重確定為第一權重，將待響應請求中函數實例的權重中的最小值確定為第二權重；
27、當所述第一權重大于第二權重時，則將所述第二權重對于的函數實例進行回收處理，用于創建新的函數實例；
28、當時第一權重不大于所述第二權重時，則根據判斷完成響應的函數實例是否還存在待響應請求；
29、若存在，則將待處理的請求分配給完成響應的函數實例處理；
30、若不存在，則在資源池有冗余的情況下，將完成響應的函數實例轉換為閑置狀態等待請求，或將完成響應的函數實例進行資源回收。
31、進一步地，完成響應的函數實例的權重通過如下公式表示：
32、
33、待響應請求中每個函數實例的權重通過如下公式表示：
34、
35、進一步地，所述邊端的資源池容量為同一邊端的資源池對應的容量。
36、本文檔來自技高網...
【技術保護點】
1.一種面向云邊協同場景下的邊端無服務計算響應調度方法，其特征在于，應用于邊端-云端協同工作的無服務計算響應調度系統，所述方法包括：
2.根據權利要求1所述的方法，其特征在于，當所述邊端的資源池容量小于目標函數對應函數實例數量，且未超過預設閾值時，則根據資源池容量和收到請求的數量將所述函數請求指令動態分配至邊端或云端響應，包括：
3.根據權利要求2所述的方法，其特征在于，根據由邊端響應處理的請求，以及所述目標函數對應的函數實例集合，將函數實例集合中平均執行時間最長的函數實例替換為待響應的請求對應的目標函數，包括：
4.根據權利要求1所述的方法，其特征在于，當所述邊端的資源池容量大于目標函數對應的函數實例數量時，則根據函數冷啟動延時、函數執行用時以及目標函數請求等待隊列對所述函數調用請求指令進行響應，包括：
5.根據權利要求1所述的方法，其特征在于，經過冷啟動后的待響應請求數量通過如下公式表示：
6.根據權利要求1所述的方法，其特征在于，所述方法還包括：
7.根據權利要求6所述的方法，其特征在于，
9.一種面向云邊協同場景下的邊端無服務計算響應調度系統，其特征在于，系統包括：邊端、云端和調度模塊，所述調度模塊用于執行如權利要求1至8任一項所述方法的步驟。
10.一種計算機可讀存儲介質，其特征在于，所述計算機可讀存儲介質存儲有計算機程序，所述計算機程序被處理器執行時實現權利要求1至8任一項所述的方法。
...【技術特征摘要】
1.一種面向云邊協同場景下的邊端無服務計算響應調度方法，其特征在于，應用于邊端-云端協同工作的無服務計算響應調度系統，所述方法包括：
2.根據權利要求1所述的方法，其特征在于，當所述邊端的資源池容量小于目標函數對應函數實例數量，且未超過預設閾值時，則根據資源池容量和收到請求的數量將所述函數請求指令動態分配至邊端或云端響應，包括：
3.根據權利要求2所述的方法，其特征在于，根據由邊端響應處理的請求，以及所述目標函數對應的函數實例集合，將函數實例集合中平均執行時間最長的函數實例替換為待響應的請求對應的目標函數，包括：
4.根據權利要求1所述的方法，其特征在于，當所述邊端的資源池容量大于目標函數對應的函數實例數量時，則根據函數冷啟動延時、函數執行用時以及目標函數請求等待隊...
【專利技術屬性】
技術研發人員：朱國偉，周河曉，李直儒，王驍，劉曉慧，黃自成，肖澤曉，顧維璽，
申請(專利權)人：中國工業互聯網研究院，
類型：發明
國別省市：
還沒有人留言評論。發表了對其他瀏覽者有用的留言會獲得科技券。