本文目录导读:
- 目录导读
- 什么是RPC?为什么Python开发者需要它?
- 案例一:使用内置模块
xmlrpc实现轻量级RPC - 案例二:借助第三方库
jsonrpc实现更现代的RPC - 案例三:工业级方案——使用
gRPC构建高性能微服务 - 总结与实战建议
Python RPC远程过程调用实战指南:3个简单案例带你快速入门
目录导读
-
什么是RPC?为什么Python开发者需要它?
- 核心概念与使用场景
- 常见问答:RPC与REST API有何区别?
-
使用内置模块
xmlrpc实现轻量级RPC- 服务端代码与客户端代码详解
- 问答:
xmlrpc适合生产环境吗?
-
借助第三方库
jsonrpc实现更现代的RPC- 基于JSON的灵活调用
- 问答:
jsonrpc与xmlrpc的优劣对比
-
工业级方案——使用
gRPC构建高性能微服务- 协议缓冲区定义与代码生成
- 问答:gRPC为何成为云原生推荐?
-
总结与实战建议
- 根据项目规模选择RPC方案
- 深化学习的推荐资源
什么是RPC?为什么Python开发者需要它?
RPC(Remote Procedure Call,远程过程调用) 是一种允许程序像调用本地函数一样调用远程服务器上的函数的技术,在Python开发中,RPC常用于微服务架构、分布式系统、任务队列等场景,能够通过简洁的接口调用实现服务间的通信。
核心价值:
- 开发者无需处理底层网络细节(如Socket连接、数据序列化、传输协议)。
- 函数签名一致,客户端代码几乎与本地调用无异。
- 适合内部服务间高频、低延迟的调用。
常见问答:RPC与REST API有何区别?
Q: 我已经用Flask搭建了REST API,为什么还需要RPC?
A: 两者定位不同,REST API强调资源(Resource)的CRUD操作,通过HTTP方法(GET/POST/PUT/DELETE)表示动作;RPC则直接暴露方法(如calculate_tax()),更贴近函数调用。
- 如果服务间需要复杂业务逻辑组合(如“先验证用户,再发送邮件”),RPC代码更直观。
- REST更适合对外公开的、资源导向的Web服务。
- 性能上,RPC(尤其使用二进制协议时)通常比REST-基于JSON的文本协议更快。
使用内置模块xmlrpc实现轻量级RPC
Python标准库自带xmlrpc模块,无需安装第三方包即可实现RPC,尽管XML-RPC已经比较古老,但对于学习原理或小型内部工具来说仍然非常合适。
服务端代码(server.py)
from xmlrpc.server import SimpleXMLRPCServer
import datetime
class MyService:
def greet(self, name):
return f"Hello {name}, server time: {datetime.datetime.now()}"
def add(self, a, b):
return a + b
if __name__ == "__main__":
server = SimpleXMLRPCServer(("0.0.0.0", 8000), allow_none=True)
server.register_instance(MyService())
print("XML-RPC Server listening on port 8000...")
server.serve_forever()
客户端代码(client.py)
import xmlrpc.client
proxy = xmlrpc.client.ServerProxy("http://localhost:8000/")
print(proxy.greet("Alice")) # 远程调用
print(proxy.add(10, 20)) # 返回30
运行效果:
客户端无需了解网络传输,直接像调用本地方法一样使用proxy.greet()。
问答:xmlrpc适合生产环境吗?
Q: 我看到有人吐槽xmlrpc性能差,真的吗?
A: 是的,它有明显局限:
- 使用XML作为序列化格式,数据体积大、解析慢。
- 不支持二进制数据(需手动编码),缺乏高级特性(如流式传输)。
- 安全性较弱,默认无认证机制。
适用建议:仅用于个人学习、内部监控脚本或对性能无要求的临时工具,企业级项目建议跳过此方案。
借助第三方库jsonrpc实现更现代的RPC
jsonrpc基于JSON-RPC 2.0协议,使用JSON格式传递数据,比XML更轻量、可读性强,通过jsonrpclib(Python版)可以快速搭建。
安装依赖
pip install jsonrpclib-pelix
服务端代码(jsonrpc_server.py)
from jsonrpclib.SimpleJSONRPCServer import SimpleJSONRPCServer
def get_user_info(user_id):
# 模拟数据库查询
if user_id == 1:
return {"id": 1, "name": "Bob", "role": "admin"}
else:
return {"id": user_id, "name": "Unknown"}
server = SimpleJSONRPCServer(("0.0.0.0", 8001))
server.register_function(get_user_info)
print("JSON-RPC Server running on port 8001...")
server.serve_forever()
客户端代码(jsonrpc_client.py)
from jsonrpclib import Server
proxy = Server("http://localhost:8001")
result = proxy.get_user_info(1)
print(result) # 输出:{'id': 1, 'name': 'Bob', 'role': 'admin'}
问答:jsonrpc与xmlrpc的优劣对比
Q: 既然jsonrpc已经更好,为何还要学xmlrpc?
A:
jsonrpc优势:数据体积小30%~50%,解析速度更快,支持错误对象标准描述。- 适用人群:需要RPC但不想引入重型框架(如gRPC)的中小型项目。
- 公共局限:依然基于HTTP/TCP文本协议,高并发场景性能不如二进制方案;没有自动生成客户端/服务端代码的能力。
工业级方案——使用gRPC构建高性能微服务
gRPC由Google开发,基于HTTP/2协议和Protocol Buffers(protobuf)序列化格式,它支持双向流、拦截器、认证等特性,是云原生(如Kubernetes)生态的标准技术之一。
步骤1:安装工具
pip install grpcio grpcio-tools
还需要安装protobuf编译器(protoc),从GitHub Release下载即可。
步骤2:定义protobuf文件(calc.proto)
syntax = "proto3";
service Calculator {
rpc Multiply (MultiplyRequest) returns (MultiplyResponse);
}
message MultiplyRequest {
int32 a = 1;
int32 b = 2;
}
message MultiplyResponse {
int32 result = 1;
}
步骤3:生成Python代码
python -m grpc_tools.protoc -I. --python_out=. --grpc_python_out=. calc.proto
生成calc_pb2.py和calc_pb2_grpc.py文件。
步骤4:服务端实现(grpc_server.py)
import grpc
from concurrent import futures
import calc_pb2
import calc_pb2_grpc
class CalculatorServicer(calc_pb2_grpc.CalculatorServicer):
def Multiply(self, request, context):
result = request.a * request.b
return calc_pb2.MultiplyResponse(result=result)
server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
calc_pb2_grpc.add_CalculatorServicer_to_server(CalculatorServicer(), server)
server.add_insecure_port("[::]:50051")
print("gRPC Server running on port 50051...")
server.start()
server.wait_for_termination()
步骤5:客户端调用(grpc_client.py)
import grpc
import calc_pb2
import calc_pb2_grpc
channel = grpc.insecure_channel("localhost:50051")
stub = calc_pb2_grpc.CalculatorStub(channel)
response = stub.Multiply(calc_pb2.MultiplyRequest(a=5, b=6))
print("Multiplication result:", response.result) # 输出 30
问答:gRPC为何成为云原生推荐?
Q: 相比前两种方案,gRPC的进入门槛更高,值得使用吗?
A: 绝对值得,尤其当:
- 服务间调用量极大(每秒数千次以上),需要低延迟、高吞吐(二进制协议+HTTP/2多路复用)。
- 希望自动生成多语言客户端(定义一次
.proto,即可生成Java、Go、C++等)。 - 需要流式传输(如实时日志、机器学习在线推理)。
缺点:
- 学习曲线(Proto语法、代码生成流程)。
- 浏览器不能直接调用(需通过gRPC-Web网关)。
- 不适合对外暴露给终端用户(通常用REST API统一对外)。
总结与实战建议
根据项目规模选择RPC方案
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
xmlrpc |
学习原理、小型内部脚本 | 零依赖、入门快 | XML笨重、性能差 |
jsonrpc |
中小型项目、内部工具 | 轻量、可读性强 | 缺少高级特性 |
gRPC |
微服务架构、高并发系统 | 高性能、多语言支持 | 需要额外学习Proto |
实战原则:
- 如果只是给同事用的自动化脚本,
jsonrpc足够。 - 如果团队已采用微服务、容器化部署,优先选择gRPC。
- 避免在需要浏览器直接调用的功能中使用RPC(兼容性差)。
深化学习的推荐资源
- 官方文档:gRPC Python Quick Start(grpc.io)
- JSON-RPC规范:jsonrpc.org
- 书籍:《微服务设计》(Sam Newman)第5章“进程间通信”
最后建议:从jsonrpc案例开始动手,它能帮你最直观地理解RPC模式,然后根据实际业务压力,决定是否升级到gRPC,RPC本质是“让远程调用像本地一样简单”,选能帮你达到这个目的的最小方案即可。
标签: Python RPC 案例