你好，我是 shengjk1，多年大厂经验，努力构建 通俗易懂的、好玩的编程语言教程。 欢迎关注！你会有如下收益：

1. 了解大厂经验
2. 拥有和大厂相匹配的技术等

希望看什么，评论或者私信告诉我！

零、 背景

最近趁有时间，搞一下 MCP，前面我们已经再为更进一步的 MCP 打下了基础
一文搞定 Python 装饰器 以及 Web架构全解析：8种类型优缺点及场景

这边文章，我们继续，搞一下 MCP 的 Json-rpc，目前 MCP 主要靠 json-rpc 进行 client 和 server 的通信

一、RPC vs HTTP

1.1 什么是RPC

RPC（Remote Procedure Call，远程过程调用）是一种通过网络在不同计算机程序之间实现服务调用的协议或技术框架。其核心目标是让开发者能够像调用本地方法一样调用远程服务，而无需关注底层网络传输的细节（如通信协议、序列化、网络连接等）。

核心特征：

• 透明性：开发者无需感知远程调用的存在，调用逻辑与本地方法一致。
• 标准化：通过接口定义语言（IDL）或动态代理技术，统一不同系统间的数据表示、传输和方法调用规范。
• 跨语言支持：允许用不同编程语言编写的服务进行交互（如 Java 服务调用 Python 方法）。

1.2 为什么需要 RPC？

RPC 的诞生源于分布式系统的需求，主要解决以下问题：

• 分布式协作

  现代应用常拆分为多个独立服务（如电商系统的订单、库存服务），RPC 提供高效的服务间通信机制，使各模块能协同工作。

• 性能优化

  相比传统的 HTTP 短连接，RPC 通过长连接复用、二进制序列化（如 Protobuf）和协议优化（如 HTTP/2 多路复用），显著降低网络延迟和资源消耗。

• 服务治理

  RPC 框架内置服务发现、负载均衡、熔断降级等能力，简化分布式系统的运维复杂度。

• 跨语言集成

  在异构技术栈环境下（如 Java 后端与 Python 数据分析服务），RPC 提供统一的通信标准，避免各语言自行实现协议适配。

1.3 RPC 解决了什么问题？

• 网络通信的复杂性

  RPC 封装了底层网络传输（如 TCP/UDP）、数据序列化与反序列化，开发者只需关注业务逻辑，无需手动处理网络编程细节。

• 数据表示的异构性

  通过标准化的序列化协议（如 JSON、Protobuf），解决不同系统间数据格式差异问题，确保数据跨语言、跨平台兼容。

• 服务发现与调用规范

  提供注册中心（如 ZooKeeper）和动态代理机制，自动定位服务节点并生成调用代码，避免硬编码服务地址。

• 高并发与容错

  支持线程池管理、请求队列和重试策略，提升系统在高负载下的稳定性和容错能力。

1.4 RPC vs HTTP

HTTP 和 RPC 虽然都用于网络通信，但 RPC 的诞生并非取代 HTTP，而是为了在特定场景下弥补 HTTP 的不足，尤其是在分布式系统和高性能服务调用的需求中。以下是两者核心差异及 RPC 存在的必要性：

一、协议设计与性能效率

• 协议效率优化

  RPC 通常采用二进制协议（如 Protobuf、Thrift）进行数据序列化，相比 HTTP 的文本格式（如 JSON/XML），二进制协议的体积更小、序列化速度更快。例如，传输相同数据时，Protobuf 的带宽占用比 JSON 减少 60% 以上，解析速度提升 5-10 倍。

示例：传输 {“userId”: 12345, “name”: “Alice”}，JSON 需要 32 字节，Protobuf 仅需 8 字节。

• 连接管理机制

  RPC 默认使用长连接和连接池，复用 TCP 连接减少握手开销，而 HTTP/1.1 的短连接需要频繁建立/断开连接（即使启用 Keep-Alive 仍需传输冗余头部）。例如，gRPC 基于 HTTP/2 实现多路复用，一个 TCP 连接可并行处理多个请求。

二、开发体验与服务治理

• 调用方式透明化

  RPC 通过动态代理和接口定义语言（IDL）实现类似本地方法调用的体验，例如：
  User user = userService.getUser(123); // 无需关注网络传输细节

  而 HTTP 需手动封装 URL、Header、Body，代码复杂度更高。

• 内置服务治理能力

  RPC 框架（如 Dubbo、gRPC）集成服务发现、负载均衡、熔断降级等功能。例如，服务节点动态扩容时，RPC 通过注册中心（如 Zookeeper）自动通知调用方，而 HTTP 需手动修改 Nginx 配置。

三、适用场景的差异

• RPC 的主战场

  微服务架构：内部服务高频调用（如订单服务调用库存服务），要求低延迟、高吞吐（每秒数万次调用）。

  高性能计算：金融交易、实时数据处理等场景，节省 1ms 延迟可能带来百万级收益。

• HTTP 的优势场景

对外暴露 API：浏览器、第三方系统等异构环境兼容性强（如微信支付接口）。

快速原型开发：无需复杂服务治理时，HTTP 的 RESTful API 开发更简单。

四、综合对比与选择建议

维度	RPC（如 gRpc/Dubbo）	HTTP（RESTful）
协议类型	二进制协议（Protobuf/Thrift）	文本协议（JSON/XML）
性能	高（低延迟、小带宽）	低（高冗余、大带宽）
服务治理	内置（负载均衡、熔断）	依赖网关（如 Nginx）
跨语言支持	需协议适配（如 Protobuf）	天然支持
适用场景	微服务内部调用、高性能计算	前后端交互、开放 API

五、为什么需要 RPC？

• 解决 HTTP 的性能瓶颈

  在高并发场景下，HTTP 的文本协议冗余、短连接开销、线程阻塞模型会成为性能瓶颈，而 RPC 通过二进制协议、长连接复用、异步 I/O 显著提升效率。

• 降低分布式系统复杂度

  RPC 隐藏网络通信细节，提供“透明化”调用，开发者只需关注业务逻辑，无需手动处理序列化、重试、超时等问题。

• 适应技术栈统一的内部协作

  在公司内部使用统一技术栈时，RPC 的强类型接口和代码生成能力可减少联调错误，提升开发效率。

六、总结
HTTP 是通用协议，适合开放性和异构环境；
RPC 是高性能专用方案，适合技术栈统一、高并发的内部服务。两者并非替代关系，而是互补共存。
例如，对外用 HTTP 提供 RESTful API，对内用 RPC 实现微服务调用，兼顾灵活性与效率。

二 、JSON-RPC

2.1 什么是JSON-RPC

JSON-RPC 是一种基于 JSON 格式的轻量级远程过程调用（RPC）协议，允许客户端通过结构化请求调用远程服务器上的方法，并获取响应结果。其核心设计目标