jsonrpcjava

❶ JSON-RPC輕量級遠程調用協議介紹及使用

json-rpc是基於json的跨語言遠程調用協議。比xml-rpc、webservice等基於文本的協議數據傳輸格小；相對hessian、java-rpc等二進制協議便於調試、實現、擴展，是很優秀的一種遠程調用協議。眼下主流語言都已有json-rpc的實現框架，java語言中較好的json-rpc實現框架有jsonrpc4j、jpoxy、json-rpc。三者之中jsonrpc4j既可獨立使用。又可與spring無縫集合，比較適合於基於spring的項目開發。

json-rpc協議很easy，發起遠程調用時向服務端數據傳輸格式例如以下：

{ "method": "sayHello", "params": ["Hello JSON-RPC"], "id": 1}

參數說明：

method： 調用的方法名

params： 方法傳入的參數。若無參數則傳入 []

id ： 調用標識符。用於標示一次遠程調用過程

server其收到調用請求，處理方法調用，將方法效用結果效應給調用方；返回數據格式：

參數說明:

result: 方法返回值。若無返回值。則返回null。

若調用錯誤，返回null。

error ：調用時錯誤，無錯誤返回null。

id : 調用標識符，與調用方傳入的標識符一致。

以上就是json-rpc協議規范，很easy，小巧。便於各種語言實現。

2.1、server端Java調用演示樣例

jsonrpc4jserver端java演示樣例：

2.2、Javaclient調用演示樣例

jsonrpc4j的Javaclient調用演示樣例：

2.3、JavaScriptclient調用演示樣例

基於jsonrpcjs的JavaScriptclient調用演示樣例：

2.4、直接GET請求進行調用

無需不論什麼client。僅僅需手工拼接參數進行遠程調用，請求URL例如以下：

參數說明:

method : 方法名

params ：調用參數。json的數組格式[], 將參數需先進行url編碼，再進行base64編碼

id : 調用標識符，隨意值。

json-rpc是一種很輕量級的跨語言遠程調用協議。實現及使用簡單。

僅需幾十行代碼，就可以實現一個遠程調用的client。方便語言擴展client的實現。

server端有php、java、python、ruby、.net等語言實現，是很不錯的及輕量級的遠程調用協議。

❷ Dubbo——HTTP 協議 + JSON-RPC

Protocol 還有一個實現分支是 AbstractProxyProtocol，如下圖所示：

從圖中我們可以看到：gRPC、HTTP、WebService、Hessian、Thrift 等協議對應的 Protocol 實現，都是繼承自 AbstractProxyProtocol 抽象類。

目前互聯網的技術棧百花齊放，很多公司會使用 Node.js、Python、Rails、Go 等語言來開發 一些 Web 端應用，同時又有很多服務會使用 Java 技術棧實現，這就出現了大量的跨語言調用的需求。Dubbo 作為一個 RPC 框架，自然也希望能實現這種跨語言的調用，目前 Dubbo 中使用「HTTP 協議 + JSON-RPC」的方式來達到這一目的，其中 HTTP 協議和 JSON 都是天然跨語言的標准，在各種語言中都有成熟的類庫。

下面就重點來分析 Dubbo 對 HTTP 協議的支持。首先，會介紹 JSON-RPC 的基礎，並通過一個示例，快速入門，然後介紹 Dubbo 中 HttpProtocol 的具體實現，也就是如何將 HTTP 協議與 JSON-RPC 結合使用，實現跨語言調用的效果。

Dubbo 中支持的 HTTP 協議實際上使用的是 JSON-RPC 協議。

JSON-RPC 是基於 JSON 的跨語言遠程調用協議。Dubbo 中的 bbo-rpc-xml、bbo-rpc-webservice 等模塊支持的 XML-RPC、WebService 等協議與 JSON-RPC 一樣，都是基於文本的協議，只不過 JSON 的格式比 XML、WebService 等格式更加簡潔、緊湊。與 Dubbo 協議、Hessian 協議等二進制協議相比，JSON-RPC 更便於調試和實現，可見 JSON-RPC 協議還是一款非常優秀的遠程調用協議。

在 Java 體系中，有很多成熟的 JSON-RPC 框架，例如 jsonrpc4j、jpoxy 等，其中，jsonrpc4j 本身體積小巧，使用方便，既可以獨立使用，也可以與 Spring 無縫集合，非常適合基於 Spring 的項目。

下面先來看看 JSON-RPC 協議中請求的基本格式：

JSON-RPC請求中各個欄位的含義如下：

在 JSON-RPC 的服務端收到調用請求之後，會查找到相應的方法並進行調用，然後將方法的返回值整理成如下格式，返回給客戶端：

JSON-RPC響應中各個欄位的含義如下：

Dubbo 使用 jsonrpc4j 庫來實現 JSON-RPC 協議，下面使用 jsonrpc4j 編寫一個簡單的 JSON-RPC 服務端示常式序和客戶端示常式序，並通過這兩個示常式序說明 jsonrpc4j 最基本的使用方式。

首先，需要創建服務端和客戶端都需要的 domain 類以及服務介面。先來創建一個 User 類，作為最基礎的數據對象：

接下來創建一個 UserService 介面作為服務介面，其中定義了 5 個方法，分別用來創建 User、查詢 User 以及相關信息、刪除 User：

UserServiceImpl 是 UserService 介面的實現類，其中使用一個 ArrayList 集合管理 User 對象，具體實現如下：

整個用戶管理業務的核心大致如此。下面我們來看服務端如何將 UserService 與 JSON-RPC 關聯起來。

首先，創建 RpcServlet 類，它是 HttpServlet 的子類，並覆蓋了 HttpServlet 的 service() 方法。我們知道，HttpServlet 在收到 GET 和 POST 請求的時候，最終會調用其 service() 方法進行處理；HttpServlet 還會將 HTTP 請求和響應封裝成 HttpServletRequest 和 HttpServletResponse 傳入 service() 方法之中。這里的 RpcServlet 實現之中會創建一個 JsonRpcServer，並在 service() 方法中將 HTTP 請求委託給 JsonRpcServer 進行處理：

最後，創建一個 JsonRpcServer 作為服務端的入口類，在其 main() 方法中會啟動 Jetty 作為 Web 容器，具體實現如下：

這里使用到的 web.xml 配置文件如下：

完成服務端的編寫之後，下面再繼續編寫 JSON-RPC 的客戶端。在 JsonRpcClient 中會創建 JsonRpcHttpClient，並通過 JsonRpcHttpClient 請求服務端：

在 AbstractProxyProtocol 的 export() 方法中，首先會根據 URL 檢查 exporterMap 緩存，如果查詢失敗，則會調用 ProxyFactory.getProxy() 方法將 Invoker 封裝成業務介面的代理類，然後通過子類實現的 doExport() 方法啟動底層的 ProxyProtocolServer，並初始化 serverMap 集合。具體實現如下：

在 HttpProtocol 的 doExport() 方法中，與前面介紹的 DubboProtocol 的實現類似，也要啟動一個 RemotingServer。為了適配各種 HTTP 伺服器，例如，Tomcat、Jetty 等，Dubbo 在 Transporter 層抽象出了一個 HttpServer 的介面。

bbo-remoting-http 模塊的入口是 HttpBinder 介面，它被 @SPI 註解修飾，是一個擴展介面，有三個擴展實現，默認使用的是 JettyHttpBinder 實現，如下圖所示：

HttpBinder 介面中的 bind() 方法被 @Adaptive 註解修飾，會根據 URL 的 server 參數選擇相應的 HttpBinder 擴展實現，不同 HttpBinder 實現返回相應的 HttpServer 實現。HttpServer 的繼承關系如下圖所示：

這里以 JettyHttpServer 為例簡單介紹 HttpServer 的實現，在 JettyHttpServer 中會初始化 Jetty Server，其中會配置 Jetty Server 使用到的線程池以及處理請求 Handler：

可以看到 JettyHttpServer 收到的全部請求將委託給 DispatcherServlet 這個 HttpServlet 實現，而 DispatcherServlet 的 service() 方法會把請求委託給對應接埠的 HttpHandler 處理：

了解了 Dubbo 對 HttpServer 的抽象以及 JettyHttpServer 的核心之後，回到 HttpProtocol 中的 doExport() 方法繼續分析。

在 HttpProtocol.doExport() 方法中會通過 HttpBinder 創建前面介紹的 HttpServer 對象，並記錄到 serverMap 中用來接收 HTTP 請求。這里初始化 HttpServer 以及處理請求用到的 HttpHandler 是 HttpProtocol 中的內部類，在其他使用 HTTP 協議作為基礎的 RPC 協議實現中也有類似的 HttpHandler 實現類，如下圖所示：

在 HttpProtocol.InternalHandler 中的 handle() 實現中，會將請求委託給 skeletonMap 集合中記錄的 JsonRpcServer 對象進行處理：

skeletonMap 集合中的 JsonRpcServer 是與 HttpServer 對象一同在 doExport() 方法中初始化的。最後，我們來看 HttpProtocol.doExport() 方法的實現：

介紹完 HttpProtocol 暴露服務的相關實現之後，下面再來看 HttpProtocol 中引用服務相關的方法實現，即 protocolBindinRefer() 方法實現。該方法首先通過 doRefer() 方法創建業務介面的代理，這里會使用到 jsonrpc4j 庫中的 JsonProxyFactoryBean 與 Spring 進行集成，在其 afterPropertiesSet() 方法中會創建 JsonRpcHttpClient 對象：

下面來看 doRefer() 方法的具體實現：

在 AbstractProxyProtocol.protocolBindingRefer() 方法中，會通過 ProxyFactory.getInvoker() 方法將 doRefer() 方法返回的代理對象轉換成 Invoker 對象，並記錄到 Invokers 集合中，具體實現如下：

本文重點介紹了在 Dubbo 中如何通過「HTTP 協議 + JSON-RPC」的方案實現跨語言調用。首先介紹了 JSON-RPC 中請求和響應的基本格式，以及其實現庫 jsonrpc4j 的基本使用；接下來我們還詳細介紹了 Dubbo 中 AbstractProxyProtocol、HttpProtocol 等核心類，剖析了 Dubbo 中「HTTP 協議 + JSON-RPC」方案的落地實現。

❸ jsonrpc容易維護嗎

容易。根據查詢jsonrpc資料顯示，jsonrpc容易維護，一款使用PHP開發的高性能Json Rpc框架，框架使用TCP/IP協議直接傳輸json數據，系統集成統計監控模塊，開發部署維護非常簡單。

❹ 技術基礎--JSON-RPC2.0

最近剛加入區塊鏈學習的熱潮，從一些基本技術開始學起。本文翻譯自 JSON-RPC 2.0 Specification . 其實協議很簡單，本不需要翻譯，主要是為了記錄這個學習過程，以及加深理解。

JSON是一種輕量級的數據交換格式。它可以地標數字，字元串，有序數組，以及鍵值對。
而JSON-RPC是一種無狀態的，輕量級的遠程程序調用協議。不只一種數據結構及其處理規則可以符合這種定義。數據通過socket, http, 或其他環境傳輸，並不能確定其將在本進程內使用。它使用JSON來座位數據格式。
設計也很簡單。

關鍵詞「MUST」, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"的解釋可以在RFC2119中找到。
由於採用了JSON協議，其可傳輸的數據類型也和JSON相同。JSON可以表示四種基本類型， Strings, Numbers, Booleans, Null，還有兩種結構類型：Objects， Arrays。當我們提到「基本類型」的時候，是指四種基本的JSON類型，而「結構類型」則指代以上兩種JSON結構類型。當提到JSON類型時，總會把第一個字母大寫，比如Object, Array, String, Number, Boolean, Null. True和False也是如此。

JSON-RPC 2.0定義的請求對象和響應對象和現有的JSON-RPC 1.0客戶端/伺服器有兼容問題。這兩個版本其實很好區分，2.0定義了一個叫"jsonrpc"的成員，其值時2.0，而1.0版本沒有。2.0的實現往往要兼容1.0的對象，即使我們在開發點對點以外或者明顯不是1.0的業務的時候亦是如此。

RPC調用是指發送一個請求對象到遠程伺服器上。請求對象包括以下成員：
jsonrpc: 用來聲明JSON-RPC協議的版本，固定為「2.0」
method：需要調用的方法。方法名以單詞rpc開頭，後面跟上期限字元，這個欄位在rpc交互的方法及其擴展上被存儲起來，並且不能用於其他意義。
params: 結構化的值，用於存儲方法響應需要用到的參數，且不能被省略。
id：客戶端分配的一個標識符，可以包含字元串，數字或者為空。如果沒有id，就會被當成是廣播通知。這個值一般不能為Null，且為數字時不能有小數。如果請求中含有這個欄位，伺服器在響應時，必須原樣返回該欄位，用來關聯以下兩個對象的不同環境：

當請求參數中不發送id成員時，該請求會被當作通知處理。對於通知，客戶端不關心響應對象，因為服務端也沒必要返回響應對象，確切的說，服務端不準答復一個通知請求，即便這個請求是批處理請求中的一個。
根據這個定義，通知請求並不會被確認，因為客戶端不會收到響應對象，更進一步說，通知請求的客戶端無法感知到錯誤，比如參數錯誤/網路錯誤等。

RPC調用的參數必須是結構化的值(對象或者數組)，對象通過名字遍歷，而數組通過位置可遍歷。
數組參數的遍歷順序必須與服務端順序一致。
對象參數的成員值必須與服務端期望的一致，且在大小寫上精確匹配。一旦有成員缺失，會導致錯誤產生。

當RPC請求出錯時，伺服器響應的Response對象中，必須包含error，且包含以下成員：
code: Number類型，表示出錯類型
message: String類型 簡介的一句話來描述錯誤
data: 可以是基本類型，也可以是結構類型，來表示錯誤的額外信息，且可以預設。具體取值由伺服器自定義，比如錯誤詳情，訪問限制等等。
-32768到-32000之間的錯誤碼是系統保留錯誤碼，協議預定義方便未來使用。錯誤碼的定義和XML-RPC類似：
-32700: 解析錯誤，無效的JSON結構，伺服器在解析JSON時出錯
-32600: 請求無效，Request對象不是一個合法的JSON請求
-32601: 未知的方法，伺服器未定義該method，或者該方法不可用
-32602: 參數錯誤
-32603: 網路錯誤
-32000--32099: 伺服器錯誤，伺服器其他錯誤的保留錯誤碼
上述區間以外的錯誤碼可在應用開發時使用。

同時發送多個Request對象時， 客戶端可以把請求都放到一個數組里一起發送。
服務端收到Request對象數組並處理完成後，應當以數組的形式返回，且數組中包含了響應的請求的Response對象。每一個請求對應一個響應，如果請求是通知的話，則不包含該Response對象。服務端在批處理請求任務時，可以按任何順序或者並行化處理。
服務端對請求進行批處理時者不是至少長度為1的合法請求對象數組時，伺服器響應的對象必須是一個單的Response對象。如果沒有Response數組中不包含Response對象，那也不能返回空數組，而應該什麼都不返回。

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

--> {"jsonrpc": "2.0", "method": "subtract", "params": [23, 42], "id": 2}<-- {"jsonrpc": "2.0", "result": -19, "id": 2}

--> {"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend": 23, "minuend": 42}, "id": 3}<-- {"jsonrpc": "2.0", "result": 19, "id": 3}--> {"jsonrpc": "2.0", "method": "subtract", "params": {"minuend": 42, "subtrahend": 23}, "id": 4}<-- {"jsonrpc": "2.0", "result": 19, "id": 4}

--> {"jsonrpc": "2.0", "method": "update", "params": [1,2,3,4,5]}
--> {"jsonrpc": "2.0", "method": "foobar"}

--> {"jsonrpc": "2.0", "method": "foobar", "id": "1"}
<-- {"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "1"}

--> {"jsonrpc": "2.0", "method": "foobar, "params": "bar", "baz]
<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null}

--> {"jsonrpc": "2.0", "method": 1, "params": "bar"}
<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}

--> [ {"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"}, {"jsonrpc": "2.0", "method"]<-- {"jsonrpc": "2.0", "error": {"code": -32700, "message": "Parse error"}, "id": null}

--> []<-- {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}

--> [1]
<-- [ {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}]

--> [1,2,3]
<-- [ {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}, {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}, {"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null}]

--> [
{"jsonrpc": "2.0", "method": "sum", "params": [1,2,4], "id": "1"},
{"jsonrpc": "2.0", "method": "notify_hello", "params": [7]},
{"jsonrpc": "2.0", "method": "subtract", "params": [42,23], "id": "2"},
{"foo": "boo"},
{"jsonrpc": "2.0", "method": "foo.get", "params": {"name": "myself"}, "id": "5"},
{"jsonrpc": "2.0", "method": "get_data", "id": "9"}
]
<-- [
{"jsonrpc": "2.0", "result": 7, "id": "1"},
{"jsonrpc": "2.0", "result": 19, "id": "2"},
{"jsonrpc": "2.0", "error": {"code": -32600, "message": "Invalid Request"}, "id": null},
{"jsonrpc": "2.0", "error": {"code": -32601, "message": "Method not found"}, "id": "5"},
{"jsonrpc": "2.0", "result": ["hello", 5], "id": "9"}
]

--> [
{"jsonrpc": "2.0", "method": "notify_sum", "params": [1,2,4]},
{"jsonrpc": "2.0", "method": "notify_hello", "params": [7]}
]
<-- //Nothing is returned for all notification batches

使用rpc開頭的方法名是系統擴展方法，且不能用於其他場合。每一個系統擴展都在相關聲明中定義。系統擴展是可選的。

1）如何撰寫一個規范，或者說一個規范由哪些部分組成，本規范是一個很好的模版
2）如何做前後兼容。jsonrpc的兼容方式很簡單，在請求頭部擴展一個jsonrpc的版本號即可。如果是良好的設計，在1.0的時候就應該加上此欄位。
3）嚴謹性。比如，我們不能簡單的使用Null作為id參數來表示通知，服務端解析id失敗也返回Null的id，無法區分這兩種情形。
4）批處理。一個好的設計必然要考慮多任務的批處理，在設計批處理時，需要考慮數據的解析，伺服器可能不按序處理，以及可能並發處理，需要考慮不同的請求在不同的時許下處理可能產生的影響
5）舉例。和測試用例的設計有點類似，盡可能覆蓋全面

JSON-RPC 2.0 Specification

❺ 微服務跨語言調用（摘選）

微服務架構已成為目前互聯網架構的趨勢，關於微服務的討論，幾乎占據了各種技術大會的絕大多數版面。國內使用最多的服務治理框架非阿里開源的 bbo 莫屬，千米網也選擇了 bbo 作為微服務治理框架。另一方面，和大多數互聯網公司一樣，千米的開發語言是多樣的，大多數後端業務由 java 支撐，而每個業務線有各自開發語言的選擇權，便出現了 nodejs，python，go 多語言調用的問題。

跨語言調用是一個很大的話題，也是一個很有挑戰的技術活，目前業界經常被提及的解決方案有如下幾種，不妨拿出來老生常談一番：

當我們再聊跨語言調用時我們在聊什麼？縱觀上述幾個較為通用，成熟的解決方案，可以得出結論：解決跨語言調用的思路無非是兩種：

如果一個新型的團隊面臨技術選型，我認為上述的方案都可以納入參考，可考慮到遺留系統的兼容性問題

舊系統的遷移成本

這也關鍵的選型因素。我們做出的第一個嘗試，便是在 RPC 協議上下功夫。

通用協議的跨語言支持

springmvc的美好時代

springmvc

springmvc

在沒有實現真正的跨語言調用之前，想要實現「跨語言」大多數方案是使用 http 協議做一層轉換，最常見的手段莫過於藉助 springmvc 提供的 controller/restController，間接調用 bbo provider。這種方案的優勢和劣勢顯而易見

通用協議的支持

事實上，大多數服務治理框架都支持多種協議，bbo 框架除默認的 bbo 協議之外，還有當當網擴展的 rest協議和千米網擴展的 json-rpc 協議可供選擇。這兩者都是通用的跨語言協議。

rest 協議為滿足 JAX-RS 2.0 標准規范，在開發過程中引入了 @Path，@POST，@GET 等註解，習慣於編寫傳統 rpc 介面的人可能不太習慣 rest 風格的 rpc 介面。一方面這樣會影響開發體驗，另一方面，獨樹一幟的介面風格使得它與其他協議不太兼容，舊介面的共生和遷移都無法實現。如果沒有遺留系統，rest 協議無疑是跨語言方案最簡易的實現，絕大多數語言支持 rest 協議。

和 rest 協議類似，json-rpc 的實現也是文本序列化&http 協議。bbox 在 restful 介面上已經做出了嘗試，但是 rest 架構和 bbo 原有的 rpc 架構是有區別的，rest 架構需要對資源(Resources)進行定義， 需要用到 http 協議的基本操作 GET、POST、PUT、DELETE。在我們看來，restful 更合適互聯網系統之間的調用，而 rpc 更適合一個系統內的調用。使用 json-rpc 協議使得舊介面得以兼顧，開發習慣仍舊保留，同時獲得了跨語言的能力。

千米網在早期實踐中採用了 json-rpc 作為 bbo 的跨語言協議實現，並開源了基於 json-rpc 協議下的 python 客戶端 bbo-client-py 和 node 客戶端 bbo-node-client，使用 python 和 nodejs 的小夥伴可以藉助於它們直接調用 bbo-provider-java 提供的 rpc 服務。系統中大多數 java 服務之間的互相調用還是以 bbo 協議為主，考慮到新舊協議的適配，在不影響原有服務的基礎上，我們配置了雙協議。

bbo 協議主要支持 java 間的相互調用，適配老介面；json-rpc 協議主要支持異構語言的調用。

定製協議的跨語言支持

微服務框架所謂的協議(protocol)可以簡單理解為：報文格式和序列化方案。服務治理框架一般都提供了眾多的協議配置項供使用者選擇，除去上述兩種通用協議，還存在一些定製化的協議，如 bbo 框架的默認協議：bbo 協議以及 motan 框架提供的跨語言協議：motan2。

motan2協議的跨語言支持

                                                                                                            motan2

motan2

motan2 協議被設計用來滿足跨語言的需求主要體現在兩個細節中—MetaData 和 motan-go。在最初的 motan 協議中，協議報文僅由 Header+Body 組成，這樣導致 path，param，group 等存儲在 Body 中的數據需要反序列得到，這對異構語言來說是很不友好的，所以在 motan2 中修改了協議的組成；weibo 開源了 motan-go ，motan-php ，motan-openresty ,並藉助於 motan-go 充當了 agent 這一翻譯官的角色，使用 simple 序列化方案來序列化協議報文的 Body 部分（simple 序列化是一種較弱的序列化方案）。

                                                                                                        agent

agent

仔細揣摩下可以發現這么做和雙協議的配置區別並不是大，只不過這里的 agent 是隱式存在的，與主服務共生。明顯的區別在於 agent 方案中異構語言並不直接交互。

bbo協議的跨語言支持

bbo 協議設計之初只考慮到了常規的 rpc 調用場景，它並不是為跨語言而設計，但跨語言支持從來不是只有支持、不支持兩種選擇，而是要按難易程度來劃分。是的，bbo 協議的跨語言調用可能並不好做，但並非無法實現。千米網便實現了這一點，nodejs 構建的前端業務是異構語言的主戰場，最終實現了 bbo2.js，打通了 nodejs 和原生 bbo 協議。作為本文第二部分的核心內容，重點介紹下我們使用 bbo2.js 幹了什麼事。

Dubbo協議報文格式

                                                                                                        bbo協議

bbo協議

bbo協議報文消息頭詳解：

magic：類似java位元組碼文件里的魔數，用來判斷是不是 bbo 協議的數據包。魔數是常量 0xdabb

flag：標志位, 一共8個地址位。低四位用來表示消息體數據用的序列化工具的類型（默認 hessian），高四位中，第一位為 1 表示是 request 請求，第二位為 1 表示雙向傳輸（即有返回 response），第三位為 1 表示是心跳 ping 事件。

status：狀態位, 設置請求響應狀態，bbo 定義了一些響應的類型。具體類型見com.alibaba.bbo.remoting.exchange.Response

invoke id：消息 id, long 類型。每一個請求的唯一識別 id（由於採用非同步通訊的方式，用來把請求 request 和返回的 response 對應上）

body length：消息體 body 長度, int 類型，即記錄 Body Content 有多少個位元組

body content：請求參數，響應參數的抽象序列化之後存儲於此。

協議報文最終都會變成位元組，使用 tcp 傳輸，任何語言只要支持網路模塊，有類似 Socket 之類的封裝，那麼通信就不成問題。那，跨語言難在哪兒？以其他語言調用 java 來說，主要有兩個難點：

ps：bbo 協議通訊demo（ https://github.com/lexburner/Dubbojs-Learning ）

❻ thinkphp jsonrpc java怎麼調用

• 服務端示例:

<?php

namespace RpcController;

use ;

class JsonApiController extends JsonRpcController

{

public function index(){

return 'Hello, JsonRPC!';

}

// 支持參數傳入

public function test($name=''){

return "Hello, {$name}!";

}

}

• 客戶端示例：

vendor('jsonRPC.jsonRPCClient');

$client = new jsonRPCClient('http://www.tp.cn/index.php/Rpc/JsonApi');

$result = $client->index();

var_mp($result); // 結果：Hello, JsonRPC!

$result = $client->test('deeka');

var_mp($result); // 結果：Hello, deeka!

❼ jsonrpc java怎麼運行

JSON-RPC-Java 由兩個對用戶可視化的組件構成，它們是JSONRPCBridge和JSONRPCServlet，二者的協調實現了JSON伺服器端對請求對象的處理，並響應給用戶。
JSONRPCBridge是一個擁有伺服器端導出給特定客戶端的對象的引用的session對象，它接收伺服器（也就是JSONRPCServlet）傳來的JSON-RPC請求，然後其把JSON對象解碼（unmarshalling）為Java對象，再扮演方法調用的角色，還要把方法調用返回的Java對象結果組碼（marshall）為JSON對象傳給客戶端處理。而具體的從Java對象到Javascript對象的類型轉換由負責串列化的串列化類Serializer處理。

JSONRPCBridge必須放置在HttpSession對象中，並且注冊屬性名為「JSONRPCBridge」，以使JSONRPCServlet能夠定位負責調用導出到客戶端的Java對象的橋。為此，為了導出一個對象的所有實例和靜態方法到客戶端，應該有如下的代碼： JSONRPCBridge.registerObject("myObject", myObject)；

為了導出一個類的所有的靜態方法，應該：JSONRPCBridge.registerClass(("myObject", myObject)；

如果registerObject和registerClass被多次調用為有相同鍵值的對象使用，那麼其將被最新賦值的對象所更新。

在JSON中，還可以使用單例模式的globalBridge來為所有的HTTP客戶端導出所有的實例方法。其可以用來注冊工廠類，但使用時要注意認證與安全問題。使用時如下標識：JSONRPCBridge.getGlobalBridge().registerObject("myObject",myObject); 同上其還可以導出所有的靜態方法。

該協議中最重要的一部分還有就是Servlet了，現在就來簡單的介紹一下：

在該協議中，JSONRPCServlet充當傳送器，處理通過HTTP傳輸過來的JSON