在刚接触分布式系统时RPC 往往是一个“每个词都见过连起来却说不清”的概念客户端、服务端、序列化、接口定义、连接、超时、重试……这些知识点分散在不同层次很容易混在一起。本文从一个简单问题出发当 Python 代码调用另一台机器上的函数时中间到底发生了什么读完本文你将能够用自己的话解释 RPC。说清一次 RPC 调用的完整过程。区分 RPC、HTTP 和 REST。根据项目特点选择常见的 Python RPC 框架。从零搭建并运行一个 gRPC 服务。一、RPC 是什么RPC 是 Remote Procedure Call 的缩写中文通常译为“远程过程调用”。它的目标是让调用方以接近本地函数调用的方式请求另一个进程或另一台机器执行某个方法并取得执行结果。假设本地有一个普通函数resultadd(3,5)如果add实际运行在另一台服务器上调用方仍可能写出非常相似的代码resultcalculator_client.add(3,5)第二行代码看起来像本地方法调用但框架在背后完成了参数编码、网络传输、服务端方法查找、执行和结果返回。因此可以先记住一句话RPC 的本质是把跨进程或跨机器的通信包装成方法调用。这里的“像本地调用”只描述编程体验不代表两者具有相同的运行特性。网络可能延迟、断开或重复传递请求远程服务也可能过载或崩溃这些情况在普通的进程内函数调用中通常不会出现。二、RPC 系统由哪些部分组成一个典型的 RPC 系统包含以下角色。组成部分作用调用方Client发起远程调用的程序客户端桩Client Stub提供本地方法外观负责组装请求和还原响应序列化器把内存中的对象编码为可传输的字节收到数据后再解码传输层通过 TCP、HTTP/2 等方式传递请求和响应服务端桩Server Stub解码请求根据服务名和方法名找到对应实现服务实现Service执行业务逻辑并返回结果接口定义约定方法名称、参数类型、返回类型和错误形式服务发现在服务地址动态变化时帮助客户端找到可用实例简单系统可以没有“桩”可以理解为框架生成或提供的代理代码。调用方调用的是客户端桩真正的业务方法则由服务端执行。三、一次 RPC 调用经历了什么下面以Add(3, 5)为例说明完整过程。业务方法服务端桩客户端桩Python 调用方业务方法服务端桩客户端桩Python 调用方调用 Add(3, 5)编码请求并通过网络发送解码请求并分派方法返回计算结果编码响应并通过网络返回还原为 Python 返回值把这条链路拆开可以得到八个步骤调用方执行客户端桩上的Add方法。客户端桩检查方法签名并把参数构造成请求消息。序列化器把请求消息编码成字节。传输层把字节发送到服务端。服务端桩解码请求并将它分派给对应的业务方法。业务方法完成计算产生结果或错误。服务端把结果编码后发回客户端。客户端桩解码响应把结果或异常交还给调用方。框架替开发者处理了大部分通用工作但业务代码仍需处理超时、重试、权限校验和异常边界。1. 接口定义接口定义是客户端与服务端共同遵守的契约例如服务Calculator 方法Add 请求left 为整数right 为整数 响应result 为整数有些框架使用独立的接口定义语言例如 gRPC 的.proto文件和 Thrift 的.thrift文件有些框架直接根据 Python 类和方法暴露服务。明确的接口契约有两个重要价值客户端和服务端可以由不同语言实现。参数类型和接口变更更容易在开发阶段被发现。2. 序列化与反序列化Python 对象不能直接在网络上传输。发送方需要把对象编码为字节接收方再把字节还原为可用的数据结构。常见格式包括Protocol Buffers二进制格式体积较小类型约束明确。Thrift Binary Protocol与 Thrift 接口定义配套的二进制协议。JSON可读性好、调试方便但数据体积和解析成本通常高于紧凑二进制格式。XML兼容性广但文本较冗长常见于较早期的系统。序列化格式决定了数据如何表示但不负责把数据送到目标机器。3. 网络传输传输层负责连接管理、数据收发和连接异常处理。RPC 不是某一种固定的网络协议gRPC 通常使用 HTTP/2。XML-RPC 通常使用 HTTP 或 HTTPS。一些框架直接在 TCP 连接上使用自己的消息协议。因此“RPC 和 HTTP 哪个更好”并不是一个严谨的问题。RPC 是调用方式和通信抽象HTTP 可以成为它的传输基础。4. 调用类型RPC 不只支持“一次请求、一次响应”。常见调用类型有调用类型数据方向适用例子一元调用一个请求一个响应查询用户、创建订单服务端流一个请求多个响应持续接收事件、分批下载数据客户端流多个请求一个响应分片上传、批量汇总双向流双方持续发送实时协作、长连接消息交换初学时应先掌握一元调用再根据实际需求学习流式调用。四、远程调用与本地调用有什么不同远程方法的代码外观可能很简单但不能把它当成普通函数。维度本地调用RPC 调用耗时通常为微秒级或更低受网络、排队和服务端处理影响失败方式主要是代码异常还包括超时、断连、服务不可用结果确定性调用结束时通常可确定超时后可能无法判断服务端是否已执行参数传递直接访问内存对象需要序列化类型受到协议限制重试通常没有必要需要考虑但可能造成重复执行调试范围单进程调用栈跨进程日志、指标和链路信息这里最容易踩坑的是“超时不等于未执行”。例如客户端发起扣款请求服务端已经完成扣款但响应在返回途中丢失。客户端看到超时后立即重试就可能造成重复扣款。解决这类问题通常需要为请求设置唯一业务编号。服务端实现幂等处理。只对明确可重试的错误进行有限次数重试。记录跨服务调用链路便于确认请求实际状态。五、RPC、HTTP API 与 REST 的关系这三个概念经常被放在一起比较但它们不在同一层次。RPC强调“调用一个远程方法”接口常写成CreateOrder、GetUser。REST强调“操作资源”接口常写成POST /orders、GET /users/42。HTTP是通信协议既能承载 REST 风格接口也能承载某些 RPC 协议。可以从使用体验上做一个简单对比维度RPCREST 风格 HTTP API接口中心方法和动作资源和状态契约常由接口定义文件严格描述常由 OpenAPI 等文档描述数据格式常用紧凑二进制格式也可用文本常用 JSON浏览器调用部分方案需要额外适配通常更直接调试方式常需要专用工具curl等通用工具即可常见场景内部服务、高频调用、流式通信公开接口、前后端接口、资源管理两者并非互斥。一个系统完全可以对外提供 REST 风格接口对内使用 RPC。六、RPC 的常见应用场景1. 内部服务之间通信订单服务调用库存服务、支付服务和物流服务是 RPC 最常见的使用方式。统一的接口契约能够减少各服务对参数格式的重复约定。2. 跨语言调用客户端使用 Python服务端使用 Java、Go 或 C 时可以通过共同的接口定义生成各自语言的代码。3. 高频、低延迟调用当调用频繁、数据量较大时紧凑的二进制编码、连接复用和多路复用可以降低通信开销。4. 流式数据传输当服务需要持续返回数据或双方需要在同一连接上持续通信时支持流式调用的 RPC 框架会比反复创建独立请求更自然。5. 远程设备或进程控制测试平台、内部运维工具、实验设备控制等 Python 主导的环境可以通过远程对象或远程方法封装底层操作。哪些情况不必优先选择 RPC只需要几个简单的公开接口。调用方主要是浏览器或第三方合作方。团队更重视直接查看和手工调试请求。系统规模很小引入接口编译和代码生成反而增加维护成本。技术选型的目标不是使用功能最多的框架而是用最低的长期成本满足通信需求。七、Python 生态中的常见 RPC 方案1. gRPCgRPC 使用 Protocol Buffers 定义服务和消息通常运行在 HTTP/2 之上支持一元调用和多种流式调用。它提供多语言代码生成适合接口边界清晰的内部服务。优点接口契约明确类型检查能力较强。二进制消息通常较紧凑。支持连接复用、流式调用、截止时间和状态码。多语言支持完善。限制需要维护.proto文件和生成代码。原始请求不如 JSON 直观。浏览器直接调用通常需要 gRPC-Web 或网关。2. Apache ThriftThrift 同样使用接口定义文件和代码生成并允许选择不同的传输方式与编码协议。它适合已有 Thrift 基础设施或需要细致控制通信组件的多语言系统。优点多语言支持广。传输层和编码协议可组合。技术成熟适合维护已有系统。限制编译器和运行库的配置项较多。新项目的开发体验通常不如 gRPC 统一。3. Pyro5Pyro5 侧重 Python 对象之间的远程调用。开发者可以公开 Python 类的方法再通过代理对象进行调用。它还提供名称服务便于通过逻辑名称查找远程对象。优点接近 Python 原生对象和方法的使用方式。纯 Python 实现上手成本较低。适合 Python 内部工具、实验平台和局域网服务。限制主要面向 Python 环境不适合作为通用多语言接口标准。对外部调用者开放时需要认真配置暴露范围、认证和加密。4. RPyCRPyC 提供透明、对称的远程调用双方都可以处理请求也支持远程对象代理。它在远程测试、设备管理和受控环境中的进程协作方面很灵活。优点对 Python 对象的远程操作能力强。可以使用同步或异步调用。适合测试、管理和受信任网络中的专用工具。限制客户端与服务端都与 Python 运行时和对象语义紧密相关。暴露能力过多会扩大安全风险不宜直接向不可信网络开放。5. Python 标准库 XML-RPCPython 自带xmlrpc.client和xmlrpc.server无需安装第三方包即可实现基础 RPC。它适合教学、小型受控环境和兼容旧系统。优点标准库直接提供。协议简单便于理解 RPC 的基本过程。不同语言都有相应实现。限制XML 消息较冗长类型能力有限。不适合高吞吐或复杂流式通信。Python 官方文档明确提示标准库实现不能安全处理恶意构造的未受信数据。选型对比方案接口方式跨语言流式调用主要优势更适合gRPC.proto 代码生成强完整支持契约、性能和工具链较均衡新建内部服务、多语言系统Thrift.thrift 代码生成强取决于具体实现方式传输与协议可配置已有 Thrift 系统Pyro5Python 类与装饰器弱支持远程迭代等方式Python 开发体验自然Python 内部工具RPyCPython 服务与对象代理弱支持异步调用远程对象操作灵活测试、运维、设备控制XML-RPC动态方法注册中不支持现代流式调用无第三方依赖教学、简单兼容场景对于没有历史包袱的新建多语言服务通常可以优先评估 gRPC对于只在 Python 受控环境中使用的小工具Pyro5 往往更轻量维护旧系统时应优先遵循现有协议和基础设施。八、从零搭建一个 Python gRPC 服务下面实现一个计算器服务。客户端向服务端发送两个整数服务端返回它们的和。示例源码会打包为python-rpc-demo.tar.gz并作为博客附件单独提供。读者可以下载压缩包直接跟随本文操作也可以不使用附件按照后续步骤依次创建各个文件。1. 解压示例并准备环境tar-xzfpython-rpc-demo.tar.gzcdpython-rpc-demo python3-mvenv .venvsource.venv/bin/activate python-mpipinstall--upgradepip python-mpipinstall-rrequirements.txtWindows PowerShell 激活虚拟环境的命令为.\.venv\Scripts\Activate.ps1项目初始结构如下python-rpc-demo/ ├── calculator.proto ├── client.py ├── requirements.txt └── server.pyrequirements.txt使用本文验证过的一组依赖版本grpcio1.80.0 grpcio-tools1.80.0grpcio-tools生成的代码会检查grpcio运行库版本因此两者应保持一致升级。固定版本也能减少不同时间运行教程时产生的环境差异。2. 定义服务接口创建calculator.protosyntax proto3; package calculator.v1; service Calculator { rpc Add(AddRequest) returns (AddResponse); } message AddRequest { int64 left 1; int64 right 2; } message AddResponse { int64 result 1; }这份文件定义了三件事服务名是Calculator。服务提供一元方法Add。请求包含left和right响应包含result。字段后的1、2是消息在二进制协议中的字段编号不是默认值。接口发布后不要随意修改或重复使用已有编号否则可能破坏新旧版本之间的兼容性。3. 生成 Python 接口代码在项目目录执行python-mgrpc_tools.protoc\-I.\--python_out.\--pyi_out.\--grpc_python_out.\calculator.proto执行后会新增calculator_pb2.py calculator_pb2.pyi calculator_pb2_grpc.pycalculator_pb2.py请求和响应消息类型。calculator_pb2.pyi消息类型提示。calculator_pb2_grpc.py客户端桩、服务端基类和注册函数。这些文件由工具生成不应手工修改。接口变化后应重新执行生成命令。4. 实现服务端创建server.pyfromconcurrentimportfuturesimportgrpcimportcalculator_pb2importcalculator_pb2_grpcclassCalculatorService(calculator_pb2_grpc.CalculatorServicer):defAdd(self,request,context):resultrequest.leftrequest.rightreturncalculator_pb2.AddResponse(resultresult)defserve()-None:servergrpc.server(futures.ThreadPoolExecutor(max_workers10))calculator_pb2_grpc.add_CalculatorServicer_to_server(CalculatorService(),server,)listen_address[::]:50051bound_portserver.add_insecure_port(listen_address)ifbound_port0:raiseRuntimeError(f无法监听地址{listen_address})server.start()print(fCalculator RPC 服务已启动{listen_address})server.wait_for_termination()if__name____main__:serve()这里主要完成三项工作继承生成的CalculatorServicer并实现Add。把服务实现注册到 gRPC 服务器。监听50051端口并等待请求。ThreadPoolExecutor(max_workers10)表示同步服务端最多使用 10 个工作线程处理调用。真实项目应根据任务类型、响应时间和压测结果调整不能简单地认为线程越多越快。5. 实现客户端创建client.pyimportgrpcimportcalculator_pb2importcalculator_pb2_grpcdefmain()-None:withgrpc.insecure_channel(localhost:50051)aschannel:clientcalculator_pb2_grpc.CalculatorStub(channel)requestcalculator_pb2.AddRequest(left3,right5)try:responseclient.Add(request,timeout3.0)exceptgrpc.RpcErroraserror:print(fRPC 调用失败{error.code()}{error.details()})returnprint(f3 5 {response.result})if__name____main__:main()客户端首先建立通道再基于通道创建CalculatorStub。调用client.Add(...)时客户端桩会完成消息编码、请求发送和响应解码。这里显式设置了3秒超时。实际项目中的每次 RPC 都应该有合理的截止时间避免服务异常时调用线程无限等待。6. 启动并验证打开第一个终端cdpython-rpc-demosource.venv/bin/activate python server.py预期看到Calculator RPC 服务已启动[::]:50051打开第二个终端cdpython-rpc-demosource.venv/bin/activate python client.py预期输出3 5 8至此一个最小但完整的 RPC 调用已经跑通client.py - CalculatorStub - Protocol Buffers 编码 - HTTP/2 连接 - CalculatorService.Add - Protocol Buffers 编码 - client.py 得到结果7. 尝试观察失败停止服务端后再次执行客户端会看到类似以下错误RPC 调用失败StatusCode.UNAVAILABLE...也可以把客户端超时临时改得很短或在服务端方法中加入延迟观察StatusCode.DEADLINE_EXCEEDED。这一步很重要因为 RPC 工程实践的重点不仅是“正常时能调用”还包括“异常时能及时失败并提供可处理的信息”。九、把示例推进到生产环境前还要补什么本文示例只适合本地学习。进入真实环境前至少要考虑以下内容。1. 使用加密连接和身份认证示例使用insecure_channel请求以未加密方式传输。跨主机部署时应配置 TLS并根据系统边界增加令牌、证书或统一身份认证。2. 为每次调用设置截止时间客户端不能无限等待。截止时间应结合上游总耗时预算和服务端正常响应分布设置并为后续调用保留时间。3. 谨慎重试读取操作通常更容易安全重试创建、扣款、发货等写操作必须先实现幂等。重试还应设置次数上限和退避间隔避免故障期间进一步放大流量。4. 复用连接建立连接有成本。通常应复用 gRPC Channel 和客户端桩而不是每次业务调用都重新创建。5. 控制消息大小和调用粒度不要把超大文件直接塞进单个消息也不要为每个细小字段单独发起一次 RPC。前者占用大量内存后者会产生过多网络往返。应按业务边界设计适当的消息大小和批量接口。6. 选择合适的并发方式同步 gRPC 服务适合普通入门场景。大量请求都在等待网络或磁盘时可以评估grpc.aio若方法包含阻塞操作则需要避免直接阻塞事件循环。7. 建立可观测性至少记录服务名和方法名。调用耗时与状态码。请求标识和链路标识。超时、重试和限流次数。服务端并发量与资源使用情况。不要在日志中直接记录密码、令牌或完整敏感数据。8. 维护接口兼容性Protocol Buffers 接口演进通常遵循以下原则新需求优先增加新字段。不改变已有字段编号。删除字段后保留其编号和名称避免后续误用。新旧客户端并存期间服务端同时兼容双方需要的字段。十、常见认识误区误区一RPC 一定比 HTTP 快RPC 可能使用更紧凑的编码和更高效的连接方式但最终性能仍取决于消息大小、网络环境、业务处理、连接配置和调用次数。未经测试不能只凭协议名称判断。误区二使用 RPC 后可以忽略网络RPC 只是隐藏了通信细节没有消除网络的不可靠性。超时、重试、限流、熔断和幂等仍然需要明确设计。误区三接口生成后就不需要文档接口文件说明了字段和类型却不一定说明业务含义、权限要求、幂等规则和错误处理方式。高质量接口仍需补充这些约束。误区四所有错误都应该重试参数错误、权限不足等问题不会因为重试而消失。只有临时网络故障、短暂不可用等情况才可能适合重试而且写操作必须先保证幂等。误区五远程方法越细越好过细的接口会形成频繁往返。例如读取一个订单时分别调用十次接口获取十个字段通常不如一次返回完整业务视图。RPC 接口应围绕稳定的业务动作设计。十一、学习路线建议可以按以下顺序继续学习先运行本文的一元调用示例并主动制造服务停止和超时。为示例增加减法方法重新生成代码理解接口变更流程。为服务增加输入校验并返回合适的 gRPC 状态码。学习服务端流、客户端流和双向流。增加 TLS、健康检查和调用日志。通过并发测试观察线程数、消息大小和连接复用对性能的影响。最后再学习服务发现、负载均衡、限流和熔断。总结RPC 并不神秘它主要组合了四件事用接口契约描述“可以调用什么”。用序列化协议描述“数据如何编码”。用传输协议解决“数据如何到达远端”。用客户端桩和服务端桩隐藏重复的通信代码。真正需要建立的意识是远程调用虽然写起来像本地调用但它始终要面对网络延迟、部分失败、重复执行和版本兼容问题。对于 Python 开发者gRPC 是理解现代契约式 RPC 的合适起点Pyro5 和 RPyC 有助于理解 Python 对象式远程调用Thrift 常见于成熟的多语言系统XML-RPC 则适合用最少依赖观察 RPC 的基本形态。完成本文示例后你已经具备继续学习服务治理与分布式通信的基础。参考资料gRPC Python 快速入门Protocol Buffers 语言指南Apache Thrift Python 教程Pyro5 文档RPyC 文档Pythonxmlrpc.server文档