本文字数：4000 字，阅读约需 15 分钟。
在分布式系统里头，不同的服务相互之间得用到一种可靠的办法去展开通信。远程过程调用，也就是RPC，它是一种常见的选取方式，而JSON - RPC则是处于其中相对简单的那一种。
这篇文章讲述 JSON-RPC 2.0 协议的重中之重，涵盖消息的格式，叙述错误的处理方式，还提及实际运用的场景之处。
JSON-RPC 概述什么是 JSON-RPC
json-rpc 是一种远程过程调用协议，它无状态，且轻量级，其使用 json 作为数据格式，它的设计目标在于简单，而协议规范仅有几页文档。
JSON身为数据交换格式，近乎所有主流编程语言都有不错的支持，涵盖JavaScript、Python、Java、C#、Go等，这致使JSON-RPC能够轻易达成跨语言调用。
协议自身并不与传输层相绑定，能够运行在诸如 HTTP、WebSocket、TCP Socket 等的各类消息传输环境之中。从事开发的人能够依据业务方面的需求去挑选适宜的传输方式。
JSON-RPC 的发展历程
JSON-RPC 有两个主要版本：1.0 和 2.0。
1.最早提出基于 JSON 的 RPC 概念的是 0 版本，然而其在规范性方面存在欠缺之处。2010 年发布的 2.0 版本进行了重要升级，该升级加入了批量调用支持以及统一的错误对象结构。两个版本借助 jsonrpc 字段予以区分。
JSON-RPC 的核心特点
JSON-RPC 有几个值得注意的特点：
协议规范详解协议约定与术语
JSON - RPC规范里用到了RFC 2119定义的关键字 ，这些关键字是MUST、MUST NOT、SHOULD、SHOULD NOT、MAY。这些术语阐述了实现者必须要遵循 ，或者应该遵循 ，又或者可以遵循的行为规范。
发出请求的那个实体，被称作客户端（Client），它专门对用于构造请求的对象予以负责，同时还要处理响应，就是这样。
服务端，也就是Server，它是这样一种实体，即接收请求，然后进行处理此请求行为，进而生成响应，最后再返回响应。
同一实现能够同时充当客户端以及服务端，举例而言，于对等网络里，两个节点有可能既针对对方发出请求，又回应源自对方的请求。
数据类型系统
JSON 的类型系统被 JSON-RPC 所继承，其中涵盖六种数据类型。
基础类别有，String也就是字符串，Number即数值，Boolean为布尔值，Null是空值。
结构化类型：Object（对象）、Array（数组）
这些种类名称的首字母，是一定要大写的，其中涵盖了True，还包括False。
若成员名称也就是字段名于客户端跟服务端彼此交互之际，必须对大小写予以区分。函数、方法、过程这三个术语能够相互替换使用，它们均指向能够被调用的可执行单元且。
消息格式深度解析
JSON-RPC 2.0界定了三种核心消息类型，其中有一种是请求对象，也就是Request Object，还有一种是响应对象，即Response Object，另外一种是通知对象，也就是Notification Object。
JSON-RPC 协议架构图请求对象结构
请求对象是客户端向服务端发起 RPC 调用的载体：
{
??"jsonrpc":?"2.0",
??"method":?"subtract",
??"params": [42,?23],
??"id":?1
}
// 索引数组参数：参数顺序与服务端预期一致
{"jsonrpc":?"2.0",?"method":?"subtract",?"params": [42,?23],?"id":?1}
// 命名对象参数：参数名需与服务端方法签名匹配
{"jsonrpc":?"2.0",?"method":?"subtract",?"params": {"minuend":?42,?"subtrahend":?23},?"id":?2}
响应对象结构
响应对象是服务端返回给客户端的执行结果：
// 成功响应
{
"jsonrpc":?"2.0",
"result":?19,
"id":?1
}
// 错误响应
{
"jsonrpc":?"2.0",
"error": {
? ??"code":?-32601,
? ??"message":?"Method not found",
? ??"data":?"详细错误信息"
? },
"id":?1
}
那响应对象呢，它得涵盖result或者error其中之一，可不能同时把这两者包含进来。而id呢，它必须得跟对应请求里头的id维持一致状态。
在请求自身存有错误的状况下，是那种像无效的 JSON 格式或者非法请求结构这样的错误，致使服务端没办法去确定原始 id 的时候，响应当中的 id 一定得是 null。
通知机制
通知是一种不需要响应的请求，通过省略?id?字段来标识：
{
??"jsonrpc":?"2.0",
??"method":?"update",
??"params": [1,?2,?3,?4,?5]
}
通知可应用于日志记录的场景，通知可应用于事件发布的场景，通知可应用于进度通知的场景。客户端仅仅负责发送消息，客户端不需要处理响应。
因不存在响应机制，客户端没法晓得通知是不是被成功处置。于批量请求里，通知请求不会生成相应的响应。
JSON-RPC 请求响应流程图错误处理机制错误对象结构
JSON-RPC 2.0 定义了标准化的错误对象：
{
??"code":?-32603,
??"message":?"Internal error",
??"data": {?"details":?"数据库连接失败"?}
}
预定义错误码
JSON - RPC 2.0，在 -32768至 -32000这个范围之内，预留了预定义错误码：
错误码
名称
说明
-32700
Parse Error
解析错误，服务端收到的 JSON 格式无效
-32600
Invalid Request
无效请求，发送的不是有效的请求对象
-32601
Method Not Found
方法不存在或不可调用
-32602
Invalid Params
参数无效
-32603
Internal Error
JSON-RPC 内部错误
JSON-RPC 错误码分类图
范围处于 -32000 至 -32099 之内的错误码，被保留以供服务端自行定义使用。应用程序同样能够定义自身的错误码，（通常是负数并且其绝对值小于 32767）。
错误处理建议批量调用与性能优化批量请求机制
JSON - RPC 2.0具备在单个请求里发送多个RPC调用的能力，服务端会返回与之对应的响应数组，此一机制于高并发场景当中能够降低网络往返的次数。
// 批量请求
[
? {"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"},
? {"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",?"result": ["hello",?5],?"id":?"9"}
]
那种没有id字段的通知请求，是不会去产生响应的。响应数组当中各个元素的顺序，跟请求顺序是没有关联关系的，客户端是借助匹配id的方式，去关联请求以及响应的。
批量调用的边界情况
规范对批量调用中的边界情况有明确定义：
要是批量请求自身并非有效的 JSON，或者不是含有至少一个值的数组，那么服务端应当返回单对象响应，而并非数组。空数组是会被当作无效请求的。
要是批量请求里的全部请求均为通知，那服务端无需返回任何响应。在别的情形下，就算若干请求处理失败了，响应数组中仍然应当含有对应请求所产生的错误响应。
与 RESTful API 进行对比的性能优化策略的分析，设计理念存在差异。
JSON-RPC与RESTful体现出两种各异的API设计理念，JSON-RPC以过程为导向，所注重的是“做何种操作”，RESTful以资源为导向，所关注的是“操作哪些资源”。
以用户操作为例：
// JSON-RPC: 直接调用方法
{"jsonrpc":?"2.0",?"method":?"createUser",?"params": {"name":?"张三",?"email":?"zhang@example.com"},?"id":?1}
// RESTful: 操作资源
POST /users
{"name":?"张三",?"email":?"zhang@example.com"}
通信模式对比
维度
JSON-RPC
RESTful
语义抽象
方法调用
资源操作
URL 角色
