RPCRPC (Remote Procedure Call远程过程调用)的核心逻辑是让调用远程计算机上的函数像调用本地函数一样简单。它屏蔽了底层的网络传输、序列化、寻址等复杂细节让开发者专注于业务逻辑。1. RPC 的核心交互流程我们可以把 RPC 的通信过程拆解为“五部曲”客户端调用 (Client Call)客户端像调用普通函数一样调用getUserInfo(id)。存根打包 (Client Stub / Proxy)序列化 (Serialization)将函数名和参数如id101转换成二进制字节流。寻址通过注册中心或配置找到远程服务器的 IP 和端口。网络传输 (Transport)通过 TCP/UDP或 HTTP/2将数据包发送到服务端。服务端接力 (Server Stub / Skeleton)反序列化 (Deserialization)将字节流解析回函数名和参数。本地调用根据解析结果调用服务端真实的业务逻辑代码。结果返回服务端将返回值同样经过“序列化 - 传输 - 反序列化”的过程送回客户端。2. RPC 的三大关键组件为了实现上述流程一个成熟的 RPC 框架如 gRPC, Dubbo, Thrift必须解决以下问题A. 序列化协议 (Serialization)由于网络只能传输 0 和 1对象必须被转换。常见方案JSON (易读但慢)、Protobuf (二进制极快且小)、MessagePack。原则要在速度、体积和跨语言支持之间做平衡。B. 通信协议 (Protocol)规定数据包的结构就像报文的“格式说明书”。Header包含魔数校验、序列化类型、消息长度等。Body具体的序列化后的参数数据。C. 寻址与服务发现 (Service Discovery)客户端怎么知道服务器在哪直连硬编码 IP不灵活。注册中心如 Zookeeper, Nacos, Consul。服务端启动后向注册中心登记客户端去“查表”获取可用地址。3. RPC 与 HTTP 的区别很多人会问“我用 Axios 调接口也是远程调用这和 RPC 有什么区别”特性HTTP (REST)RPC关注点资源(URL, GET/POST)动作(函数名, 参数)传输效率文本协议Header 较重通常采用二进制效率极高耦合性弱耦合跨平台能力极强强耦合通常需要双方持有相同的 IDL (接口定义文件)典型应用浏览器与后端通信 (Open API)后端微服务之间的高频调用4. 简单代码模拟逻辑演示假设你在前端想模拟一个 RPC 效果// --- 客户端存根 (Client Stub) ---asyncfunctionremoteCalculateArea(width,height){// 1. 序列化参数constpayloadJSON.stringify({method:calculate,args:[width,height]});// 2. 网络传输 (这里用 fetch 模拟二进制传输层)constresponseawaitfetch(https://rpc-server.com/call,{method:POST,body:payload});// 3. 反序列化结果constresultawaitresponse.json();returnresult.data;}// --- 业务代码调用时完全感觉不到网络存在 ---constareaawaitremoteCalculateArea(10,20);console.log(area);// 2005. 为什么 MCP 也要用 RPC正如你之前提到的MCP (Model Context Protocol)它底层大量使用了JSON-RPC 2.0。原因AI 客户端Host和本地工具Server可能用不同的语言编写比如 Python Server 对接 TypeScript Host。逻辑通过标准化的 JSON-RPCAI 只需要发送一条{method: get_weather, params: {city: Nanjing}}Server 就能精准执行并返回结果。核心IDL双方认可接口定义语言实现跨语言调用注册中心服务端启动时注册进去客户端根据方法名和参数区注册中心寻址通信传输二进制推荐/JSON、传输协议TCP/UDP、HTTP/2代理本地电脑实际没这个方法代理负责拦截调用、序列化数据、寻找服务、网络通信和反序列化结果、反射没有会导致服务端硬编码根据方法名、不同参数进行调用、序列化与反序列化方法参数反序列化传输序列化解析MCP从FCFunction Calling函数调用到MCPModel Context Protocol模型上下文协议的演进本质上是从“孤岛式集成”向“标准化平台”的跨越。你可以把 FC 想象成每个插座都有不同的形状而 MCP 则是制定了一个全球通用的万能插头标准。1. 为什么有了 FC 还需要 MCPFC 的局限性“孤岛效应”在只有 FC 的时代如果你想让 AI 连接你的 Google Calendar、GitHub 和本地数据库你需要为每个工具手写一套 API 定义JSON Schema。在代码里维护每个工具的鉴权、连接逻辑。不可复用性你在项目 A 里写的 GitHub 工具换到项目 B或者换个编辑器如从 Cursor 换到 Windsurf时必须重新写一遍对接逻辑。MCP 发展的背景随着AI Agent和AI 原生编辑器如 Claude Desktop, Cursor, Trae的爆发开发者发现AI 需要连接的数据源太多了本地文件、数据库、Slack、Jira、甚至你的 GIS 数据库。痛点每个开发者都在重复造轮子为同一个工具写不同的连接器。需求需要一种协议让工具Server写一次就能运行在任何支持该协议的 AI 客户端Host中。2. MCP 解决了什么问题MCP 核心解决的是“多对多”的集成效率问题解耦控制权在 FC 中逻辑写在你的应用里在 MCP 中工具逻辑独立在MCP Server中AI 客户端Host通过标准协议自动发现Discovery工具。上下文标准化除了“调函数”MCP 还标准化了Resources资源如让 AI 直接读取一个本地文件或数据库表。Prompts提示词模板Server 可以预设好如何引导 AI 使用这些工具。安全性你可以本地运行 MCP ServerAI 客户端通过 JSON-RPC 与之通信而不需要把你的数据库权限交给云端 AI 模型。3. MCP 的好处特性Function Calling (FC)Model Context Protocol (MCP)集成难度每次都要手写 Schema 和请求逻辑即插即用Server 自动暴露能力复用性低绑定在特定代码中极高一份 Server 支持所有 MCP 客户端内容类型仅限函数调用函数 (Tools) 数据 (Resources) 模板 (Prompts)本地友好需自己搭建代理隧道天然支持本地服务与客户端通信4. 如何简单实践一个 MCP Server我们可以用 Python 或 TypeScript 快速写一个本地天气查询或文件搜索的 MCP Server。以下是一个基于Python (mcp-sdk)的最简实现步骤 1安装 SDKpipinstallmcp步骤 2编写 Server (server.py)这个 Server 暴露一个叫get_gis_data的工具模仿你 GIS 背景下的数据获取。frommcp.server.fastmcpimportFastMCP# 创建一个 MCP 服务实例mcpFastMCP(GIS-Helper)mcp.tool()defcalculate_area(width:float,height:float)-str:计算给定尺寸的区域面积areawidth*heightreturnf该区域的计算面积为:{area}平方米if__name____main__:mcp.run()步骤 3在客户端配置以 Claude Desktop 为例打开 Claude Desktop 的配置文件 (config.json)添加你的 Server{mcpServers:{gis_helper:{command:python,args:[/绝对路径/to/server.py]}}}效果重启客户端后Claude 的输入框旁会出现一个“锤子”图标。当你问“帮我算一下 50x100 的地块面积”时Claude 会自动调用你本地跑的这个 Python 脚本而不需要你写任何 API 接口。5. 总结FC是 AI 的“手指”能按按钮。MCP是 AI 的“扩展坞”插上它AI 就能直接读你的硬盘、查你的 SQL、调你的 GIS 算法而这一切都是标准协议化的。
RPC——MCP通信基础后端常见项目
发布时间：2026/5/26 4:13:51
RPCRPC (Remote Procedure Call远程过程调用)的核心逻辑是让调用远程计算机上的函数像调用本地函数一样简单。它屏蔽了底层的网络传输、序列化、寻址等复杂细节让开发者专注于业务逻辑。1. RPC 的核心交互流程我们可以把 RPC 的通信过程拆解为“五部曲”客户端调用 (Client Call)客户端像调用普通函数一样调用getUserInfo(id)。存根打包 (Client Stub / Proxy)序列化 (Serialization)将函数名和参数如id101转换成二进制字节流。寻址通过注册中心或配置找到远程服务器的 IP 和端口。网络传输 (Transport)通过 TCP/UDP或 HTTP/2将数据包发送到服务端。服务端接力 (Server Stub / Skeleton)反序列化 (Deserialization)将字节流解析回函数名和参数。本地调用根据解析结果调用服务端真实的业务逻辑代码。结果返回服务端将返回值同样经过“序列化 - 传输 - 反序列化”的过程送回客户端。2. RPC 的三大关键组件为了实现上述流程一个成熟的 RPC 框架如 gRPC, Dubbo, Thrift必须解决以下问题A. 序列化协议 (Serialization)由于网络只能传输 0 和 1对象必须被转换。常见方案JSON (易读但慢)、Protobuf (二进制极快且小)、MessagePack。原则要在速度、体积和跨语言支持之间做平衡。B. 通信协议 (Protocol)规定数据包的结构就像报文的“格式说明书”。Header包含魔数校验、序列化类型、消息长度等。Body具体的序列化后的参数数据。C. 寻址与服务发现 (Service Discovery)客户端怎么知道服务器在哪直连硬编码 IP不灵活。注册中心如 Zookeeper, Nacos, Consul。服务端启动后向注册中心登记客户端去“查表”获取可用地址。3. RPC 与 HTTP 的区别很多人会问“我用 Axios 调接口也是远程调用这和 RPC 有什么区别”特性HTTP (REST)RPC关注点资源(URL, GET/POST)动作(函数名, 参数)传输效率文本协议Header 较重通常采用二进制效率极高耦合性弱耦合跨平台能力极强强耦合通常需要双方持有相同的 IDL (接口定义文件)典型应用浏览器与后端通信 (Open API)后端微服务之间的高频调用4. 简单代码模拟逻辑演示假设你在前端想模拟一个 RPC 效果// --- 客户端存根 (Client Stub) ---asyncfunctionremoteCalculateArea(width,height){// 1. 序列化参数constpayloadJSON.stringify({method:calculate,args:[width,height]});// 2. 网络传输 (这里用 fetch 模拟二进制传输层)constresponseawaitfetch(https://rpc-server.com/call,{method:POST,body:payload});// 3. 反序列化结果constresultawaitresponse.json();returnresult.data;}// --- 业务代码调用时完全感觉不到网络存在 ---constareaawaitremoteCalculateArea(10,20);console.log(area);// 2005. 为什么 MCP 也要用 RPC正如你之前提到的MCP (Model Context Protocol)它底层大量使用了JSON-RPC 2.0。原因AI 客户端Host和本地工具Server可能用不同的语言编写比如 Python Server 对接 TypeScript Host。逻辑通过标准化的 JSON-RPCAI 只需要发送一条{method: get_weather, params: {city: Nanjing}}Server 就能精准执行并返回结果。核心IDL双方认可接口定义语言实现跨语言调用注册中心服务端启动时注册进去客户端根据方法名和参数区注册中心寻址通信传输二进制推荐/JSON、传输协议TCP/UDP、HTTP/2代理本地电脑实际没这个方法代理负责拦截调用、序列化数据、寻找服务、网络通信和反序列化结果、反射没有会导致服务端硬编码根据方法名、不同参数进行调用、序列化与反序列化方法参数反序列化传输序列化解析MCP从FCFunction Calling函数调用到MCPModel Context Protocol模型上下文协议的演进本质上是从“孤岛式集成”向“标准化平台”的跨越。你可以把 FC 想象成每个插座都有不同的形状而 MCP 则是制定了一个全球通用的万能插头标准。1. 为什么有了 FC 还需要 MCPFC 的局限性“孤岛效应”在只有 FC 的时代如果你想让 AI 连接你的 Google Calendar、GitHub 和本地数据库你需要为每个工具手写一套 API 定义JSON Schema。在代码里维护每个工具的鉴权、连接逻辑。不可复用性你在项目 A 里写的 GitHub 工具换到项目 B或者换个编辑器如从 Cursor 换到 Windsurf时必须重新写一遍对接逻辑。MCP 发展的背景随着AI Agent和AI 原生编辑器如 Claude Desktop, Cursor, Trae的爆发开发者发现AI 需要连接的数据源太多了本地文件、数据库、Slack、Jira、甚至你的 GIS 数据库。痛点每个开发者都在重复造轮子为同一个工具写不同的连接器。需求需要一种协议让工具Server写一次就能运行在任何支持该协议的 AI 客户端Host中。2. MCP 解决了什么问题MCP 核心解决的是“多对多”的集成效率问题解耦控制权在 FC 中逻辑写在你的应用里在 MCP 中工具逻辑独立在MCP Server中AI 客户端Host通过标准协议自动发现Discovery工具。上下文标准化除了“调函数”MCP 还标准化了Resources资源如让 AI 直接读取一个本地文件或数据库表。Prompts提示词模板Server 可以预设好如何引导 AI 使用这些工具。安全性你可以本地运行 MCP ServerAI 客户端通过 JSON-RPC 与之通信而不需要把你的数据库权限交给云端 AI 模型。3. MCP 的好处特性Function Calling (FC)Model Context Protocol (MCP)集成难度每次都要手写 Schema 和请求逻辑即插即用Server 自动暴露能力复用性低绑定在特定代码中极高一份 Server 支持所有 MCP 客户端内容类型仅限函数调用函数 (Tools) 数据 (Resources) 模板 (Prompts)本地友好需自己搭建代理隧道天然支持本地服务与客户端通信4. 如何简单实践一个 MCP Server我们可以用 Python 或 TypeScript 快速写一个本地天气查询或文件搜索的 MCP Server。以下是一个基于Python (mcp-sdk)的最简实现步骤 1安装 SDKpipinstallmcp步骤 2编写 Server (server.py)这个 Server 暴露一个叫get_gis_data的工具模仿你 GIS 背景下的数据获取。frommcp.server.fastmcpimportFastMCP# 创建一个 MCP 服务实例mcpFastMCP(GIS-Helper)mcp.tool()defcalculate_area(width:float,height:float)-str:计算给定尺寸的区域面积areawidth*heightreturnf该区域的计算面积为:{area}平方米if__name____main__:mcp.run()步骤 3在客户端配置以 Claude Desktop 为例打开 Claude Desktop 的配置文件 (config.json)添加你的 Server{mcpServers:{gis_helper:{command:python,args:[/绝对路径/to/server.py]}}}效果重启客户端后Claude 的输入框旁会出现一个“锤子”图标。当你问“帮我算一下 50x100 的地块面积”时Claude 会自动调用你本地跑的这个 Python 脚本而不需要你写任何 API 接口。5. 总结FC是 AI 的“手指”能按按钮。MCP是 AI 的“扩展坞”插上它AI 就能直接读你的硬盘、查你的 SQL、调你的 GIS 算法而这一切都是标准协议化的。
原理与实战应用)
