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 中的 dubbo-rpc-xml、dubbo-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 的接口。

dubbo-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”方案的落地实现。

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等语言实现，是很不错的及轻量级的远程调用协议。

最近刚加入区块链学习的热潮，从一些基本技术开始学起。本文翻译自 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

---