RPC与MCP：从远程调用到AI工具链的通信底座

最近连续处理了几个后端项目的通信问题从老旧的HTTP接口调试到gRPC服务治理再到接MCP这种新的AI工具链发现很多同学对RPC的理解还停留在“远程调用”四个字上。RPCRemote Procedure Call远程过程调用是后端系统之间最核心的通信方式而MCPModel Context Protocol模型上下文协议又把这层通信逻辑带到了AI应用与外部工具之间。这篇内容我不打算从教材定义讲起而是直接结合后端常见项目场景把RPC的通信基础、MCP跟RPC的关系、实际落地时的踩坑点一起梳理清楚适合刚接触分布式后端的同学也适合已经在写业务接口、想搞清楚底层通信原理的工程师参考。1. 后端通信体系里RPC到底站在什么位置1.1 从“本地调用”到“远程调用”的那道坎理解RPC最快的方式是回想你自己写代码时的普通函数调用。你在UserService里调用orderService.createOrder(...)参数在栈上传递返回值直接拿到整个过程是同步的、透明的你不需要关心这个函数跑在哪个进程里也不需要关心数据怎么从内存A拷贝到内存B。RPC要做的事情就是把这套“本地调用”的体验复制到“远程调用”上——被调用的函数可能跑在另一台机器上中间隔着一层网络协议栈。但这里有个根本性的矛盾本地调用是内存地址跳转远程调用是网络报文传输。内存地址跳转纳秒级完成网络报文传输至少是毫秒级中间还夹着序列化、反序列化、连接管理、超时重试这些额外开销。所以任何一个RPC框架本质解决的都不是“能不能调用”的问题而是“怎么在远程调用的代价下尽量让调用方感觉像在本地调用”。很多后端项目一开始用HTTP接口也能跑通但是一旦服务数量上来比如拆分出订单服务、用户服务、库存服务三个模块服务之间互相调用HTTP接口的几个痛点就暴露了没有内置的服务发现URL配置靠手写没有统一的重试和熔断机制A服务挂了直接拖垮B服务JSON序列化效率不够高高并发下带宽和CPU都扛不住。RPC框架比如gRPC、Dubbo把这些能力做成了内置基础设施这就是后端常见项目从单体走向微服务时几乎必然引入RPC的原因。1.2 RPC的三板斧序列化、传输协议、服务治理剥开任何一个RPC框架核心就三块序列化协议、网络传输协议、服务治理能力。这三块的选型直接决定了RPC的性能和稳定性。序列化负责把内存中的对象变成字节流传输的时候把字节流还原成对象。常见的序列化方案有JSON、Protobuf、Hessian、Kryo。JSON可读性好、跨语言方便但体积大、解析慢Protobuf体积小、解析快但需要维护.proto文件、学习成本高。实际项目里内部服务调用追求性能用Protobuf或Hessian的居多对外开放接口追求兼容性用JSON的居多。传输协议负责在网络上搬运字节流。gRPC底层走HTTP/2支持多路复用、头部压缩一个连接上可以并发跑多个请求避免了HTTP/1.1的队头阻塞问题。Dubbo默认走Netty自定义协议纯TCP层实现性能更高但调试没那么方便。传输协议的选择跟业务场景强相关如果你要兼容浏览器客户端HTTP/2是必然选择如果你只在内部服务间通信自定义TCP协议更占优势。服务治理是RPC区别于“裸HTTP调用”的核心增量。它包含服务注册与发现服务实例挂在注册中心上调用方动态获取可用地址、负载均衡按权重/一致性哈希选择目标实例、熔断降级下游异常时快速失败或返回降级数据、链路追踪贯通全链路的traceId透传。没有服务治理的HTTP接口调用本质上是在手写一套不完整的RPC而完整RPC框架把这些能力统一封装好了这也是为什么后端项目稍微有点规模就会切换到成熟RPC框架。2. 后端常见项目里的RPC选型思路2.1 Java生态Dubbo与Spring Cloud的抉择Java后端项目里Dubbo和Spring Cloud是两条最常见的RPC路线很多团队在这两者之间摇摆。Dubbo是阿里开源的高性能RPC框架自带服务注册、负载均衡、集群容错底层支持多种协议dubbo协议、triple协议等在内部服务间高吞吐场景下表现非常突出。Spring Cloud不是单一框架而是一整套微服务治理生态通信基础用的是Spring Cloud OpenFeign声明式HTTP调用或Spring Cloud LoadBalancer底层走HTTP配合注册中心Eureka、Nacos、Consul完成服务发现。我个人的选型经验是如果团队以Java为主、追求极致性能、服务规模中等偏大Dubbo更合适因为它在注册中心、序列化、负载均衡策略上做了大量深度优化而且和Nacos搭配使用非常顺手。如果团队需要更强的生态整合能力尤其要接入Spring Cloud Gateway、Spring Cloud Stream这种周边组件或者组织里有多个语言Java、Go、Node共存Spring Cloud的HTTPJSON路线更稳妥因为HTTP协议跨语言支持天然好。说到底选型不是比谁性能高而是比谁的配套设施更匹配你团队的技术积累和业务形态。顺带提一下RuoYi这类常见的Java后台管理框架。RuoYi-Vue-Pro在近期版本里开始支持合并MCP功能以及gRPC集成搜索“ruoyi-vue-pro合并mcp功能”的热度也比较高。这说明后端脚手架项目已经在主动迎接RPC跟AI工具链的打通而不是拒绝变化。如果你手上的项目恰好是基于这类后台管理系统改造的可以留意官方更新日志里关于集成MCP Server、暴露Service方法给AI客户端调用的部分这部分内容放到第4节详聊。2.2 Python生态FastAPI的性能与异步通信Python后端的RPC选择跟Java完全不同。Java体系里RPC框架是标配但Python项目更多是用FastAPI这类Web框架直接暴露HTTP接口配合现代ASGI服务器Uvicorn达到不错的并发能力。FastAPI的风格是“类型驱动”用Pydantic做参数校验、自动生成OpenAPI文档上手非常快特别适合AI应用的后端——你定义一个/chat接口用类型注解描述请求体框架自动帮你做校验、生成文档前后端联调效率比Java那套高很多。但FastAPI本身并不算传统意义上的RPC框架它走的是HTTPJSON的路子。如果你的Python服务需要跟Java服务做高性能内部通信常见做法是Python侧起一个gRPC客户端/服务端通过protobuf定义接口。FastAPI有官方的grpc集成方式也可以用grpcio库手动启动一个gRPC服务跟FastAPI的HTTP服务共存。实测下来Python侧gRPC服务配合异步调用的性能表现尚可但序列化后的数据结构和强类型约束对Python这种动态语言来说维护成本会高一些。如果接口变更频繁建议在proto文件设计上留足兼容字段把可选的参数都标记为optional。还要多提一句“前后端分离”场景。现在很多后端项目是前后端完全分离的前端走Vue/React通过HTTP/HTTPS调用后端Gateway或BFF层。这里RPC的工作就落在BFFBackend For Frontend层BFF接收前端请求后再通过RPC调用下游微服务组装好数据返回给前端。这种分层的好处是前端只需要面向BFF的“聚合接口”不需要关心下游到底有几个服务、各服务怎么调用。BFF层用JavaDubbo或Node通过gRPC client都可以关键是协议边界要清晰。2.3 想用JS写后端Node框架的通信定位和选择“想用JS写一个后端项目用什么框架好”这个热搜词几乎每个季度都会出现。坦率说JS后端跟Java/Python后端在RPC体系里的位置完全不一样。Node.js生态里Express是经典之选路由中间件清晰、生态成熟适合快速做一些BFF层和API服务NestJS则是目前更接近“工程化完整”的方案它内置了依赖注入、模块化、装饰器对TypeScript支持极佳如果你用TS写后端NestJS基本是首选。但在RPC层面JS世界的选择相对简单一是直接跑gRPCNode官方有grpc-js库二是走HTTP/JSON跟其他语言服务通信很少见到JS团队像Java团队那样搭一套完整的注册中心负载均衡体系。如果你的“用JS写后端”是指独立开发一个中小型项目我建议选择NestJSTS写业务逻辑数据库用PostgreSQL或MySQL接口设计用RESTful或者GraphQL部署时用Docker起服务。大部分场景下Node后端作为BFF层跟Java/Python核心服务通过gRPC或HTTP沟通即可没必要硬上“全套微服务”的复杂度。只有当Node服务收敛了很多业务边界、需要治理服务发现和链路追踪时才需要引入RPC框架体系。2.4 数字后端的“通信基础”一条经常被搞混的线热搜词里“芯片后端”“数字后端”“innovus数字后端”是另一个完全独立的“后端”概念——它不是软件后端的服务端而是集成电路设计流程里“逻辑综合之后”的物理设计阶段。在这里“通信基础”更多指的是芯片内部不同模块之间的互连也就是片上网络NoC、总线协议、时钟树上的信号传播。这些物理层面的“通信”跟RPC虽然是完全不同的抽象层次但思想上有相通之处都是“如何在多个单元之间可靠、高效地传递信息”差别只是一个在芯片里用金属导线传电信号一个在服务器之间用网络报文传数据。所以如果你搜RPC时看到“数字后端”别慌那大概率是在讲芯片物理设计。学软件后端的人不需要掌握Innovus但了解一下这个概念有好处——至少跟别人聊“后端”的时候不会混淆两个完全不同的领域。3. MCP把“模型上下文”和RPC通信底座结合起来3.1 MCP是什么它跟RPC到底什么关系MCP全称Model Context Protocol模型上下文协议本质上是给AI应用比如大模型客户端提供一套标准化的方式来访问外部工具和数据源。你可以把它理解成“AI界的USB接口”以前每个AI应用要接入不同的数据源都得单独定制集成方式有了MCP数据源比如数据库、文件系统、设计工具只要实现了MCP Server任何支持MCP的客户端就能统一调用它。那MCP跟RPC是什么关系一句话概括MCP在通信机制上本质是基于RPC思想构建的但它面向的是“AI模型与工具之间的调用”关注的是“让模型拿到它需要的上下文”。RPC解决的是“怎么让一个程序像调用本地函数一样调用远端函数”MCP解决的是“怎么让AI模型标准化地调用外部工具、读取外部资源”。MCP底层用的是JSON-RPC 2.0协议这是一种轻量的RPC协议请求/响应用JSON封装方法调用通过method字段区分。所以从这个意义上看MCP就是RPC思想在AI领域的落地形态——只是它把“函数”变成了“工具”把“返回值”扩展成了“资源Resource”。搜索热词里频繁出现“mcp是什么”“mcp 基础知识”“mcp resource实战”说明大家对这个新协议的基础概念和实战方式都很感兴趣。我在第4节会给出一个具体的MCP Server配置示例那里面你能直观看到JSON-RPC请求长什么样。3.2 MCP的三个核心原语工具、资源、提示MCP协议设计里最核心的是三个原语Tools工具、Resources资源、Prompts提示。理解这三样东西基本就理解了MCP能干什么。Tools是“可执行的函数”AI模型通过调用tool来触发外部动作比如查询数据库、调用计算器、发送邮件。Tools的描述description对模型非常重要大模型通过tool的description字段决定“这个任务该调用哪个工具”所以写清晰的工具描述比写正确的工具实现还要重要。Resources是“可读取的数据”比如数据库表内容、文件内容、API响应结果模型通过读取resource来获取上下文。Prompts是“可复用的提示模板”把一套固定的提问流程封装起来让模型按照模板工作。三者组合起来就构成了一个完整的AI工具链模型先读资源了解背景→ 调用工具执行动作→ 返回结果继续推理。从RPC角度理解这三个原语会更清晰Tools和Resources都是JSON-RPC方法method它们被定义为类似tools/call、resources/read这样的标准方法名客户端AI应用调用这些方法服务端MCP Server处理并返回结果。这跟gRPC里定义service接口、通过stub去调用远端方法本质思维是一致的。3.3 MCP在前后端项目中的接入形态MCP的实际落地形态目前主要是两类一类是给AI IDE比如带AI能力的编辑器、通义灵码这类插件接入MCP Server让IDE里的AI助手能直接读数据库、操作代码另一类是给独立AI应用比如企业内的AI客服、AI报表工具接入MCP Server让模型能访问内部业务系统数据。热词里“idea插件通义灵码怎么使用mcp链接oracle”“codex 接入 figma mcp”“codex 接入 蓝湖mcp”都是这类场景。以通义灵码为例要在IDE的AI助手里通过MCP连接Oracle数据库流程大概是先在MCP Server里实现一个查Oracle的工具比如query_oracle再把Server地址配置到IDE的MCP客户端设置里之后AI助手就能在对话里直接执行query_oracle(select * from users)这样的工具调用来查库。这背后的通信链路就是AI模型发送“调用query_oracle”的JSON-RPC请求到MCP Server → Server执行SQL → 返回结果给模型。热词里还有“x32dbg 的mcp插件”“cheat engine 桥接 mcp教程”“ue5.8 mcp codex”这些偏逆向/游戏/渲染领域的MCP实践。这些都是同一个模式把某个特定领域的工具能力封装成MCP Server让AI模型能够调用。说明MCP标准化之后接入AI的工具类型正在快速扩展从后端数据库到前端设计工具再到调试器都在尝试变成“AI可调用的工具”。4. 实操RPC调用失败排查与MCP Server配置4.1 典型的“RPC调用失败”报错到底是什么回事热词里有一条非常典型的报错“cannot finish rpc call in 30 seconds: nul,done. error: rpc 失败。curl 56 recv failure: 连接超时00 kib/s error: 预期仍”。这看起来很乱但拆开来看其实是三个不同层面的问题混在一起。“cannot finish rpc call in 30 seconds”通常是RPC框架自带的超时控制框架规定一次RPC调用最长时间是30秒超过就强制中断。这个“30秒”是很多框架的默认值在高并发或下游服务响应慢的场景下极易触发。“curl 56 recv failure: 连接超时00 kib/s”是curl的错误码56代表“接收数据时连接失败”说明TCP连接虽然建立了但数据传输过程中断传输速率跌到0 KB/s。“error: 预期仍”应该是“预期仍有数据未收到”的截断——服务端没有返回完整的响应体就关闭了连接。排查这类问题我的固定顺序是先看错误发生在“连接建立阶段”还是“数据传输阶段”。连接建立阶段超时connect timeout大概率是网络不通、防火墙拦截、目标端口未监听数据传输阶段超时read/write timeout大概率是服务端处理慢、响应体过大、客户端缓冲区设置不合理。这个案例的curl 56发生在数据传输阶段优先怀疑服务端响应慢或连接被中间设备断开。接着看服务端日志里的处理耗时如果某个方法执行时间接近30秒优先优化该方法的数据库查询或外部依赖调用如果日志里没有耗时记录说明请求压根没到服务端逻辑层就要查网络链路和负载均衡的健康检查配置。4.2 超时参数与服务端处理能力的关系超时时间设置不是越大越好也不是越小越好它需要跟服务端的P99耗时曲线对齐。假设你调用的下游接口P99耗时是800毫秒那客户端超时设置成2秒就够宽裕如果P50都要3秒那超时最少也要给到5秒以上。比较稳妥的做法是先给一个宽裕的初始值比如10秒压测时观察实际耗时分布再把超时逐步收紧到P99的1.5~2倍左右。设置太短偶发波动会导致大量“超时误杀”设置太长下游故障时请求会全堆在服务端等待队列里适得其反。跟超时并列的一个重要参数是重试次数。RPC框架默认可能开3次重试但重试是有代价的每次重试都会给下游增加一份压力。如果下游已经因为过载而慢响应重试只会雪上加霜。正确做法是区分“幂等请求”和“非幂等请求”只有查询类幂等接口才允许自动重试写操作下单、扣款一律禁止自动重试需要引入分布式事务或最终一致性方案来兜底。这是我踩过多次坑后的真实体会很多线上事故都是“超时→重试→下游更堵→再超时→再重试”的恶性循环造成的。4.3 一个RPCgRPC与MCP Server的最小可运行对照先从RPC视角看一个最简gRPC服务。用Protobuf定义一个返回当前时间的service// time.proto syntax proto3; package time; service TimeService { rpc GetCurrentTime (TimeRequest) returns (TimeResponse); } message TimeRequest { string req_id 1; } message TimeResponse { string formatted_time 1; }生成对应语言的stub代码后服务端实现GetCurrentTime方法客户端通过生成的stub发起调用整个过程对调用方而言就像调用本地方法。这就是RPC框架的标准形态.proto文件定义接口边界stub封装网络细节调用方无感知。再看MCP Server的最小实现。目前最简单的方式是基于官方SDK写一个Python服务下面这个示例暴露一个“读取时间”的tool# mcp_server.py from mcp.server.fastmcp import FastMCP import datetime mcp FastMCP(time-server) mcp.tool() def get_current_time() - str: 返回当前服务端时间格式为 YYYY-MM-DD HH:MM:SS now datetime.datetime.now() return now.strftime(%Y-%m-%d %H:%M:%S) if __name__ __main__: mcp.run() # 默认走 stdio 传输运行这个脚本后MCP Server会在标准输入输出stdio上监听JSON-RPC请求。你再用任意支持MCP的客户端比如支持MCP的AI IDE配置好该Server的启动命令客户端就能在对话里调用get_current_time这个工具。整个调用链路上客户端发的请求大致是这样的JSON-RPC 2.0格式{ jsonrpc: 2.0, id: 1, method: tools/call, params: { name: get_current_time, arguments: {} } }Server端收到tools/call后把执行结果封装成JSON-RPC响应返回。这就是最基础的MCP通信过程底层就是标准的JSON-RPC远程调用跟RPC的思想完全一致。理解了这一个请求的完整流转再看任何MCP框架的文档都会轻松很多因为工具定义再怎么花哨底层都是这套方法调用。如果要把MCP Server接入远程网络环境可以把传输方式从stdio改成SSEServer-Sent Events或者Streamable HTTP客户端通过HTTP地址来连接。改动也很小FastMCP底层封装好了把mcp.run()改成带传输参数的运行方式即可。但要注意改成远程传输后认证和网络暴露面就成了必须考虑的问题MCP Server本质上是一个可以执行任意定义工具的远程服务暴露在公网上必须加访问控制。4.4 常见工具与框架的MCP接入方式速查场景做法关键要点IDEA插件通义灵码连接Oracle在MCP Server里实现调用JDBC的tool将连接串/账号配置到Server环境变量注意SQL注入防护tool描述写清楚参数含义Codex接入Figma/蓝湖配置Codex的MCP客户端设置指向Figma/蓝湖官方MCP Server授权通常走OAuth需要先完成令牌获取Debuggerx64dbg/CE桥接MCP实现对应调试器的MCP插件通过MCP Server暴露内存读写/寄存器读取工具注意调试会话隔离避免工具调用阻塞UI线程UE5.8 MCP在UE项目中嵌入MCP Server插件暴露关卡控制/资产查询工具给AI引擎线程与网络线程分离注意线程安全Dify平台接入浏览器MCP在Dify工具配置里添加MCP Server URL自动发现工具列表确认工具Schema兼容工具别名匹配时优先PostgreSQL 查询工具实现query_pg工具底层走连接池执行SQL并返回结果集单次查询限制返回行数防止大结果集拖垮模型上下文这张表覆盖了我最近看到的高频场景也都是实际项目中比较容易踩坑的地方。表格里每一条背后的细节都够单独写一篇这里先给方向遇到具体问题再按协议排查即可。5. 前后端分离项目里的RPC地基跨域、重复提交与接口设计5.1 不要被“前后端分离”骗了通信基础决定上层体验前后端分离项目里RPC的“后端”视角和“前端”视角是完全不同的。后端工程师眼里的RPC是Dubbo、gRPC、Feign这些服务间调用工具前端工程师眼里的“通信”更多是浏览器发出的HTTP请求、CORS跨域、接口鉴权、重复提交。这两个视角在同一个项目里需要互相理解前端调用的BFF接口后端在BFF里通过RPC去聚合下游服务一旦下游RPC超时BFF返回给前端的响应也会变慢前端表现就是“请求一直转圈”。搜索热词里“前后端分离项目实战”“后端跨域”“前后端对于按钮重复提交校验方法”这些都是前后端交互中的高频问题。跨域问题的本质是浏览器的同源策略页面A来自http://localhost:3000要请求http://localhost:8080的接口被浏览器拦截。后端最常见的解法是加CORS响应头比如在Spring Boot里配置CorsFilter允许指定来源、指定方法、指定Header。但要注意CORS拦截只是浏览器层面的拦截服务端其实能正常接收请求所以真正的安全防控不能只靠CORS还需要做服务端鉴权和校验。5.2 按钮重复提交前后端双保险按钮重复提交在前后端项目里非常经典。用户快速点两下“提交订单”按钮前端可能发出两次请求后端可能就会创建两笔订单。前端能做的有按钮置灰用loading状态禁用按钮、请求去重同一时间窗内相同的请求直接丢弃、防抖节流一定时间内只触发一次。但前端手段永远不是绝对可靠的——页面刷新、网络重试、恶意脚本都可能绕过前端限制。所以真正可靠的做法是后端加幂等校验创建订单的接口接收一个“幂等键”通常用前端的UUID或业务ID后端在Redis里检查这个幂等键是否已存在存在就直接返回第一次的响应不存在才继续处理并写入幂等键。这里用到的本质还是分布式系统中的幂等设计跟RPC重试时的幂等判断是同一个道理。真实项目里我把“前端提交按钮最佳实践”整理成了一条约定所有涉及写操作的提交按钮必须实现“请求中状态结果失败恢复”的双重状态机杜绝重复请求同时后端必须实现“幂等键RPC最终一致性”兜底。前端防误触后端防重放只有两层都做透了重复提交才算真正解决。6. 后端项目实战中的RPC与MCP避坑经验6.1 服务注册中心的那些隐性坑注册中心是RPC链路里的“通讯录”。服务实例启动时把自己注册进去下线时把自己移除调用方从注册中心拿到可用实例列表。但注册中心有几个隐性坑第一实例下线通知不一定实时服务提供方被强杀比如kill -9时注册中心可能在心跳超时默认几十秒之后才摘除该实例这段时间内调用方依然会路由到死节点大量请求超时第二注册中心节点本身的高可用很重要很多人依赖一个单点Nacos或单点Consul注册中心一挂整个RPC链路全断。应对思路有两个方向一个是靠客户端缓存RPC框架的客户端如Dubbo Consumer会缓存服务地址列表即使注册中心暂时不可用现有连接还能继续工作一段时间另一个是靠多级容错在注册中心不可用时回退到本地配置或最后已知地址。我实际排查过的一个案例里某个服务频繁超时最后定位到问题竟然是服务实例的IP地址是内网保留段注册到Nacos后调用方从另一个VPC访问不到——这类网络拓扑问题排查优先级比调参高得多。6.2 MCP Server开发中的线程与协议问题MCP Server虽然代码写起来很简单但放到生产环境还是有一些和业务系统耦合的坑。第一个坑是线程模型如果你的MCP Server里某个工具会阻塞调用比如同步查数据库而这个工具又被多个请求同时触发服务端的线程池一旦被占满其他工具的响应也会跟着变慢。解决方式是对耗时操作使用异步执行FastMCP里支持async工具底层用asyncio事件循环同时给阻塞型工具做好超时和并发限制。第二个坑是工具描述description的质量。大模型选择工具时靠的是工具名和描述文本的语义匹配而不是人类在UI里做的“先选后填”。如果你把一个查询订单的工具描述写成“order_detail”模型很难知道这个工具适合什么时候用但如果你写成“根据订单号查询订单的详细状态包括金额、物流、退款进度”模型就能精准触发。我实测过在MCP工具多的情况下描述写得精准与否直接决定模型能不能在第一步就选对工具这比去调整模型温度参数有效得多。第三个坑是错误返回格式。工具执行失败时不要直接抛异常让整个JSON-RPC请求失败应该把失败信息包装成工具返回值的一部分返回给模型。比如查询数据库失败工具应该返回{success: false, error: 数据库连接超时, traceId: xxx}而不是让MCP Server直接返回error。原因很简单模型看到结构化错误信息才能理解失败原因并调整后续策略模型收到一个异常堆栈只会复述“我遇到了错误”。6.3 从“会用RPC”到“懂得设计RPC边界”最后想聊一个后端常见项目里最容易忽略的点RPC边界的划分。通信基础讲得再细如果服务之间的边界划分不合理再好的RPC框架也救不回来。比如订单服务跟支付服务之间边界是“状态机领域事件”订单服务只关心“支付完成”这个事件具体怎么跟第三方支付渠道交互是支付服务自己的事。如果你把第三方支付的通信逻辑放在了订单服务里跨服务RPC调用就会缠成一团乱麻。设计RPC边界时我会先问三个问题这个接口是给谁调的内部服务/BFF/外部系统数据一致性要求是什么强一致/最终一致/读多写少失败之后能容忍多大延迟和丢失不能容忍→必须同步RPC重试能容忍→可以走异步消息回答完这三个问题接口粒度、同步/异步、重试策略基本就定了。跟产品经理确认需求时也要把这三个问题摆在桌面上聊清楚很多“接口到底该谁来做”的争论根源就是边界没对齐。RPC只是工具边界设计才是后端架构的灵魂。这也是我在这篇文章最后最想表达的东西不管是RPC还是MCP通信协议最终都是为业务边界服务的你把边界想清楚了工具选型自然就有了答案。