jsonrpcpython

① python怎么把json文件转换成字符串

1、说明：

json文件本身就是字符串文件，使用open函数就可以得到文件字符串内容，如果要解析文件则使用python3通过json模块load函数来实现。
2、代码示例：
首先编写一个json文件j.txt,内容如下：
{"errno":1,"errmsg":"操作成功！","data":[]}
python代码如下：

import json
# 读取文件内容
whth open('j.txt', 'r') as fr:
print(fr.read())
输出如下：
{"errno":1,"errmsg":"操作成功！","data":[]}

# 解析json文件
with open('j.txt', 'r') as fr:
o = json.load(fr)
print(o['errno'])
print(o['errmsg'])
print(len(o['data']))
输出如下：
1
操作成功！
0
3、函数说明：
load(fp, cls=None, object_hook=None, parse_float=None, parse_int=None, parse_constant=None, object_pairs_hook=None, **kw)
反序列化fp（一个.read（）包含 - 支持类文件对象一个JSON文件），以一个Python对象。
object_hook是将与被调用的可选功能任何对象文本解码（一个``dict``）的结果。返回值object_hook将用来代替dict。此功能可用于实现自定义解码器（例如JSON-RPC级提示）。
object_pairs_hook是将与被调用的可选功能任何对象的结果与对的有序列表字面解码。该的返回值object_pairs_hook将用来代替dict。
此功能可用于实现依赖于定制解码器命令该键和值对被解码（例如，collections.OrderedDict会记得插入的顺序）。如果object_hook也定义了object_pairs_hook优先。
要使用自定义JSONDecoder子类，与cls指定它kwarg;否则JSONDecoder使用。
4、其它说明：
也可以使用json.loads函数来直接处理字符串，方法如下：
o=json.loads('{"errno":0,"errmsg":"操作成功！","data":[]}')

② 微服务跨语言调用（摘选）

微服务架构已成为目前互联网架构的趋势，关于微服务的讨论，几乎占据了各种技术大会的绝大多数版面。国内使用最多的服务治理框架非阿里开源的 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 ）

③ 从 0 到 1：全面理解 RPC 远程调用

作者 | Python编程时光

责编 | 胡巍巍

什么是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亿败光了！

你点的每个“在看”，我都认真当成了喜欢

④ JSON-RPC在Web服务中的应用

JSON-RPC (JSON Remote Procere Call) 是一种轻量级的远程过程调用协议，它使用JSON (JavaScript Object Notation) 来编码调用信息。JSON-RPC 的设计目标是简单性和易用性，它可以在任何环境中运行，只要该环境支持HTTP协议。

在Web服务中的应用主要体现在它提供了一种标准的、跨平台的远程调用机制。Web服务通常需要在不同的系统和语言之间进行通信，JSON-RPC 的JSON格式和HTTP传输方式使得这种通信变得简单和高效。

JSON-RPC 的请求和响应都是通过JSON对象来表示的，包括了请求的ID、方法名、参数以及响应的结果或错误信息。JSON-RPC 在Web服务中的应用方式包括作为后端通信协议，用于调用数据库服务或计算服务，以及作为前端接口，允许其他Web应用或客户端通过JSON-RPC 来调用服务。

以下是一个使用Python实现的JSON-RPC服务器的示例：

定义了一个subtract函数，并使用SimpleXMLRPCServer来创建一个服务器，接收JSON-RPC请求，调用函数，并返回JSON格式的响应。

JSON-RPC 的灵活性和简洁性使得它在Web服务中得到广泛的应用，无论是后端通信协议还是前端接口，JSON-RPC 都提供高效、可靠和跨平台的远程调用服务。

JSON 数据格式是轻量级的数据交换格式，易于人阅读和编写，同时也易于机器解析和生成。JSON 是基于 JavaScript 的一个子集，但它是独立于语言的文本格式，使用了类似于 C 语言家族的习惯（包括 C、C++、C#、Java、JavaScript、Perl、Python 等许多语言）。

JSON 支持多种数据类型，如字符串、数字、布尔值、数组和对象。以下是一个包含多种数据类型的 JSON 对象示例：

JSON-RPC 是一种基于 JSON 的 RPC 协议，它使用 JSON 来编码调用请求和响应。以下是一个 JSON-RPC 请求的示例，调用名为subtract 的方法，传入参数 42 和 23，id 用于标识请求。

响应包含了jsonrpc 版本，result 字段包含了方法调用的结果，id 字段与请求中的 id 字段相匹配，用于标识响应。

JSON-RPC 的实现通常包括一个服务器端和一个客户端。服务器端负责接收和处理 JSON-RPC 请求，客户端则负责发送请求和处理响应。

以下是一个使用Python实现的JSON-RPC客户端示例，向本地的 JSON-RPC 服务发送请求，调用名为subtract 的方法，并打印结果。

通过以上内容，我们了解了 JSON 数据格式、RPC 远程过程调用的基本原理，以及 JSON-RPC 在 Web 服务中的应用方式。

JSON-RPC 协议包括版本与规范、实现 JSON-RPC 服务、设计与实现 JSON-RPC 方法、创建 JSON-RPC 请求与处理响应等部分。在实际项目中，使用合适的 JSON-RPC 库在不同的编程语言中实现服务和方法。

JSON-RPC 在实际项目中的应用案例包括 Web 服务间通信、跨平台服务调用。在跨平台服务调用中，如 Python 和 JavaScript 之间，通过 JSON-RPC 实现服务调用。

JSON-RPC 的高级特性包括批处理请求和错误处理与调试技巧。批处理请求允许在单个 HTTP 请求中发送多个 JSON-RPC 请求，提高性能。错误处理机制在方法调用失败时返回错误信息。

JSON-RPC 的优势在于简洁的数据格式、跨平台和跨语言、低延迟和高效率。局限性包括简单的错误处理、相对较低的安全性和功能限制。未来 Web 服务通信协议的趋势可能更加倾向于 RESTful API 和 GraphQL。

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