现在大家做系统开发,都喜欢搞"微服务架构"——简单说就是把一个大系统拆成很多小服务,这样更灵活也更容易扩展。那这些服务之间怎么沟通呢?就得靠一种技术叫 RPC(远程过程调用)。今天我们就来聊聊它的"进化版":gRPC,看看它和传统的 RPC 到底有啥不一样。
一、先搞懂几个概念
什么是 RPC?
可以把它理解成"跨机器调用函数"的方式。就像你在本地调用一个函数一样,但其实它是在另一台服务器上运行的。传统 RPC 有很多种实现,比如 XML-RPC、JSON-RPC、SOAP 等,数据格式多是 XML 或 JSON。
那 gRPC 是啥?
Google 出品的一个更高效的 RPC 框架,基于 HTTP/2 协议,数据格式用的是 Protocol Buffers(简称 Protobuf)。性能好、效率高,还能自动生成代码,听起来就很香对吧?
二、gRPC 和传统 RPC 的几大区别(白话版)
| 对比点 | 传统 RPC | gRPC |
|---|---|---|
| 传输协议 | 通常用 HTTP/1 或 TCP | HTTP/2,支持多路复用,速度快 |
| 数据格式 | XML/JSON,可读但体积大 | Protobuf,体积小,解析快 |
| 代码生成 | 通常手动写 | 支持自动生成客户端/服务端代码 |
| 流式处理 | 一般不支持 | 支持四种调用模式,支持双向流 |
| 跨语言支持 | 有点费劲 | 官方支持多语言(Go、Python 等) |
| 错误处理 | 用 HTTP 状态码处理 | 用标准错误码机制,支持详细描述 |
三、举个例子更直观
用传统 JSON-RPC 调接口
{ "jsonrpc": "2.0", "method": "getUserProfile", "params": { "userId": 123, "includeDetails": true }, "id": 1 }
人类能看懂,但数据量大,解析速度也慢。
用 gRPC + Protobuf
首先定义协议:
syntax = "proto3"; service UserService { rpc GetUserProfile(UserRequest) returns (UserProfile) {} } message UserRequest { int32 user_id = 1; bool include_details = 2; } message UserProfile { int32 user_id = 1; string username = 2; string email = 3; }
然后就可以这样调用:
request = user_pb2.UserRequest(user_id=123, include_details=True) response = stub.GetUserProfile(request) print(f"用户名: {response.username}")
结构更清晰、体积更小、传输效率更高。
四、请求处理方式对比
# XML-RPC示例 import xmlrpc.client # 创建客户端 server = xmlrpc.client.ServerProxy("http://localhost:8000") # 每次调用都会建立新连接 result = server.get_user_info(user_id=123) print(f"用户信息: {result}") # 又得重新连接 another_result = server.get_product_details(product_id=456)
就像每次打电话都要重新拨号一样,费时间!
gRPC的调用方式
import grpc import user_service_pb2 import user_service_pb2_grpc # 创建一个连接通道 with grpc.insecure_channel('localhost:50051') as channel: # 创建调用对象 stub = user_service_pb2_grpc.UserServiceStub(channel) # 同一个连接可以调用多个方法 response1 = stub.GetUser(user_service_pb2.GetUserRequest(user_id=123)) response2 = stub.GetProduct(user_service_pb2.GetProductRequest(product_id=456)) # 还能做流式调用,像看视频一样一点点接收数据 for product in stub.ListProducts(user_service_pb2.ListProductsRequest(category="手机")): print(f"产品: {product.name}, 价格: {product.price}")
就像建立一条专线,通话不断,还能边说边听,太方便了!
五、性能差距有多大?
场景:获取 1000 个用户信息
传统 REST(HTTP/1 + JSON)版本:
import requests import time start_time = time.time() users = [] # 发送1000个独立的HTTP请求,每次都要建连接 for i in range(1000): response = requests.get(f"http://api.example.com/users/{i}") users.append(response.json()) duration = time.time() - start_time print(f"REST API: 获取了{len(users)}个用户,耗时{duration:.2f}秒") # 输出: REST API: 获取了1000个用户,耗时10.45秒
gRPC 版本:
import grpc import user_pb2 import user_pb2_grpc import time start_time = time.time() with grpc.insecure_channel('api.example.com:50051') as channel: stub = user_pb2_grpc.UserServiceStub(channel) # 一次请求获取所有用户,批量处理 users = list(stub.GetUsers(user_pb2.GetUsersRequest(limit=1000))) duration = time.time() - start_time print(f"gRPC: 获取了{len(users)}个用户,耗时{duration:.2f}秒") # 输出: gRPC: 获取了1000个用户,耗时1.23秒
总结:gRPC 更快,因为它:
-
支持连接复用(不用每次都重新连)
-
使用 Protobuf,数据更轻更快
-
流式处理,批量效率高
六、错误处理方式对比
REST 错误处理:
服务端返回的错误:
{ "error": { "code": 404, "message": "User not found", "details": "The user with ID 12345 does not exist" } }
客户端处理:
fetch('/api/users/12345') .then(response => { if (!response.ok) { return response.json().then(err => { throw new Error(`${err.error.message}: ${err.error.details}`); }); } return response.json(); }) .catch(error => console.error('错误:', error));
靠 HTTP 状态码,但格式不统一,需要手动解析。
gRPC 错误处理:
服务端定义错误:
def GetUser(self, request, context): user = database.find_user(request.user_id) if not user: context.set_code(grpc.StatusCode.NOT_FOUND) context.set_details(f"找不到用户 {request.user_id}") return user_pb2.UserProfile() # 返回空对象 return user
客户端处理错误:
try: response = stub.GetUser(request) print(f"用户信息: {response}") except grpc.RpcError as e: if e.code() == grpc.StatusCode.NOT_FOUND: print(f"错误: 用户不存在 - {e.details()}") else: print(f"RPC错误: {e.code()} - {e.details()}")
标准的错误码 + 描述,客户端可以直接 catch。像处理本地异常一样方便!
七、实际应用场景选择
什么时候用传统REST API?
-
前端直接调API
// 浏览器调REST API就很方便 fetch('/api/products') .then(res => res.json()) .then(products => console.log(products)); -
接第三方平台 比如接微信支付、支付宝API,人家都是REST的,你也得跟着来
-
简单系统 小项目不追求性能,REST开发速度快
什么时候用gRPC?
-
微服务内部通信 服务多了,内部调用频繁,用gRPC又快又稳
-
实时数据应用
// 股票价格实时推送 func (s *StockServer) PriceStream(request *pb.StockRequest, stream pb.StockService_PriceStreamServer) error { for { price := getLatestPrice(request.Symbol) stream.Send(&pb.StockPrice{ Symbol: request.Symbol, Price: price, Timestamp: time.Now().Unix(), }) time.Sleep(1 * time.Second) } } -
移动端应用 手机流量金贵,gRPC数据小,省流量
-
多语言系统 Python服务调Go服务,Java服务调C#服务,都不是问题
八、总结一句话
REST API就像普通话,大家都听得懂;gRPC像高速公路,虽然有门槛,但一旦上了路就飞快!
如果你在做面向普通用户的接口,或者简单系统,REST API足够了。