本發(fā)明涉及云計算，具體涉及服務器無感知計算場景下工作流中函數(shù)間數(shù)據(jù)傳輸。

背景技術：

1、近幾年來，由于具備對資源和編程的高度抽象、按需使用計費以及動態(tài)擴容等優(yōu)勢，服務器無感知計算成為日益流行的云計算開發(fā)范式。為實現(xiàn)復雜的實際應用，用戶通常以有向無環(huán)圖的形式將一系列細粒度函數(shù)編排成工作流，工作流中定義了函數(shù)的順序以及彼此間的數(shù)據(jù)依賴。例如公布號為cn117834709a的現(xiàn)有發(fā)明專利申請文獻《面向服務器無感知計算場景的函數(shù)間數(shù)據(jù)直接傳遞方法》，該現(xiàn)有方法包括：用作前端api端點的網(wǎng)關接收外部函數(shù)請求，執(zhí)行負載平衡，并將其轉(zhuǎn)發(fā)到節(jié)點內(nèi)引擎；節(jié)點內(nèi)引擎分派請求給函數(shù)，并根據(jù)qps決定通知該函數(shù)是否和下游函數(shù)之間建立dtcs；若函數(shù)間不能建立dtcs，則同節(jié)點函數(shù)間和跨節(jié)點函數(shù)間分別采用ipc和fabric傳輸方式數(shù)據(jù)傳輸；若函數(shù)間能建立dtcs，則同節(jié)點函數(shù)間和跨節(jié)點函數(shù)間分別采用dtc_over_ipc和dtc_over_fabric傳輸方式建立有狀態(tài)連接，實現(xiàn)函數(shù)間數(shù)據(jù)直接傳遞。前述當前主流的服務器無感知計算平臺將每個函數(shù)部署在單獨的實例中，由于服務器無感知計算的無狀態(tài)特性和實例動態(tài)伸縮，平臺不向用戶提供函數(shù)實例的實際地址。因此，地址互不感知的實例之間無法建立點對點的直接通信，只能通過第三方路由完成函數(shù)間數(shù)據(jù)的傳輸。具體而言，上游函數(shù)的結(jié)果首先通過平臺提供的api被全局控制器接收，然后控制器查找存有所有函數(shù)實例狀態(tài)的全局路由表，找到空閑的下游函數(shù)實例的地址，最后將收到的數(shù)據(jù)發(fā)送過去。整個傳輸過程中數(shù)據(jù)經(jīng)歷多次拷貝，相比實例間直接傳輸，通信延遲顯著增加。此外，平臺對于單個請求大小存在限制，需要依賴第三方存儲服務存取大數(shù)據(jù)，函數(shù)間只能傳遞實際所在位置，通信開銷進一步增加。顯而易見，隨著系統(tǒng)吞吐的增加，全局控制器承受的負擔會越來越高，很容易成為整個系統(tǒng)的瓶頸，最終致使吞吐難以進一步提高。因此，如何提高工作流的通信效率，是服務器無感知計算領域的一個重要挑戰(zhàn)。

2、現(xiàn)有的工作大多通過優(yōu)化數(shù)據(jù)轉(zhuǎn)發(fā)的效率來加速函數(shù)間中間數(shù)據(jù)傳輸，例如使用更快的內(nèi)存型數(shù)據(jù)庫代替磁盤數(shù)據(jù)庫，或者將函數(shù)部署在同一節(jié)點上，使用高效的進程間通信技術代替協(xié)議棧開銷高昂的網(wǎng)絡通信等。這些方案盡管在延遲上取得了一定改進，但是并沒有改變第三方路由的本質(zhì)，所有的數(shù)據(jù)傳輸依然需要經(jīng)過全局控制器。因此，系統(tǒng)瓶頸的到來只是被推遲，并不能被避免。

3、為了優(yōu)化服務器無感知計算工作流的吞吐，現(xiàn)有的系統(tǒng)大多聚焦于優(yōu)化通信方式，使用更快的數(shù)據(jù)庫，亦或使用本地通信代替網(wǎng)絡通信等。這些方案通過加速數(shù)據(jù)轉(zhuǎn)發(fā)速率在一定程度上降低了通信延遲，實現(xiàn)了系統(tǒng)吞吐的提升，但是這些基于第三方路由的方案中的每個請求依然經(jīng)過集中式的控制器，高吞吐下系統(tǒng)瓶頸依然會出現(xiàn)。為克服函數(shù)間直連的限制，部分方法先通過第三方路由完成兩個實例間的握手，再復用建立的直傳連接傳輸后續(xù)的中間數(shù)據(jù)。但是，基于第三方路由的握手會為關鍵路徑帶來高昂的開銷，同時復用連接采用的靜態(tài)路由策略導致實例間的相互鎖定，進而引發(fā)全部函數(shù)的同步實例擴容，致使嚴重的資源浪費。

4、也有一些工作嘗試通過連接復用的方案突破函數(shù)間直接通信的限制。具體而言，該方案首先通過第三方路由完成函數(shù)實例間的握手，即先交換地址信息，再建立直接連接通道，握手完成后函數(shù)實例即可不斷復用該通道傳輸中間數(shù)據(jù)。盡管該方案通過直連傳輸實現(xiàn)了最優(yōu)的通信效率，但是會導致顯著的握手開銷和低資源效率，進而影響系統(tǒng)吞吐。首先，函數(shù)實例間的握手仍然依賴第三方路由完成，并且第一次中間數(shù)據(jù)傳輸需要等待握手完成后才開始，所以第一個請求會經(jīng)歷比原本基于第三方路由更高的端到端延遲。此外，上游函數(shù)只與每個下游函數(shù)的單個實例握手，并不斷復用同一個直連通道傳輸數(shù)據(jù)，這種靜態(tài)路由策略導致函數(shù)實例間相互鎖定，即新擴容出的實例無法再與原有實例直連。因此，系統(tǒng)只能同步擴容其他所有函數(shù)并在這些新的實例間重新握手，致使嚴重的資源浪費，進而限制了系統(tǒng)吞吐的提升。

5、綜上，現(xiàn)有技術存在實例間鎖定、缺少全局控制器協(xié)調(diào)導致的路由矛盾、限制系統(tǒng)吞吐性能提高的技術問題。

技術實現(xiàn)思路

1、本發(fā)明所要解決的技術問題在于：如何解決現(xiàn)有技術中實例間鎖定、缺少全局控制器協(xié)調(diào)導致的路由矛盾、限制系統(tǒng)吞吐性能提高的技術問題。

2、本發(fā)明是采用以下技術方案解決上述技術問題的：服務器無感知計算工作流吞吐優(yōu)化的本地路由方法包括：

3、s1、利用全局控制器，將函數(shù)路由的功能信息下放至每個函數(shù)實例，函數(shù)實例根據(jù)功能信息，獲取存在依賴關系函數(shù)實例的地址，與存在依賴關系函數(shù)實例建立直傳連接，對每個工作流請求動態(tài)選擇適用路由對象，進行擴容操作；

4、s2、使得函數(shù)實例獲取其余函數(shù)實例的地址并進行直接握手操作，根據(jù)函數(shù)實例內(nèi)存中的本地路由表，為每個工作流請求動態(tài)選擇路由實例；

5、s3、設計穩(wěn)定和恐慌路由機制，使每個函數(shù)實例獨立進行動態(tài)路由決策，選擇數(shù)據(jù)發(fā)送的目的實例，其中，工作流包括：第一函數(shù)a、第二函數(shù)b以及第三函數(shù)c，利用預置扇入結(jié)構(gòu)執(zhí)行第一函數(shù)a、第二函數(shù)b以及第三函數(shù)c；

6、s4、將函數(shù)擴縮容的部分功能也下放至每個實例，構(gòu)建基于本地路由組的擴縮容機制，以利用函數(shù)實例實時監(jiān)測工作流請求的到達頻率、請求執(zhí)行時間，與集中式控制器協(xié)同決策擴縮容策略，并設計本地路由組作為擴縮容管理單位。

7、本發(fā)明通過本地路由實現(xiàn)支持直接握手和動態(tài)路由的數(shù)據(jù)直傳，通過將路由功能由全局控制器下放給每個函數(shù)實例以支持高系統(tǒng)吞吐，降低額外握手開銷和資源浪費。本發(fā)明設計穩(wěn)定/恐慌模式和本地路由組擴縮容等機制，保障本地路由方法下工作流的正確運行和擴縮容，解決了服務器無感知計算工作流中系統(tǒng)吞吐低下的問題。

8、由于全局控制器被從中間數(shù)據(jù)傳輸中移除，本發(fā)明將函數(shù)擴縮容的部分功能也下放至每個實例，構(gòu)建了基于本地路由組的擴縮容機制以滿足不同的系統(tǒng)吞吐需要。

9、在更具體的技術方案中，s1包括：

10、s11、利用系統(tǒng)網(wǎng)關，將工作流請求直接發(fā)送至入口函數(shù)的函數(shù)實例，執(zhí)行函數(shù)代碼；

11、s12、在當前的函數(shù)實例，利用本地控制器查閱本地存儲路由表，選擇合適的下游函數(shù)實例作為適用路由對象，將中間數(shù)據(jù)直傳至適用路由對象；

12、s13、使得函數(shù)實例實時監(jiān)控工作流請求的到達頻率、請求自身處理能力，在工作流請求處于排隊狀態(tài)時，請求集中式控制器進行擴容操作。

13、在更具體的技術方案中，s2包括：

14、s21、利用集中式控制器，向新函數(shù)實例發(fā)送路由表更新信息；

15、s22、函數(shù)實例與新函數(shù)實例進行握手操作，供后續(xù)的工作流請求的直傳備選。

16、本發(fā)明支持函數(shù)實例自行獲取其他函數(shù)實例的地址并進行直接握手，同時在實例內(nèi)存有本地路由表，可以為每個請求動態(tài)選擇路由實例，避免實例間鎖定。

17、本發(fā)明將路由能力下放至每個函數(shù)實例中，從而實現(xiàn)實例的直接握手和動態(tài)路由能力。本發(fā)明在實現(xiàn)實例間數(shù)據(jù)高速直傳的同時，避免了高昂的握手開銷，并保障了函數(shù)級的細粒度擴縮容能力，可以用相同的資源實現(xiàn)最高的系統(tǒng)吞吐。

18、在更具體的技術方案中，s22中，對于部署在不同節(jié)點的函數(shù)實例，根據(jù)本地路由表內(nèi)存儲的ip地址，在函數(shù)實例間建立tcp連接，通過預置網(wǎng)絡連接方式完成數(shù)據(jù)直傳，其中，預置網(wǎng)絡連接方式包括：rdma硬件加速跨機通信，以及共享內(nèi)存與單邊rdma加速大數(shù)據(jù)傳輸。

19、在更具體的技術方案中，s3包括：

20、s31、在第三函數(shù)c的第一函數(shù)實例c-1啟動時，利用全局控制器將第一函數(shù)實例c-1的地址告知第一函數(shù)實例、第二函數(shù)實例，進行握手建立直傳連接；

21、s32、在函數(shù)實例處于默認穩(wěn)定狀態(tài)時，采用穩(wěn)定模式，利用差異路由算法處理扇入結(jié)構(gòu)、非扇入結(jié)構(gòu)；

22、s33、在函數(shù)實例發(fā)生擴容時，切換至恐慌模式，進行重新路由。

23、為解決缺少全局控制器協(xié)調(diào)可能導致的路由矛盾問題，本發(fā)明設計了穩(wěn)定和恐慌兩種路由機制以保障工作流的正常執(zhí)行。

24、在更具體的技術方案中，s32還包括：

25、s321、針對非扇入結(jié)構(gòu)，在上游的函數(shù)實例使用輪詢算法，每個下游的函數(shù)實例輪流作為路由目標；

26、s322、針對扇入結(jié)構(gòu)，使用一致性哈希算法，以工作流請求的id作為鍵值，并根據(jù)個工作量請求的哈希值，在本地路由表構(gòu)成的環(huán)狀結(jié)構(gòu)映射，確定路由結(jié)果。

27、在更具體的技術方案中，s33包括：

28、s331、函數(shù)實例在被通知需要更新本地路由表時，就從穩(wěn)定模式轉(zhuǎn)為恐慌模式；

29、s332、設關鍵路徑數(shù)據(jù)最遲到達，在函數(shù)實例的關鍵路徑數(shù)據(jù)未全部到達時，判定發(fā)生路由矛盾；

30、s333、使當前函數(shù)實例向數(shù)據(jù)缺失函數(shù)的函數(shù)實例發(fā)送重新路由通知；

31、s334、在上游的函數(shù)實例收到重新路由通知時，若上游的函數(shù)實例的本地存在要求數(shù)據(jù)，則重發(fā)要求數(shù)據(jù)至發(fā)送重新路由通知通知的函數(shù)實例，并要求該函數(shù)實例刪除要求數(shù)據(jù)；

32、s335、在確定所有路由表更新期間發(fā)送的工作流請求，都在下游的函數(shù)實例中完整聚合時，退出恐慌模式。

33、本發(fā)明支持對每個請求的動態(tài)路由，并設計了穩(wěn)定和恐慌模式保障工作流的正常運行。其中穩(wěn)定模式保障下游實例的負載均衡并盡量減少路由矛盾的發(fā)送，而恐慌模式監(jiān)測路由矛盾的發(fā)生并在必要時要求上游實例重新路由。

34、在更具體的技術方案中，s334中，使函數(shù)實例持續(xù)檢查后續(xù)的工作流請求是否滿足預置條件，在生成需要數(shù)據(jù)時，將重新路由數(shù)據(jù)路由至相應下游函數(shù)實例；下游函數(shù)實例在收到重新路由數(shù)據(jù)時，會通知其余的上游實例停止檢查。

35、在更具體的技術方案中，s4中，本地路由組包括：存在直傳連接的函數(shù)實例，每個本地路由組還包括：工作流函數(shù)；優(yōu)先在本地路由組內(nèi)，對函數(shù)實例進行擴縮容操作。

36、針對本地路由場景下的全局實例狀態(tài)實時監(jiān)控的缺失，本發(fā)明設計了基于本地路由組的實例擴縮容機制，由每個函數(shù)實例負責監(jiān)視自身的請求到達頻率和執(zhí)行時間，必要時與集中式控制器協(xié)同完成擴縮容工作。本發(fā)明只需用戶提交包含函數(shù)間依賴關系的工作流有向無環(huán)圖，可以自動化部署函數(shù)至服務器無感知計算平臺上并執(zhí)行各項工作，不需要用戶參與，有效降低了人工成本。

37、在更具體的技術方案中，服務器無感知計算工作流吞吐優(yōu)化的本地路由系統(tǒng)包括：

38、路由功能下放模塊，用以利用全局控制器，將函數(shù)路由的功能信息下放至每個函數(shù)實例，函數(shù)實例根據(jù)功能信息，獲取存在依賴關系函數(shù)實例的地址，與存在依賴關系函數(shù)實例建立直傳連接，對每個工作流請求動態(tài)選擇適用路由對象，進行擴容操作；

39、路由實例動態(tài)選擇模塊，用以使得函數(shù)實例獲取其余函數(shù)實例的地址并進行直接握手操作，根據(jù)函數(shù)實例內(nèi)存中的本地路由表，為每個工作流請求動態(tài)選擇路由實例，路由實例動態(tài)選擇模塊與路由功能下放模塊連接；

40、穩(wěn)定恐慌路由機制模塊，用以設置穩(wěn)定和恐慌路由機制，使每個函數(shù)實例獨立進行動態(tài)路由決策，選擇數(shù)據(jù)發(fā)送的目的實例，其中，工作流包括：第一函數(shù)a、第二函數(shù)b以及第三函數(shù)c，利用預置扇入結(jié)構(gòu)執(zhí)行第一函數(shù)a、第二函數(shù)b以及第三函數(shù)c，穩(wěn)定恐慌路由機制模塊與路由實例動態(tài)選擇模塊連接；

41、擴縮容模塊，用以將函數(shù)擴縮容的部分功能也下放至每個實例，構(gòu)建基于本地路由組的擴縮容機制，以利用函數(shù)實例實時監(jiān)測工作流請求的到達頻率、請求執(zhí)行時間，與集中式控制器協(xié)同決策擴縮容策略，并設計本地路由組作為擴縮容管理單位，擴縮容模塊與穩(wěn)定恐慌路由機制模塊連接。

42、本發(fā)明相比現(xiàn)有技術具有以下優(yōu)點：

43、本發(fā)明通過本地路由實現(xiàn)支持直接握手和動態(tài)路由的數(shù)據(jù)直傳，通過將路由功能由全局控制器下放給每個函數(shù)實例以支持高系統(tǒng)吞吐，降低額外握手開銷和資源浪費。本發(fā)明設計穩(wěn)定/恐慌模式和本地路由組擴縮容等機制，保障本地路由方法下工作流的正確運行和擴縮容，解決了服務器無感知計算工作流中系統(tǒng)吞吐低下的問題。

44、由于全局控制器被從中間數(shù)據(jù)傳輸中移除，本發(fā)明將函數(shù)擴縮容的部分功能也下放至每個實例，構(gòu)建了基于本地路由組的擴縮容機制以滿足不同的系統(tǒng)吞吐需要。

45、本發(fā)明支持函數(shù)實例自行獲取其他函數(shù)實例的地址并進行直接握手，同時在實例內(nèi)存有本地路由表，可以為每個請求動態(tài)選擇路由實例，避免實例間鎖定。

46、本發(fā)明將路由能力下放至每個函數(shù)實例中，從而實現(xiàn)實例的直接握手和動態(tài)路由能力。本發(fā)明在實現(xiàn)實例間數(shù)據(jù)高速直傳的同時，避免了高昂的握手開銷，并保障了函數(shù)級的細粒度擴縮容能力，可以用相同的資源實現(xiàn)最高的系統(tǒng)吞吐。

47、為解決缺少全局控制器協(xié)調(diào)可能導致的路由矛盾問題，本發(fā)明設計了穩(wěn)定和恐慌兩種路由機制以保障工作流的正常執(zhí)行。

48、本發(fā)明支持對每個請求的動態(tài)路由，并設計了穩(wěn)定和恐慌模式保障工作流的正常運行。其中穩(wěn)定模式保障下游實例的負載均衡并盡量減少路由矛盾的發(fā)送，而恐慌模式監(jiān)測路由矛盾的發(fā)生并在必要時要求上游實例重新路由。

49、針對本地路由場景下的全局實例狀態(tài)實時監(jiān)控的缺失，本發(fā)明設計了基于本地路由組的實例擴縮容機制，由每個函數(shù)實例負責監(jiān)視自身的請求到達頻率和執(zhí)行時間，必要時與集中式控制器協(xié)同完成擴縮容工作。本發(fā)明只需用戶提交包含函數(shù)間依賴關系的工作流有向無環(huán)圖，可以自動化部署函數(shù)至服務器無感知計算平臺上并執(zhí)行各項工作，不需要用戶參與，有效降低了人工成本。

50、本發(fā)明解決了現(xiàn)有技術中存在的實例間鎖定、缺少全局控制器協(xié)調(diào)導致的路由矛盾、限制系統(tǒng)吞吐性能提高的技術問題。