[發(fā)明專利]一種遠(yuǎn)程過程調(diào)用處理方法、裝置及系統(tǒng)

有效

• 申請?zhí)枺?/td>: 201610050072.6
• 申請日: 2016-01-26
• 公開（公告）號: CN106998343B
• 公開（公告）日: 2020-11-03
• 發(fā)明（設(shè)計）人: 徐淀
• 申請（專利權(quán)）人: 創(chuàng)新先進(jìn)技術(shù)有限公司
• 主分類號: H04L29/08
• 分類號: H04L29/08;G06F9/46
• 代理公司: 北京三友知識產(chǎn)權(quán)代理有限公司 11127
• 代理人: 黨曉林

本申請?zhí)峁┮环N遠(yuǎn)程過程調(diào)用處理方法、裝置及系統(tǒng)。所述方法可以包括：接收請求方發(fā)送的服務(wù)請求消息；根據(jù)所述服務(wù)請求消息中的用戶標(biāo)識和請求數(shù)據(jù)字段在設(shè)置的接口配置數(shù)據(jù)中確定所述請求方調(diào)用的目標(biāo)服務(wù)；根據(jù)所述確定出的目標(biāo)服務(wù)執(zhí)行所述請求方的遠(yuǎn)程過程調(diào)用。利用本申請實施例可以對不同請求方實際的請求數(shù)據(jù)字段進(jìn)行分析處理，決策出各個請求方實際需要調(diào)用的RPC服務(wù)，從而實現(xiàn)根據(jù)不同請求方的數(shù)據(jù)字段實際所需的服務(wù)或者應(yīng)用發(fā)生RPC調(diào)用，大大減少不必要的RPC網(wǎng)絡(luò)調(diào)用開銷，提高API接口響應(yīng)效率。

技術(shù)領(lǐng)域

本申請屬于計算機數(shù)據(jù)處理領(lǐng)域，尤其涉及一種遠(yuǎn)程過程調(diào)用處理方法、裝置及系統(tǒng)。

背景技術(shù)

RPC(Remote Procedure Call，遠(yuǎn)程過程調(diào)用)是一種使用RPC協(xié)議，通過網(wǎng)絡(luò)從遠(yuǎn)程計算機程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的技術(shù)。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。

通常，RPC采用客戶端/服務(wù)器端模式，請求程序可以作為客戶端，服務(wù)提供程序可以作為服務(wù)器端。請求程序可以通過提供的API接口走開放平臺的方式調(diào)用服務(wù)器。目前，在多數(shù)實際業(yè)務(wù)應(yīng)用場景下，客戶端/服務(wù)器端模式通常包括多個用戶側(cè)的客戶端，而服務(wù)器端多采用分布式環(huán)境下的服務(wù)器集群，或者一個服務(wù)器中的多個服務(wù)提供應(yīng)用。對于同一 API接口，在開放給多個客戶端時，所述客戶端可以通過簽約的API接口請求需要的數(shù)據(jù)字段。不同的客戶端由于用戶不同、業(yè)務(wù)不同、需求不同等通常請求的數(shù)據(jù)字段也不一樣。由于存在大量簽約同一API接口且對接口返回數(shù)據(jù)字段需求不一，而API接口的實現(xiàn)層通常是在分布式環(huán)境下對多個服務(wù)器端的多次RPC調(diào)用后，然后對各調(diào)用結(jié)果進(jìn)行數(shù)據(jù)字段合并包裝后再對外通過網(wǎng)關(guān)進(jìn)行響應(yīng)輸出。目前現(xiàn)有RPC處理機制以數(shù)據(jù)字段全集為標(biāo)準(zhǔn)對這些數(shù)據(jù)字段所落在的下游服務(wù)系統(tǒng)進(jìn)行RPC遠(yuǎn)程調(diào)用，然后進(jìn)行包裝并返回給網(wǎng)關(guān)，網(wǎng)關(guān)再進(jìn)行字段過濾最終返回給發(fā)起請求的客戶端。網(wǎng)關(guān)層面所做的字段過濾發(fā)生在后置處理部分，即 API實現(xiàn)層已經(jīng)對各數(shù)據(jù)字段所處的下游服務(wù)系統(tǒng)發(fā)生了RPC網(wǎng)絡(luò)調(diào)用，冗余了網(wǎng)絡(luò)調(diào)用開銷，增加了API響應(yīng)時間。

圖1為現(xiàn)有技術(shù)中RPC處理過程的一種場景示意圖。如圖1所示，對外開放API數(shù)據(jù)接口可以依靠網(wǎng)關(guān)層面(Gateway)對各合作伙伴(請求客戶端)的數(shù)據(jù)字段實際需求進(jìn)行過濾輸出。而網(wǎng)關(guān)層面會把API接口請求分發(fā)給對應(yīng)的業(yè)務(wù)系統(tǒng)(API接口實現(xiàn)系統(tǒng))，API 接口實現(xiàn)層是按照接口返回的全集數(shù)據(jù)字段進(jìn)行返回，對各數(shù)據(jù)字段所處的下游系統(tǒng)均會發(fā)起串行RPC調(diào)用，即API接口實現(xiàn)是按照全集數(shù)據(jù)字段的標(biāo)準(zhǔn)進(jìn)行返回的，并不感知各合作伙伴對數(shù)據(jù)字段的需求不一，把數(shù)據(jù)字段全部返回給網(wǎng)關(guān)，然后由網(wǎng)關(guān)按照各合作伙伴實際需求進(jìn)行過濾輸出。具體的，例如圖1中的partner1實際數(shù)據(jù)字段需求為{field1,field2}，而API全集輸出字段為{field1,field2,field3,field4,field5,field6,field7}。現(xiàn)有的處理機制則會對上述全集輸出字段所處的下游服務(wù)系統(tǒng){app1,app2,app3,app4}均發(fā)生RPC調(diào)用，而對于partner1的實際數(shù)據(jù)字段需求而言并不需要執(zhí)行app2、app3、app4的RPC調(diào)用。

目前現(xiàn)有RPC處理機制會冗余大量RPC網(wǎng)絡(luò)開銷，增加了調(diào)用處理時間，降低API響應(yīng)效率。

發(fā)明內(nèi)容

本申請目的在于提供一種遠(yuǎn)程過程調(diào)用處理方法、裝置及系統(tǒng)，可以做到根據(jù)請求方實際數(shù)據(jù)字段需求進(jìn)行精準(zhǔn)的調(diào)用，大大減少RPC網(wǎng)絡(luò)調(diào)用開銷，提高API接口響應(yīng)效率。

本申請?zhí)峁┑囊环N遠(yuǎn)程過程調(diào)用處理方法、裝置及系統(tǒng)是這樣實現(xiàn)的：

一種遠(yuǎn)程過程調(diào)用處理方法，所述方法包括：

接收請求方發(fā)送的服務(wù)請求消息；