(19)國家知識產(chǎn)權(quán)局(12)發(fā)明專利(65)同一申請的已公布的文獻號(73)專利權(quán)人度小滿科技(北京)有限公司院西區(qū)4號樓6層606(72)發(fā)明人王少添(74)專利代理機構(gòu)北京知帆遠景知識產(chǎn)權(quán)代理有限公司11890專利代理師劉巖磊審查員劉瑩一種推理服務(wù)方法、設(shè)備及系統(tǒng)本發(fā)明公開了一種推理服務(wù)方法，該方法中消息總線在接收到客戶端發(fā)送的推理請求后，將其投入至與其服務(wù)類型對應(yīng)的消息隊列中，并向訂閱該消息隊列的服務(wù)實例發(fā)送新請求通知，服務(wù)實例在接收到新請求通知后可以根據(jù)自身的實際性能，包括負載情況以及可用性確定是否承接該請求，若可以承接，則從消息總線獲取推理請求并處理。這一請求的處理過程中服務(wù)實例根據(jù)自身實際性能進行請求的承接，保證請求的均衡處理；而且當(dāng)推理請求發(fā)送到消息總線后，請求可以在網(wǎng)絡(luò)恢復(fù)后繼續(xù)被處理，容錯性高；同時各服務(wù)實例可以同時進行請求的承接以及處2消息總線接收到客戶端發(fā)送的推理請求后，確定所述推理請求的服務(wù)類型；將所述推理請求添加至主題與所述服務(wù)類型相對應(yīng)的消息隊列中；向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知，以便所述服務(wù)實例根據(jù)自身負載以及服務(wù)可用性接收或拒絕所述推理請求的處理；其中，在所述向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知之后，所述方法還包括：在接收到服務(wù)實例發(fā)送的請求處理通知后，確定處理的請求，作為目標請求；向所述目標請求添加文件鎖；在接收到請求處理完成通知后，將所述目標請求刪除；在所述向所述目標請求添加文件鎖之后，還包括：若所述目標請求的處理異常，解開所述目標請求的文件鎖；其中，各所述服務(wù)實例根據(jù)自身負載從消息隊列中讀取若干推理請求，并同時批量處理各推理請求。2.一種消息總線，其特征在于，包括：若干設(shè)置有用于指示服務(wù)類型的主題的消息隊所述消息總線用于：接收到客戶端發(fā)送的推理請求后，確定所述推理請求的服務(wù)類型；將所述推理請求添加至主題與所述服務(wù)類型相對應(yīng)的消息隊列中；向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知，以便所述服務(wù)實例根據(jù)自身負載以及服務(wù)可用性接收或拒絕所述推理請求的處理；其中，在所述向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知之后，所述方法還包括：在接收到服務(wù)實例發(fā)送的請求處理通知后，確定處理的請求，作為目標請求；向所述目標請求添加文件鎖；在接收到請求處理完成通知后，將所述目標請求刪除；在所述向所述目標請求添加文件鎖之后，還包括：若所述目標請求的處理異常，解開所述目標請求的文件鎖；其中，各所述服務(wù)實例根據(jù)自身負載從消息隊列中讀取若干推理請求，并同時批量處理各推理請求。服務(wù)實例接收訂閱的消息總線中的消息隊列發(fā)送的新請求通知；其中，所述新請求通知為所述消息總線將客戶端發(fā)送的推理請求添加至所述消息隊列后觸發(fā)；所述消息隊列的主題與所述服務(wù)實例的推理服務(wù)類型相對應(yīng)；根據(jù)自身負載以及服務(wù)可用性判斷是否可以承接所述推理請求；若可以承接，從所述消息隊列讀取所述推理請求并進行推理處理；其中，在所述服務(wù)實例接收訂閱的消息總線中的消息隊列發(fā)送的新請求通知之后，所述方法還包括：在接收到服務(wù)實例發(fā)送的請求處理通知后，確定處理的請求，作為目標請求；向所述目標請求添加文件鎖；在接收到請求處理完成通知后，將所述目標請求刪除；在所述向所述目標請求添加文件鎖之后，還包括：3若所述目標請求的處理異常，解開所述目標請求的文件鎖；所述從所述消息隊列獲取所述推理請求并進行推理處理，包括：根據(jù)自身負載從所述消息隊列中讀取若干所述推理請求，并同時批量處理各所述推理處理器，用于執(zhí)行所述計算機程序時實現(xiàn)如權(quán)利要求1或3所述推理服務(wù)方法的步驟。5.一種推理服務(wù)系統(tǒng)，其特征在于，包括：客戶端、消息總線以及若干具有不同服務(wù)類型的服務(wù)實例；其中，所述客戶端，用于接收用戶發(fā)起的推理請求，并將所述推理去請求發(fā)送至所述消息總線；所述消息總線中包含若干消息隊列，所述消息總線用于接收到所述推理請求后，確定所述推理請求的服務(wù)類型；將所述推理請求添加至主題與所述服務(wù)類型相對應(yīng)的消息隊列中；向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知；所述服務(wù)實例，用于接收所述新請求通知；根據(jù)自身負載以及服務(wù)可用性判斷是否可以承接所述推理請求；若可以承接，從所述消息隊列獲取所述推理請求并進行推理處理；其中，在所述向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知之后，所述方法還包括：在接收到服務(wù)實例發(fā)送的請求處理通知后，確定處理的請求，作為目標請求；向所述目標請求添加文件鎖；在接收到請求處理完成通知后，將所述目標請求刪除；在所述向所述目標請求添加文若所述目標請求的處理異常，解開所述目標請求的文件鎖；其中，各所述服務(wù)實例根據(jù)自身負載從消息隊列中讀取若干推理請求，并同時批量處理各推理請求。6.根據(jù)權(quán)利要求5所述的推理服務(wù)系統(tǒng)，其特征在于，還包括：與所述消息隊列連接的服務(wù)管理器；所述服務(wù)管理器，用于服務(wù)管理器監(jiān)聽所述消息總線中各消息隊列的請求處理速度，生成請求處理監(jiān)聽記錄，根據(jù)所述請求處理監(jiān)聽記錄對所述服務(wù)實例進行擴縮容處理。7.根據(jù)權(quán)利要求6所述的推理服務(wù)系統(tǒng)，其特征在于，所述服務(wù)管理器，具體用于：根據(jù)所述請求處理監(jiān)聽記錄確定目標消息隊列的請求處理速度；若所述請求處理速度低于第一閾值；添加與所述目標消息隊列的主題相對應(yīng)的服務(wù)類型的服務(wù)實例；若所述請求處理速度高于第二閾值；減少與所述目標消息隊列的主題相對應(yīng)的服務(wù)類型的服務(wù)實例；其中，所述第一閾值低于所述第二閾值。4技術(shù)領(lǐng)域背景技術(shù)[0002]模型主要用于對客戶端提供的請求數(shù)據(jù)(比如文本、圖片、視頻等)進行計算，得出一個結(jié)果(比如分類，數(shù)值等),包括機器學(xué)習(xí)模型，深度神經(jīng)網(wǎng)絡(luò)模型等不同種類的模型。其中數(shù)據(jù)準備、特征提取、建模、訓(xùn)練以及部署等過程都需要強大的數(shù)據(jù)采集能力、數(shù)據(jù)處理能力以及分析能力、模型結(jié)構(gòu)以及參數(shù)知識，專業(yè)性要求較強，而且對于部署的設(shè)備性能要求也較高，開發(fā)成本較高，部分企業(yè)或單位難以達到模型開發(fā)的條件，但是其仍需要模型自身強大的推理能力來滿足自身數(shù)據(jù)處理的高精度要求，因此模型推理服務(wù)應(yīng)運而生。[0003]模型推理服務(wù)指通過某種網(wǎng)絡(luò)協(xié)議(比如http、grpc等),對外提供模型能力的服務(wù)，由客戶端發(fā)起推理請求后，由模型推理服務(wù)中對應(yīng)的服務(wù)實例(instance,即模型)響應(yīng)該推理請求進行推理服務(wù)。現(xiàn)有在線模型推理服務(wù)為了能夠同時提供多種模型服務(wù)以及滿足高并發(fā)要求，通常采用代理結(jié)構(gòu)，由代理服務(wù)器負責(zé)管理多種模型服務(wù)實例，使用路由算法將模型推理請求發(fā)送給空閑的服務(wù)實例(instance)。但是該種模式下代理服務(wù)器無法精準每個推理服務(wù)的實際容量和壓力，在請求的分發(fā)中無法實現(xiàn)請求數(shù)量與服務(wù)實例自身處理能力的匹配，極易造成服務(wù)實例過載或空載的情況，增加了推理請求的平均耗時；同時也無法實時、準確地獲得可用的推理服務(wù)，極易出現(xiàn)因為使用了錯誤地址而導(dǎo)致請求失敗的情況；而且代理服務(wù)在一個請求處理完成后再下發(fā)下一個推理請求，整體請求處理效率低，如果網(wǎng)絡(luò)故障或者推理服務(wù)故障，則會導(dǎo)致該推理請求失敗，無法進入下一個推理請求的[0004]綜上所述，如何保證推理請求分配的均勻合理性，提升推理請求的響應(yīng)效率以及成功率，是目前本領(lǐng)域技術(shù)人員急需解決的技術(shù)問題。發(fā)明內(nèi)容[0005]本發(fā)明的目的是提供一種推理服務(wù)方法、設(shè)備及系統(tǒng)，以保證推理請求分配的均勻合理性，提升推理請求的響應(yīng)效率以及成功率。[0006]為解決上述技術(shù)問題，本發(fā)明提供如下技術(shù)方案：[0008]消息總線接收到客戶端發(fā)送的推理請求后，確定所述推理請求的服務(wù)類型；[0009]將所述推理請求添加至主題與所述服務(wù)類型相對應(yīng)的消息隊列中；[0010]向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知，以便所述服務(wù)實例根據(jù)自身負載以及服務(wù)可用性接收或拒絕所述推理請求的處理。[0011]可選地，在所述向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知之后，還5[0013]向所述目標請求添加文件鎖；[0014]在接收到請求處理完成通知后，將所述目標請求刪除。[0016]若所述目標請求的處理異常，解開所述目標請求的文件鎖。[0018]所述消息總線用于：接收到客戶端發(fā)送的推理請求后，確定所述推理請求的服務(wù)類型；將所述推理請求添加至主題與所述服務(wù)類型相對應(yīng)的消息隊列中；向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知，以便所述服務(wù)實例根據(jù)自身負載以及服務(wù)可用性接收或拒絕所述推理請求的處理。[0020]服務(wù)實例接收訂閱的消息總線中的消息隊列發(fā)送的新請求通知；其中，所述新請求通知為所述消息總線將客戶端發(fā)送的推理請求添加至所述消息隊列后觸發(fā)；所述消息隊列的主題與所述服務(wù)實例的推理服務(wù)類型相對應(yīng)；[0021]根據(jù)自身負載以及服務(wù)可用性判斷是否可以承接所述推理請求；[0022]若可以承接，從所述消息隊列讀取所述推理請求并進行推理處理。[0023]可選地，所述從所述消息隊列獲取所述推理請求并進行推理處理，包括：[0024]根據(jù)自身負載從所述消息隊列中讀取若干所述推理請求，并同時批量處理各所述推理請求。[0027]處理器，用于執(zhí)行所述計算機程序時實現(xiàn)基于服務(wù)實例的所述推理服務(wù)方法的步驟。[0028]一種推理服務(wù)系統(tǒng)，包括：客戶端、消息總線以及若干具有不同服務(wù)類型的服務(wù)實[0029]其中，所述客戶端，用于接收用戶發(fā)起的推理請求，并將所述推理去請求發(fā)送至所述消息總線；[0030]所述消息總線中包含若干消息隊列，所述消息總線用于接收到所述推理請求后，確定所述推理請求的服務(wù)類型；將所述推理請求添加至主題與所述服務(wù)類型相對應(yīng)的消息隊列中；向訂閱所述消息隊列的服務(wù)實例發(fā)送新請求通知；[0031]所述服務(wù)實例，用于接收所述新請求通知；根據(jù)自身負載以及服務(wù)可用性判斷是否可以承接所述推理請求；若可以承接，從所述消息隊列獲取所述推理請求并進行推理處[0033]所述服務(wù)管理器，用于服務(wù)管理器監(jiān)聽所述消息總線中各消息隊列的請求處理速度，生成請求處理監(jiān)聽記錄，根據(jù)所述請求處理監(jiān)聽記錄對所述服務(wù)實例進行擴縮容處理。[0034]可選地，所述服務(wù)管理器，具體用于：根據(jù)所述請求處理監(jiān)聽記錄確定目標消息隊列的請求處理速度；若所述請求處理速度低于第一閾值；添加與所述目標消息隊列的主題相對應(yīng)的服務(wù)類型的服務(wù)實例；若所述請求處理速度高于第二閾值；減少與所述目標消息隊列的主題相對應(yīng)的服務(wù)類型的服務(wù)實例；其中，所述第一閾值低于所述第二閾值。6[0035]本發(fā)明實施例所提供的方法，將模型推理服務(wù)無狀態(tài)、請求量波動較大的特點和消息總線易伸縮、高容錯的優(yōu)勢相結(jié)合，將推理請求的分配由代理服務(wù)主動選擇，變成由推理服務(wù)主動選擇，消息總線在接收到客戶端發(fā)送的推理請求后，將其投入至消息隊列中，并向訂閱該消息隊列的服務(wù)實例發(fā)送新請求通知，指示存在新請求到達消息隊列，服務(wù)實例在接收到新請求通知后可以根據(jù)自身的實際性能，包括負載情況以及可用性確定是否承接該請求，若可以承接，則從消息總線獲取推理請求并處理。這一請求的處理過程中服務(wù)實例根據(jù)自身實際性能進行請求的承接，不存在由于不了解實際性能造成的過載和空載的問題，保證了負載均衡，同時也不存在不可用但承接請求的問題，請求處理的成功率高；而且當(dāng)推理請求發(fā)送到消息總線后，即使由于網(wǎng)絡(luò)故障，推理服務(wù)無法接收到請求，該請求也可以在網(wǎng)絡(luò)恢復(fù)后繼續(xù)被處理，容錯性高；同時各服務(wù)實例可以同時進行請求的承接以及處[0036]相應(yīng)地，本發(fā)明實施例還提供了與上述推理服務(wù)方法相對應(yīng)的推理服務(wù)設(shè)備和系附圖說明[0037]為了更清楚地說明本發(fā)明實施例或相關(guān)技術(shù)中的技術(shù)方案，下面將對實施例或相關(guān)技術(shù)描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。[0038]圖1為一種傳統(tǒng)的代理結(jié)構(gòu)示意圖；[0039]圖2為本發(fā)明實施例中一種推理服務(wù)方法的信令圖；[0040]圖3為本發(fā)明實施例中一種消息總線的結(jié)構(gòu)示意圖；[0041]圖4為本發(fā)明實施例中一種計算機設(shè)備的結(jié)構(gòu)示意圖；[0042]圖5為本發(fā)明實施例中一種推理服務(wù)系統(tǒng)的結(jié)構(gòu)示意圖；[0043]圖6為本發(fā)明實施例中另一種推理服務(wù)系統(tǒng)的結(jié)構(gòu)示意圖。具體實施方式[0044]本發(fā)明的核心是提供一種推理服務(wù)方法，可以保證推理請求分配的均勻合理性，提升推理請求的響應(yīng)效率以及成功率。[0045]為了使本技術(shù)領(lǐng)域的人員更好地理解本發(fā)明方案，下面結(jié)合附圖和具體實施方式對本發(fā)明作進一步的詳細說明。顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。[0046]現(xiàn)有在線模型推理服務(wù)為了能夠同時提供多種模型服務(wù)以及滿足高并發(fā)要求，通例，以下簡稱為服務(wù)實例)以及服務(wù)管理器。[0047]基于上述代理結(jié)構(gòu)的一次推理請求處理過程如下：[0049]2、代理服務(wù)器根據(jù)推理請求的推理服務(wù)類型查詢服務(wù)管理器，獲得該推理服務(wù)的7所有服務(wù)實例(每種推理服務(wù)可能存在多個服務(wù)實例);[0050]3、代理服務(wù)器根據(jù)負載均衡策略(例如隨機選擇，最少鏈接數(shù)，輪詢RoundRobin等)使用路由算法將模型推理請求從所有實例中選擇一個空閑的服務(wù)實例；[0055]而其中，代理服務(wù)器選擇空閑服務(wù)實例時，代理服務(wù)器通常只能通過預(yù)先設(shè)置的性能規(guī)格(如每秒可處理請求數(shù))以及當(dāng)前正在處理的請求量對服務(wù)實例的負載量做大致判斷。但是服務(wù)實例實際運行過程中，其處理能力是會變化的，可能低于或者高于預(yù)先配置的性能規(guī)格，因此代理服務(wù)器無法準確知道每個服務(wù)實例的實際容量和壓力，因此無法實現(xiàn)準確地負載均衡，導(dǎo)致請求分配不均。而如果將請求轉(zhuǎn)發(fā)給已經(jīng)滿載的服務(wù)實例，則會導(dǎo)[0056]而且，代理服務(wù)器需要從服務(wù)管理器對服務(wù)實例進行監(jiān)控以及創(chuàng)建刪除管理中生成服務(wù)注冊表中獲取服務(wù)實例的地址，但是由于網(wǎng)絡(luò)同步延遲或失敗、或者推理服務(wù)未能及時更新自身信息等因素，導(dǎo)致服務(wù)管理器監(jiān)測生成的服務(wù)注冊表的信息可能是不準確，或者非實時的。這樣的情況下，服務(wù)實例就可能會因為使用了代理服務(wù)器返回的錯誤地址而導(dǎo)致請求失敗。[0057]另外，代理服務(wù)器是以同步的方式處理推理請求的，即將推理請求發(fā)送給推理服務(wù)后，需要等待服務(wù)實例處理完成返回推理結(jié)果，將推理結(jié)果返回給客戶端后才能啟動第二個推理請求的響應(yīng)。這一請求處理機制導(dǎo)致在多個推理請求處理時的處理時長較長；而且如果網(wǎng)絡(luò)故障或者推理服務(wù)故障，則會導(dǎo)致該推理請求失敗，無法進入下一個推理請求[0058]為解決傳統(tǒng)方法中出現(xiàn)的推理請求分配不均、服務(wù)實例信息不準確以及處理耗時長、容錯性較差等問題，本發(fā)明提出了一種推理服務(wù)方法，該方法采用的是基于消息總線的訂閱和發(fā)布的方式，請參考圖1,圖1為本發(fā)明實施例中一種推理服務(wù)方法的信令圖，該方法包括以下步驟：[0059]S110、客戶端接收用戶發(fā)起的推理請求，將推理請求發(fā)送至消息總線；[0060]推理請求由用戶在客戶端發(fā)起，推理請求中包含用戶需要調(diào)用模型進行推理計算的數(shù)據(jù)對象(比如文本、圖像、數(shù)據(jù))以及需要調(diào)用的模型類型，當(dāng)然，也可以包含其他類型的信息，本實施例中對于推理請求中包含的信息不做限定，足以指示服務(wù)實例完成推理服[0061]客戶端接收到用戶發(fā)起的推理請求后，將其發(fā)送至消息總線，將模型推理服務(wù)的特點(無狀態(tài)，請求量波動較大)和消息總線的優(yōu)勢(易伸縮，高容錯)相結(jié)合，可以有效地滿足模型推理服務(wù)的動態(tài)變化，提升模型服務(wù)的資源利用率，同時提升模型推理服務(wù)的健壯[0062]S120、消息總線接收到客戶端發(fā)送的推理請求后，確定推理請求的服務(wù)類型；[0063]消息總線可以接收來自任意客戶端的推理請求，消息總線中包含多個消息隊列的服務(wù)，每個消息隊列對應(yīng)一個主題(topiic)。生產(chǎn)方(即客戶端)將推理請求發(fā)布(publish)8到某個主題(topic)的消息隊列。消費方(即推理服務(wù))訂閱(subscribe)某個主題(topic)的消息隊列，當(dāng)該主題隊列中有請求時，則獲取請求并進行處理。[0064]具體地，在接收到某個客戶端發(fā)送的推理請求后，根據(jù)推理請求中的信息確定當(dāng)前推理請求所要請求服務(wù)的類型，即模型的類型或服務(wù)實例類型。確定推理請求的服務(wù)類型可以通過需要調(diào)用的模型類型來進一步分析確定，也可以在推理請求中設(shè)置響應(yīng)的服務(wù)類型字段，則直接讀取該字段內(nèi)容即可，對于服務(wù)類型的確定方式本實施例中不做限定，可以根據(jù)實際使用需要進行相應(yīng)設(shè)定。其中，服務(wù)類型的配置需與消息總線中消息隊列的主題對應(yīng)設(shè)置，以便根據(jù)服務(wù)類型就可以匹配到與服務(wù)類型對應(yīng)的主題，從而定位到某個消息隊列。而需要說明的是，一般來說服務(wù)類型與消息隊列的主題可以一一對應(yīng)設(shè)置，當(dāng)然，與服務(wù)類型匹配的主題(或消息隊列)也可以不止一個，與主題(或消息隊列)匹配的服務(wù)類型也可以不止一個，具體地服務(wù)類型與主題間的匹配關(guān)系可以根據(jù)實際模型服務(wù)調(diào)用需求[0065]S121、消息總線將推理請求添加至主題與服務(wù)類型相對應(yīng)的消息隊列中；[0066]匹配到可以滿足當(dāng)前推理請求的服務(wù)類型后，將推理請求添加至匹配的服務(wù)類型相對應(yīng)的消息隊列中，比如匹配的主題為圖像特征提取，而以圖像特征提取作為主題的消息隊列為消息隊列1,則將該推理請求添加至消息隊列1。一般向消息隊列中添加信息是按照先入先出的規(guī)則，則將該推理請求添加至消息隊列后，如果該消息隊列中存儲有其他未被處理完成的推理請求，則當(dāng)前推理請求放置在隊尾，在其他請求處理完成后才會處理，這一機制可以保障各個推理請求的處理時長平均化，不會出現(xiàn)等待時間過長的問題。[0067]S122、消息總線向訂閱消息隊列的服務(wù)實例發(fā)送新請求通知；[0068]服務(wù)實例與主題對應(yīng)的消息隊列建立訂閱關(guān)系，則在該服務(wù)實例訂閱的消息隊列中存入新請求后，就會向訂閱的服務(wù)實例發(fā)送新請求通知。新請求通知指示消息隊列中存在新的推理請求，但可能并非只有新的推理請求，歷史未處理的推理請求也可能排列其中，則空閑的各服務(wù)實例按照隊列中請求的排列順序依次拿取推理請求進行處理。[0069]S130、服務(wù)實例接收訂閱的消息總線中的消息隊列發(fā)送的新請求通知，根據(jù)自身負載以及服務(wù)可用性判斷是否可以承接推理請求；[0070]訂閱該主題(topic)的服務(wù)實例在接收到新請求通知后，該服務(wù)實例會根據(jù)自身的實際運行狀態(tài)判斷是否承接該推理請求，具體的運行狀態(tài)主要是自身負載情況以及服務(wù)可用性兩方面來判斷。[0071]S131、服務(wù)實例若可以承[0072]若服務(wù)實例自身對于該推理請求的推理服務(wù)可用，則指示自身具有承接該服務(wù)請求的能力，進一步地，如果該服務(wù)實例處于空閑狀態(tài)(包括無待處理的任務(wù)、處理能力超過目前待處理的任務(wù)量),即自身負載量較低，則服務(wù)實例就可以判定可以承接這個推理請[0073]反之，如果訂閱該主題(topic)的服務(wù)實例自身對于該推理請求的推理服務(wù)不可用，或者，自身負載較大(處理能力已達到超過目前待處理的任務(wù)量),則可以不承接當(dāng)前推理請求。而如果所有的推理服務(wù)都處于忙碌的狀態(tài)無法承接該推理請求，則該主題(topic)的請求數(shù)量會堆積，該隊列的處理速度變慢。[0074]本方法中對于推理請求的分配將傳統(tǒng)方法中代理服務(wù)分配轉(zhuǎn)換為由推理服務(wù)主9動選擇，該種方法下，推理服務(wù)可以根據(jù)自身的實際性能從消息總線獲取推理請求并處理，流量分配均勻，不存在過載和空載的問題。[0075]需要說明的是，在服務(wù)實例完成推理處理得到推理結(jié)果后，推理結(jié)果也會反饋至消息總線，由消息總線返回至客戶端。對于結(jié)果返回的過程可以參照請求發(fā)送的過程，在此不再贅述。[0076]基于上述介紹，本發(fā)明實施例所提供的技術(shù)方案，將模型推理服務(wù)無狀態(tài)、請求量波動較大的特點和消息總線易伸縮、高容錯的優(yōu)勢相結(jié)合，將推理請求的分配由代理服務(wù)主動選擇，變成由推理服務(wù)主動選擇，消息總線在接收到客戶端發(fā)送的推理請求后，將其投入至消息隊列中，并向訂閱該消息隊列的服務(wù)實例發(fā)送新請求通知，指示存在新請求到達消息隊列，服務(wù)實例在接收到新請求通知后可以根據(jù)自身的實際性能，包括負載情況以及可用性確定是否承接該請求，若可以承接，則從消息總線獲取推理請求并處理。這一請求的處理過程中服務(wù)實例根據(jù)自身實際性能進行請求的承接，不存在由于不了解實際性能造成的過載和空載的問題，同時也不存在不可用但承接請求的問題，請求處理的成功率高；而且當(dāng)推理請求發(fā)送到消息總線后，即使由于網(wǎng)絡(luò)故障，推理服務(wù)無法接收到請求，該請求也可以在網(wǎng)絡(luò)恢復(fù)后繼續(xù)被處理，容錯性高；同時各服務(wù)實例可以同時進行請求的承接以及處[0077]需要說明的是，基于上述實施例，本發(fā)明實施例還提供了相應(yīng)的改進方案。在優(yōu)選/改進實施例中涉及與上述實施例中相同步驟或相應(yīng)步驟之間可相互參考，相應(yīng)的有益效果也可相互參照，在本文的優(yōu)選/改進實施例中不再一一贅述。[0078]在上述實施例的基礎(chǔ)上，為進一步提升各服務(wù)實例從消息隊列中承接任務(wù)的規(guī)范性，避免多個服務(wù)實例同時處理一個推理請求對計算資源的浪費等問題，在向訂閱消息隊列的服務(wù)實例發(fā)送新請求通知之后，可以進一步執(zhí)行以下步驟：[0080]若服務(wù)實例判定自身可以承接該推理請求，則向消息總線發(fā)送請求處理通知，指示服務(wù)實例A處理推理請求B,消息總線接收到請求處理通知后，確定請求處理通知發(fā)送端要處理的請求(推理請求B),作為目標請求。[0081](2)向目標請求添加文件鎖；[0082]為避免多個空閑服務(wù)實例同時對一個推理請求進行處理造成的資源浪費等問題，可以在接收到請求處理通知后立即對目標請求添加文件鎖，保證第一個發(fā)起請求處理通知的服務(wù)實例可以獨自處理該推理請求，而其他空閑的服務(wù)實例無法處理該推理請求，保證推理請求處理的唯一性。[0084]在服務(wù)實例完成某一推理請求的處理后，向消息總線發(fā)送請求處理完成通知，請求處理完成通知指示服務(wù)實例A完成對于目標請求(推理請求B)的處理，此時就可以將該目標請求從消息隊列中刪除，以避免消息隊列中服務(wù)請求的堆積。[0085]而進一步地，為避免目標請求的處理陷入死循環(huán)，同時為了提升請求的處理效率，避免請求在隊列中堆積，在向目標請求添加文件鎖之后，可以進一步執(zhí)行以下步驟：若目標請求的處理異常，解開目標請求的文件鎖。[0086]若目標請求的處理異常，可以解開目標請求的文件鎖，解開目標請求的文件鎖后目標請求可以重新接受其他服務(wù)實例的承接處理(其他服務(wù)實例承接后也需要對其添加文件鎖),以加速目標請求的處理流轉(zhuǎn)。其中，目標請求處理異常的判定方式本實施例中不做限定，可以由服務(wù)實例向消息總線發(fā)送處理異常通知來確定，也可以由消息總線或其他設(shè)備對服務(wù)請求的處理過程進行監(jiān)控，若發(fā)生某些異?；蛱幚頃r間超出最大閾值，則判定異常。本實施例中僅以上述兩種異常判定方式為例進行介紹，其他異常判定方式均可參照本[0087]上述實施例中各服務(wù)實例間可以同時從消息隊列中獲取推理請求并同時進行推理處理，各服務(wù)實例間推理請求的異步處理可以顯著提升推理請求的整體處理速度。而為進一步提升推理請求的處理速度，從消息隊列獲取推理請求并進行推理處理的過程具體可以為：根據(jù)自身負載從消息隊列中讀取若干推理請求，并同時批量處理各推理請求。[0088]傳統(tǒng)方法中代理服務(wù)(根據(jù)類型)將推理請求發(fā)送給對應(yīng)的推理服務(wù)，(使用負載均衡的方法)將請求以均勻的方式發(fā)送給推理服務(wù)(每種類型的推理服務(wù)有多個實例),該種方式導(dǎo)致的結(jié)果就是，每個推理服務(wù)同時只處理一個請求。但是實際推理服務(wù)自身的處理能力是可以同時處理一批(多個)請求，并且耗時和同時處理一個請求的耗時是幾乎一樣個推理請求同時處理，這樣可以充分利用模型服務(wù)資源，很好地緩解偶發(fā)的，瞬間請求量暴增的問題，顯著提升推理服務(wù)的處理效率。[0089]相應(yīng)于上面的方法實施例，本發(fā)明實施例還提供了一種消息總線，下文描述的消息總線與上文描述的推理服務(wù)方法可相互對應(yīng)參照。[0090]如圖3所示為本實施例提供的一種消息總線示意圖，該消息總線中主要包括若干用于存儲服務(wù)請求的消息隊列，每個消息總線具有唯一的主題，主題用于指示存儲的推理請求的服務(wù)類型。[0091]具體地，在該種設(shè)置下的消息總線具體用于：接收到客戶端發(fā)送的推理請求后，確定推理請求的服務(wù)類型；將推理請求添加至主題與服務(wù)類型相對應(yīng)的消息隊列中；向訂閱消息隊列的服務(wù)實例發(fā)送新請求通知，以便服務(wù)實例根據(jù)自身負載以及服務(wù)可用性接收或拒絕推理請求的處理。該部分內(nèi)容的介紹可以參照上述方法實施例的介紹，在此不再贅述。[0092]相應(yīng)于上面的方法實施例，本發(fā)明實施例還提供了一種計算機設(shè)備，該計算機設(shè)備主要用于搭載服務(wù)實例，下文描述的一種計算機設(shè)備與上文描述的一種推理服務(wù)方法可相互對應(yīng)參照。[0093]該計算機設(shè)備具體可以為服務(wù)器、計算機等，該計算機[0095]處理器，用于執(zhí)行計算機程序時實現(xiàn)上述方法實施例的推理服務(wù)方法的步驟。[0096]具體的，請參考圖4,為本實施例提供的一種計算機設(shè)備的具體結(jié)構(gòu)示意圖，該計算機設(shè)備可因配置或性能不同而產(chǎn)生比較大的差異，可以包括一個或一個以上處理器(centralprocessingunits,CPU)322(例如，一個或一個以上處理器)和存儲器332,存儲器332存儲有一個或一個以上的計算機應(yīng)用程序342或數(shù)據(jù)344。其中，存儲器332可以是短暫存儲或持久存儲。存儲在存儲器332的程序可以包括一個或一個以上模塊(圖示沒標出),每個模塊可以包括對數(shù)據(jù)處理設(shè)備中的一系列指令操作。更進一步地，中央處理器322可以設(shè)置為與存儲器332通信，在計算機設(shè)備301上執(zhí)行存儲器332中的一系列指令操作。11[0097]計算機設(shè)備301還可以包括一個或一個以上電源326,一個或一個以上有線或無線網(wǎng)絡(luò)接口350,一個或一個以上輸入輸出接口358,和/或，一個或一個以上操作系統(tǒng)341。[0098]上文所描述的推理服務(wù)方法中以服務(wù)實例作為執(zhí)行主體的步驟可以由本實施例提供的計算機設(shè)備的結(jié)構(gòu)實現(xiàn)。[0099]相應(yīng)于上面的設(shè)備實施例，本發(fā)明實施例還提供了一種推理服務(wù)系統(tǒng)，下文描述的一種推理服務(wù)系統(tǒng)與上文描述的消息總線以及計算機設(shè)備可相互對應(yīng)參照。[0100]一種推理服務(wù)系統(tǒng)，具體包括：客戶端、消息總線以及若干具有不同服務(wù)類型的服務(wù)實例，如圖5為一種推理服務(wù)系統(tǒng)結(jié)構(gòu)示意圖。[0101]其中，客戶端主要用于與用戶交互，接收用戶發(fā)起的推理請求，并將推理去請求發(fā)送至消息總線；[0102]消息總線中包含若干消息隊列，消息總線用于接收到推理請求后，確定推理請求的服務(wù)類型；將推理請求添加至主題與服務(wù)類型相對應(yīng)的消息隊列中；向訂閱消息隊列的服務(wù)實例發(fā)送新請求通知；具體的消息總線的結(jié)構(gòu)以及工作過程可以參照上述消息總線實[0103]服務(wù)實例，用于接收新請求通知；根據(jù)自身負載以及服務(wù)可用性判斷是否可以承接推理請求；若可以承接，從消息隊列獲取推理請求并進行推理處理。服務(wù)實例搭載于計算機設(shè)備中，具體地服務(wù)實例的工作過程以及搭載的設(shè)備結(jié)構(gòu)也可以參照上述方法實施例以及計算機設(shè)備實施例的介紹，在此不再贅述。[0104]本實施例提供的推理服務(wù)系統(tǒng)中，通過客戶端獲取用戶的推理請求，并將其發(fā)送至消息總線，消息總線在接收到客戶端發(fā)送的推理請求后，將其投入至與推理請求的服務(wù)類型的消息隊列中，并向訂閱該消息隊列的服務(wù)實例發(fā)送新請求通知，指示存在新請求到達消息隊列，服務(wù)實例在接收到新請求通知后可以根據(jù)自身的實際性能，包括負載情況以及可用性確定是否承接該請求，若可以承接，則從消息總線獲取推理請求并處理。這一過程可以與上述方法實施例相互對照。通過設(shè)置由客戶端、消息總線以及若干具有不同服務(wù)類型的服務(wù)實例組成的推理服務(wù)系統(tǒng)，可以由消息總線實現(xiàn)服務(wù)實例主導(dǎo)的推理服務(wù)處理，保證請求的負載均衡性以及高效性。[0105]在一種實施例中，推理服務(wù)系統(tǒng)中可以進一步包括：與消息隊列連接的服務(wù)管理器，服務(wù)管理器指根據(jù)某些外部條件(例如請求量監(jiān)控數(shù)據(jù)、隊列排隊深度等),負責(zé)管理推理服務(wù)的創(chuàng)建，銷毀及信息查詢的設(shè)備，如圖6所示為本實施例中提供的一種推理服務(wù)系統(tǒng)結(jié)構(gòu)示意圖。[0106]服務(wù)管理器連接于消息總線以及各服務(wù)實例，可以監(jiān)聽消息總線中各消息隊列的請求處理速度，生成請求處理監(jiān)聽記錄，根據(jù)請求處理監(jiān)聽記錄對服務(wù)實例進行擴縮容處[0107]目前，傳統(tǒng)方法下服務(wù)管理器根據(jù)代理服務(wù)中每個推理服務(wù)的請求量和請求處理時間，增加或者減少推理服務(wù)數(shù)量。而由于代理服務(wù)對于推理請求的分配存在不均勻，推理請求的平均耗時偏高，導(dǎo)致服務(wù)管理器不能準確地判斷請求量的大小，無法準確的、實時的擴縮容(即增加或減少)推理服務(wù)數(shù)量。而且代理服務(wù)需要通過服務(wù)注冊表才能獲取推理服務(wù)的地址，但是由于網(wǎng)絡(luò)同步延遲或失敗，或者推理服務(wù)未能及時更新自身信息等因素，導(dǎo)致服務(wù)注冊表的信息可能是不準確、或者非實時的，這樣的情況下，推理服務(wù)實例的擴縮容周期較長，無法實時響應(yīng)推理請求量的變化，可能在請求量已經(jīng)下降之后才完成擴容，這時已經(jīng)失去意義。[0108]而本實施例提供的服務(wù)管理器中根據(jù)消息總線上的待處理請求數(shù)量的變化趨勢，可以準確地、實時地彈性增加或者減少模型服務(wù)實例。當(dāng)請求數(shù)量出現(xiàn)堆積的趨勢時，增加模型服務(wù)的實例數(shù)量，提升處理能力。當(dāng)請求數(shù)量處理速度加快時，減少模型服務(wù)的實例數(shù)量，減少處理能力。由于是根據(jù)請求數(shù)量的變化趨勢，這可以充分真實的反應(yīng)每個模型