rpc如何調用伺服器
Ⅰ UE4網路之（二） 遠程調用函數（RPC）
所有示例使用第三人稱模板創建的項目並帶有初始資源StarterContent
Function Replicateion（簡稱RPC）是在本地調用但在其他機器上遠程執行的函數。RPC可以實現客戶端或伺服器之間相互發送消息。RPC可以設置為Reliable或Unreliable，其中Reliable調用必定發生，而Unreliable調用可能會因為網路問題被丟棄。因此大多處理視覺效果的RPC應該設置為Unreliable來避免過多地佔用網路。
RPC主要包括Multicast（廣播）、Run On Server（在服務端執行）和Run On Owning Client（在客戶端執行）三種類型。其中廣播類型在伺服器上調用執行，然後自動轉發給客戶端；在服務端執行的函數有客戶端調用，然後僅在伺服器執行。在客戶端執行的函數由伺服器調用，然後僅在自己的客戶端上執行。
1、打開ThirdPersonBP/Blueprints中的ThirdPersonCharacter藍圖，添加一個按下空格時在玩家為之生成火焰特效的事件。藍圖非常簡單直接上圖。
2、更改Number of Players改為4後運行。
可以看到所有窗口只有自己按下空格時才鉛辯能生成火焰特效並且只能看到自己的特效。
3、在ThirdPersonCharacter藍圖添加一個MulticasTest事件並將Replicates設置為Multicast，將藍圖改為如圖所示。
4、點擊Play運行。
看到伺服器上生成的特效在所有客戶端都能看到，而客戶端生成的特效只有自己才能看到。
重復步驟3將Replicates分別改為Run On Server。此處直接上效果圖。
此時不論誰按空格鍵槐伏缺，只有伺服器上相應的角色可以生成特效，客戶端並不能看到任何效果。如果想要廳嫌在客戶端也能看到效果，我們需要確保特效設置為Replicates。
打開特效藍圖，並選中Replicates選項後重新開始運行。
1、打開ThirdPersonCharacter藍圖，創建一個String類型的變數Inventory並設置為Instance Editable和Replicated
2、添加按P鍵列印Inventory的事件藍圖。
3、在場景中添加一個Box Trigger
4、取消Rendering下面的Actor Hidden In Game
5、添加藍圖，重疊觸發器時，如果重疊發生在伺服器上，在伺服器上運行 Add Item 事件，並將它復制到自己的客戶端；當人物退出觸發器盒時，在伺服器上運行 Remove Item 事件，並將其復制到自己的客戶端。其中Add Item 和 Remove Item 事件為自定義事件，並且Replicates屬性全都為Run on owning Client。
6、編譯運行。
可以看出剛開始啟動時，每個角色列印的都為空，當一個角色進入觸發器後會顯示文本Item added ，按P時文本改為"has the item "，人物退出觸發器會列印「Item Removed」，再次按P會列印空字元
Ⅱ rpc伺服器不可用怎麼解決
在伺服器上運行 Dcpromo 時可能出現「RPC server is unavailable」錯誤。如果只有一台 DC，並且該 DC 的網卡上沒有啟鍵州用文件和列印機共享，則會發生此問穗握題。出現這種情況可以按照以下方法解決：
1、首先打開電腦的運行窗口，按下win+r即可打開，然後在裡面我們輸入services.msc。
(2)rpc如何調用伺服器擴展閱讀：
RPC採用客戶機/伺服器模式。請求程序就是一個客戶機，而服務提供程序就是一個伺服器。首先，調用進程發送一個有進程參數的調用信息到服務進程，然後等待應答信息。在伺服器端，進程保持睡眠狀態直到調用信息的到達為止。當一個調用信息到達，伺服器獲得進程參數，計算結果，發送答復信息，然後等待下一個調用信息，最後，客戶端調用過程接收答復信息，獲得進程結果，然後調用執行繼續進行。
Ⅲ rpc伺服器不可用怎麼辦
rpc伺服器是一種遠程的調用協議，對於需要使用遠程服務的用戶，比如遠程列印等，禁止後就會出現頌老悶rpc伺服器錯誤的提示。
rpc伺服器不可用野彎解決辦法如下：
工具／原料：matebook14、windows11、rpc伺服器2022。
1、【win+R】鍵打開【運行】，輸入「services.msc」。
Ⅳ 從 0 到 1：全面理解 RPC 遠程調用
責編 | 胡巍巍
什麼是RPC呢？網路給出的解釋是這樣的：「RPC（Remote Procere Call Protocol）——遠程過程調用協議，它是一種通過網路從遠程計算機程序上請求服務，而不需要了解底層網路技術的協議」。
這個概念聽起來還是比較抽象，沒關系，繼續往後看，後面概念性的東西，我會講得足夠清楚，讓你完全掌握 RPC 的基礎內容。
在 OpenStack 里的進程間通信方式主要有兩種，一種是基於HTTP協議的RESTFul API方式，另一種則是RPC調用。
那麼這兩種方式在應用場景上有何區別呢？
有使用經驗的人，就會知道：
首先，給你提兩個問題，帶著這兩個問題再往下看：
1、RPC 和 REST 區別是什麼？2、為什麼要採用RPC呢？
首先，第一個問題：RPC 和 REST 區別是什麼？
你一定會覺得這個問題很奇怪，是的，包括我，但是你在網路上一搜，會發現類似對比的文章比比皆是，我在想可能很多初學者由於基礎不牢固，才會將不相乾的二者拿出來對比吧。既然是這樣，那為了讓你更加了解陌生的RPC，就從你熟悉得不能再熟悉的 REST 入手吧。
01、所屬類別不同
REST，是Representational State Transfer 的簡寫，中文描述表述性狀態傳遞（是指某個瞬間狀態的資源數據的快照，包括資源數據的內容、表述格式(XML、JSON)等信息。）
REST 是一種軟體架構風格。這種風格的典型應用，就是HTTP。其因為簡單、擴展性強的特點而廣頃肢受開發者的青睞。
而RPC 呢，是 Remote Procere Call Protocol 的簡寫，中文描述是遠程過程調用，它可以實現客戶端像調用本地服務(方法)一樣調用伺服器的服務(方法)。
而 RPC 可以基於 TCP/UDP，也可以基於 HTTP 協議進行傳輸的，按理說它和REST不是一個層面意義上的東西，不應該放在一起討論，但是誰讓REST這么流行呢，它是目前最流行的一套互聯網應用程序的API設計標准，某種意義下，我們說 REST 可以其實就是指代 HTTP 協議。
02、使用方式不同
03、面向對象不同
從設計上來看，RPC，所謂的遠程過程調用 ，是面向方法的 ，REST：所謂的 Representational state transfer ，是面向資源的，除此之外，還有一種叫做 SOA，所謂的面向服務的架構，它是面向消息的，這個接觸不多，就不多說了。
04、序列化協議不同
介面調用通常包含兩個部分，序列化和通信協議。
通信協議，上面已經提及了，REST 是 基於 HTTP 協議，而 RPC 可以基於 TCP/UDP，也可以基於 HTTP 協議進行傳輸的。
常見的序列化協議，有：json、xml、hession、protobuf、thrift、text、bytes等，REST 通常使用的是 JSON或者XML，而 RPC 使用的是渣歷 JSON-RPC，或者 XML-RPC。
通過以上幾點，我們知道了 REST 和 RPC 之間有很明顯的差異。
然後第二個問題：為什麼要採用RPC呢？
那到底為何要使用 RPC，單純的依靠RESTful API不可以嗎？為什麼要搞這么多復雜的協議，渣渣表示真的學不過來了。
關於這一點，以下幾點僅是我的個人猜想，僅供交流哈：
說了這么多，我們該如何選擇這兩者呢？我總結了如下兩點，供你參考：
「遠程調用」意思就是：被調用方法的具體實現不在程序運行本地，而是在別的某個地方（分布到各個伺服器），調用者只想要函數運算的結果，卻不需要實現函數的具體細節。
光說不練嘴把式，接下來，我將分別用三種不同的方式全面地讓你搞明白 rpc 遠程調用是如何實現的。
01、基於 xml-rpc
Python實現 rpc，可以使用標准庫里的 SimpleXMLRPCServer，它是基於XML-RPC 協議的。
有了這個模塊，開如乎搜啟一個 rpc server，就變得相當簡單了。執行以下代碼：
有了 rpc server，接下來就是 rpc client，由於我們上面使用的是 XML-RPC，所以 rpc clinet 需要使用xmlrpclib 這個庫。
然後，我們通過 server_proxy 對象就可以遠程調用之前的rpc server的函數了。
SimpleXMLRPCServer是一個單線程的伺服器。這意味著，如果幾個客戶端同時發出多個請求，其它的請求就必須等待第一個請求完成以後才能繼續。
若非要使用 SimpleXMLRPCServer 實現多線程並發，其實也不難。只要將代碼改成如下即可。
02、基於json-rpc
SimpleXMLRPCServer 是基於 xml-rpc 實現的遠程調用，上面我們也提到 除了 xml-rpc 之外，還有 json-rpc 協議。
那 python 如何實現基於 json-rpc 協議呢？
答案是很多，很多web框架其自身都自己實現了json-rpc，但我們要獨立這些框架之外，要尋求一種較為干凈的解決方案，我查找到的選擇有兩種
第一種是 jsonrpclib
第二種是 python-jsonrpc
先來看第一種 jsonrpclib
它與 Python 標准庫的 SimpleXMLRPCServer 很類似（因為它的類名就叫做 SimpleJSONRPCServer ，不明真相的人真以為它們是親兄弟）。或許可以說，jsonrpclib 就是仿照 SimpleXMLRPCServer 標准庫來進行編寫的。
它的導入與 SimpleXMLRPCServer 略有不同，因為SimpleJSONRPCServer分布在jsonrpclib庫中。
服務端
客戶端
再來看第二種python-jsonrpc，寫起來貌似有些復雜。
服務端
客戶端
調用過程如下
還記得上面我提到過的 zabbix API，因為我有接觸過，所以也拎出來講講。zabbix API 也是基於 json-rpc 2.0協議實現的。
因為內容較多，這里只帶大家打個，zabbix 是如何調用的：直接指明要調用 zabbix server 的哪個方法，要傳給這個方法的參數有哪些。
03、基於 zerorpc
以上介紹的兩種rpc遠程調用方式，如果你足夠細心，可以發現他們都是http+rpc 兩種協議結合實現的。
接下來，我們要介紹的這種（zerorpc），就不再使用走 http 了。
zerorpc 這個第三方庫，它是基於TCP協議、 ZeroMQ 和 MessagePack的，速度相對快，響應時間短，並發高。zerorpc 和 pyjsonrpc 一樣，需要額外安裝，雖然SimpleXMLRPCServer不需要額外安裝，但是SimpleXMLRPCServer性能相對差一些。
調用過程如下
客戶端除了可以使用zerorpc框架實現代碼調用之外，它還支持使用「命令行」的方式調用。
客戶端可以使用命令行，那服務端是不是也可以呢？
是的，通過 Github 上的文檔幾個 demo 可以體驗到這個第三方庫做真的是優秀。
比如我們可以用下面這個命令，創建一個rpc server，後面這個 time Python 標准庫中的 time 模塊，zerorpc 會將 time 注冊綁定以供client調用。
經過了上面的學習，我們已經學會了如何使用多種方式實現rpc遠程調用。
通過對比，zerorpc 可以說是脫穎而出，一支獨秀。
為此，我也做了一番思考：
OpenStack 組件繁多，在一個較大的集群內部每個組件內部通過rpc通信頻繁，如果都採用rpc直連調用的方式，連接數會非常地多，開銷大，若有些 server 是單線程的模式，超時會非常的嚴重。
OpenStack 是復雜的分布式集群架構，會有多個 rpc server 同時工作，假設有 server01，server02，server03 三個server，當 rpc client 要發出rpc請求時，發給哪個好呢？這是問題一。
你可能會說輪循或者隨機，這樣對大家都公平。這樣的話還會引出另一個問題，倘若請求剛好發到server01，而server01剛好不湊巧，可能由於機器或者其他因為導致服務沒在工作，那這個rpc消息可就直接失敗了呀。要知道做為一個集群，高可用是基本要求，如果出現剛剛那樣的情況其實是很尷尬的。這是問題二。
集群有可能根據實際需要擴充節點數量，如果使用直接調用，耦合度太高，不利於部署和生產。這是問題三。
引入消息中間件，可以很好的解決這些問題。
解決問題一：消息只有一份，接收者由AMQP的負載演算法決定，默認為在所有Receiver中均勻發送(round robin)。
解決問題二：有了消息中間件做緩沖站，client 可以任性隨意的發，server 都掛掉了？沒有關系，等 server 正常工作後，自己來消息中間件取就行了。
解決問題三：無論有多少節點，它們只要認識消息中間件這一個中介就足夠了。
既然講到了消息隊列，如果你之前沒有接觸過這塊內容，最好花幾分鍾的時間跟我好好過下關於消息隊列的幾個基礎概念。
首先，RPC只是定義了一個通信介面，其底層的實現可以各不相同，可以是 socket，也可以是今天要講的 AMQP。
AMQP(Advanced Message Queuing Protocol)是一種基於隊列的可靠消息服務協議，作為一種通信協議，AMQP同樣存在多個實現，如Apache Qpid，RabbitMQ等。
以下是 AMQP 中的幾個必知的概念：
Publisher：消息發布者
Queue：用來保存消息的存儲空間，消息沒有被receiver前，保存在隊列中。
Exchange：用來接收Publisher發出的消息，根據Routing key 轉發消息到對應的Message Queue中，至於轉到哪個隊列里，這個路由演算法又由exchange type決定的。
Exchange type：主要四種描述exchange的類型。
direct：消息路由到滿足此條件的隊列中(queue,可以有多個)：routing key = binding key
topic：消息路由到滿足此條件的隊列中(queue,可以有多個)：routing key 匹配 binding pattern. binding pattern是類似正則表達式的字元串，可以滿足復雜的路由條件。
fanout：消息路由到多有綁定到該exchange的隊列中。
binding ：binding是用來描述exchange和queue之間的關系的概念，一個exchang可以綁定多個隊列，這些關系由binding建立。前面說的binding key /binding pattern也是在binding中給出。
為了讓你明白這幾者的關系，我畫了一張模型圖。
關於AMQP，有幾下幾點值得注意：
前面鋪墊了那麼久，終於到了講真實應用的場景。在生產中RPC是如何應用的呢？
其他模型我不太清楚，在 OpenStack 中的應用模型是這樣的
至於為什麼要如此設計，前面我已經給出了自己的觀點。
接下來，就是源碼解讀 OpenStack ，看看其是如何通過rpc進行遠程調用的。如若你對此沒有興趣（我知道很多人對此都沒有興趣，所以不浪費大家時間），可以直接跳過這一節，進入下一節。
目前Openstack中有兩種RPC實現，一種是在oslo messaging,一種是在openstack.common.rpc。
openstack.common.rpc是舊的實現，oslo messaging是對openstack.common.rpc的重構。openstack.common.rpc在每個項目中都存在一份拷貝，oslo messaging即將這些公共代碼抽取出來，形成一個新的項目。oslo messaging也對RPC API 進行了重新設計，對多種 transport 做了進一步封裝，底層也是用到了kombu這個AMQP庫。（註：Kombu 是Python中的messaging庫。Kombu旨在通過為AMQ協議提供慣用的高級介面，使Python中的消息傳遞盡可能簡單，並為常見的消息傳遞問題提供經過驗證和測試的解決方案。）
關於oslo_messaging庫，主要提供了兩種獨立的API:
因為 notify 實現是太簡單了，所以這里我就不多說了，如果有人想要看這方面內容，可以收藏我的博客(http://python-online.cn) ，我會更新補充 notify 的內容。
OpenStack RPC 模塊提供了 rpc.call，rpc.cast, rpc.fanout_cast 三種 RPC 調用方法，發送和接收 RPC 請求。
rpc.call 和 .rpc.cast 從實現代碼上看，他們的區別很小，就是call調用時候會帶有wait_for_reply=True參數，而cast不帶。
要了解 rpc 的調用機制呢，首先要知道 oslo_messaging 的幾個概念主要方法有四個：
transport：RPC功能的底層實現方法，這里是rabbitmq的消息隊列的訪問路徑
transport 就是定義你如何訪連接消息中間件，比如你使用的是 Rabbitmq，那在 nova.conf中應該有一行transport_url的配置，可以很清楚地看出指定了 rabbitmq 為消息中間件，並配置了連接rabbitmq的user，passwd，主機，埠。
target用來表述 RPC 伺服器監聽topic，server名稱和server監聽的exchange，是否廣播fanout。
rpc server 要獲取消息，需要定義target，就像一個門牌號一樣。
rpc client 要發送消息，也需要有target，說明消息要發到哪去。
endpoints：是可供別人遠程調用的對象
RPC伺服器暴露出endpoint，每個 endpoint 包涵一系列的可被遠程客戶端通過 transport 調用的方法。直觀理解，可以參考nova-conctor創建rpc server的代碼，這邊的endpoints就是 nova/manager.py:ConctorManager
dispatcher：分發器，這是 rpc server 才有的概念
只有通過它 server 端才知道接收到的rpc請求，要交給誰處理，怎麼處理？
在client端，是這樣指定要調用哪個方法的。
而在server端，是如何知道要執行這個方法的呢？這就是dispatcher 要乾的事，它從 endpoint 里找到這個方法，然後執行，最後返回。
Serializer：在 python 對象和message(notification) 之間數據做序列化或是反序列化的基類。
主要方法有四個：
每個notification listener都和一個executor綁定，來控制收到的notification如何分配。默認情況下，使用的是blocking executor(具體特性參加executor一節）
模仿是一種很高效的學習方法，我這里根據 OpenStack 的調用方式，抽取出核心內容，寫成一個簡單的 demo，有對 OpenStack 感興趣的可以了解一下，大部分人也可以直接跳過這章節。
注意以下代碼不能直接運行，你還需要配置 rabbitmq 的連接方式，你可以寫在配置文件中，通過 get_transport 從cfg.CONF 中讀取，也可以直接將其寫成url的格式做成參數，傳給 get_transport 。而且還要nova或者其他openstack組件的環境中運行（因為需要有ctxt這個環境變數）
簡單的 rpc client
簡單的 rpc server
【End】
熱 文 推 薦
☞Facebook 發幣 Libra；谷歌十億美金為窮人造房；第四代樹莓派 Raspberry Pi 4 發布 | 開發者周刊
☞WebRTC 將一統實時音視頻天下？
☞小米崔寶秋：小米 AIoT 深度擁抱開源
☞華為在美研發機構 Futurewei 意欲分家？
☞老司機教你如何寫出沒人敢維護的代碼！
☞Python有哪些技術上的優點？比其他語言好在哪兒？
☞上不了北大「圖靈」、清華「姚班」，AI專業還能去哪上？
☞公鏈史記 | 從鴻蒙初辟到萬物生長的十年激盪……
☞邊緣計算容器化是否有必要？
☞馬雲曾經偶像，終於把阿里留下的1400億敗光了！
你點的每個「在看」，我都認真當成了喜歡
Ⅳ rpc伺服器不可用 如何修復Windows上的RPC伺服器不可用錯誤
導致RPC錯誤的原因有很多。因此，每個問題也都有解決方案。嘗試所有這些以擺脫它：
1、方法1.確保RCP服務正常工作。單擊Win + R鍵以打開「 運行」窗口。鍵入services.msc，然後單擊Enter。在「 服務」窗口中，找到DCOM Server Process Launcher， 遠程過程調用（RPC）和RPC Endpoint Mapper。檢查其狀態是否設置為「正在運行」並將啟動設置為「 自動」。
2、方法2.檢查Windows防火牆設置。修復「RPC伺服器不可用」錯誤的另一種方法是檢查防火牆是否不阻止RPC連接。為了搏世州檢查Windows Defender防火牆是否存在任何問題，[2]請按照下列步驟操作：
打開「 開始」，然後在搜索框中鍵入防火牆。從結果中打開Windows Defender防火牆。在Windows Defender防火牆中，單擊 左窗格中的「 通過Windows Defender防火牆允許應用程序或功能」選項。在允許的應用和功能列表中，找到遠程協助並確保允許它。如果沒有，請單擊「 更改設置」按鈕並選中「 私人和公共」復選框。單擊「 確定」以保存更改。
3、方法3.檢查網路連接。
如果網路連接中斷，則「RPC伺服器不可用」錯誤可能也出現在屏幕上。要檢查它，請按照以下步驟操作：單擊Win + R鍵以打開「 運行」對話返宴框。在「運行」對話框窗口中鍵入ncpa.cpl，然後單擊「 輸入」。在「 網路連接」基蔽窗口中，右鍵單擊您使用的網路連接。從菜單中選擇「 屬性 」。檢查是否啟用了Microsoft網路和Internet協議版本6（TCP / IPv6）選項的文件 和列印機共享。如果沒有，請勾選復選框。
Ⅵ SOFARPC源碼解析-服務調用
簡介摘要
SOFARPC服務調用創建服務引用配置ConsumerConfig，自定義設置介面名稱、調用協議、直連調用地址以及連接超時時間等基礎配置；通過服務消費者啟動類ConsumerBootstrap引用服務，客戶端集群Cluster調跡沒用消費端調用器ConsumerInvoker實現Client發送數據給Server調用過程。
SOFARPC以基於Netty實現的網路通信框架SOFABolt用作遠程通信框架，使用者不用關心如何實現私有協議的細節，直接使用內置RPC通信協議，啟動客戶端與服務端同時注冊用戶請求處理器即可完成遠程調用：
1.調用方式
SOFARPC服務調用提供同步Sync、非同步Future、回調Callback以及單向Oneway四種調用類型：
使用Future非同步調用SOFABoot配置服務引用需要設置sofa:global-attrs元素的type屬性聲明調用方式為future：
如上設置為非同步調用的方式。客戶端獲取響應結果有兩種方式：
(1)通過 SofaResponseFuture直接獲取結果。第一個參數是獲取結果的超時時間，第二個參數表示是否清除線程上下文中的結果。
(2)獲取原生Futrue，該種方姿基納式獲取JDK原生的Future，參數表示是否清除線程上下文中的結果。因為響應結果放在JDK原生的Future，需要通過JDK Future的get()方法獲取響應結果。
當前線程發起調用得到RpcResponseFuture對象，當前線程可以繼續執行下一次調用。在任意時刻使用RpcResponseFuture對象的get()方法來獲取結果，如果響應已經回來此時就馬上得到結果；如果響應沒有回來則阻塞鋒粗住當前線程直到響應回來或者超時時間到。
(3)Callback回調調用
客戶端提前設置回調實現類，在發起調用後不會等待結果，是真正的非同步調用，永遠不會阻塞線程，結果處理是在非同步線程里執行。SOFA-RPC在獲取到服務端的介面後會自動執行該回調實現，目前支持 bolt 協議。客戶端回調類需要實現com.alipay.sofa.rpc.core.invoke.SofaResponseCallback介面：
如上設置是服務級別的設置，也可以進行調用級別的設置：
使用Callback回調調用SOFABoot配置服務引用需要設置sofa:global-attrs元素的type屬性聲明調用方式為callback，通過callback-ref屬性聲明回調的實現類，使用該服務引用發起調用時結果返回時由SOFARPC自動執行該回調類：
當前線程發起調用則本次調用馬上結束執行下一次調用。發起調用時需要注冊回調，該回調需要分配非同步線程池以待響應回來後在回調的非同步線程池來執行回調邏輯。
(4)Oneway單向調用
客戶端發送請求後不會等待服務端返回的結果，並且會忽略服務端的處理結果，目前支持bolt協議：
使用Oneway單向調用SOFABoot配置服務引用需要設置sofa:global-attrs元素的type屬性聲明調用方式為oneway：
當前線程發起調用後，不關心調用結果不做超時控制，只要請求已經發出就完成本次調用。單向調用不關心響應結果，請求線程不會被阻塞，使用Oneway調用需要注意控制調用節奏防止壓垮接收方。注意Oneway調用不保證成功，而且發起方無法知道調用結果。因此通常用於可以重試，或者定時通知類的場景，調用過程是有可能因為網路問題、機器故障等原因導致請求失敗，業務場景需要能接受這樣的異常場景才能夠使用。
2.直連調用
SOFARPC支持指定地址進行調用的場景，設置直連地址即可：
3.泛化調用
SOFARPC泛化調用方式能夠在客戶端不需要依賴服務端的介面情況下發起調用，目前支持bolt協議。由於不知道服務端的介面，因此需要通過字元串的方式將服務端的介面，調用的方法，參數及結果類進行描述：
如上通過setGeneric設置該服務為泛化服務，設置服務方的介面名。以GenericService作為泛化服務，通過GenericService能夠發起泛化調用。發起調用時需要傳入方法名、方法類型、方法參數。如果參數或者返回結果在客戶端也需要泛化表示則通過GenericObject來實現獲取序列化結果等：
(1)介面描述：所有泛化調用都需要在服務引用的時候聲明interface為com.alipay.sofa.rpc.api.GenericService，這是SOFARPC提供的類。真正的服務介面通過sofa:global-attrs元素的generic-interface屬性聲明完成介面的描述。
(2)參數描述：由於客戶端沒有調用服務的參數類，因此通過GenericObject進行描述，GenericObject持有Map<String, Object>類型的變數，能夠通過GenericObject提供的對該變數的操作方法將參數類的屬性放到Map以此來描述參數類。
(3)發起泛化調用：介面描述通過XML配置聲明泛化引用的bean，通過該泛化引用能夠發起服務調用，發起泛化調用的第一個參數就是方法名，第二個參數就是參數類的全類名，第三個參數就是描述參數類的 GenericObject。
(4)獲取泛化結果：發起泛化調用如果客戶端同樣沒有泛化結果的類，那麼同樣以GenericObject對調用結果進行描述，通過GenericObject的getField方法能夠獲取結果類的屬性值，通過GenericObject的getType方法能夠獲取結果類的全類名。
(5)泛化調用示例:SOFARPC泛化調用完整的泛化調用方式：
源碼解析
1.調用方式
參考sofa-rpc-boot-projects範例模塊( com.alipay.sofa.rpc.samples.invoke )：
運行調用方式服務端範例類InvokeServerApplication查看調用方式服務端輸出日誌：