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

背景技術(shù)：

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

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

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

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

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

技術(shù)實(shí)現(xiàn)思路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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