gRPC是什么？
gRPC是Google在2016年开源的一套远程过程调用（RPC）框架。它让不同服务之间的调用像本地函数一样简单，同时性能极高。
名字里的"g"代表Google，“RPC"代表远程过程调用。你可以把它理解成：两个服务之间打电话的方式。
传统REST API用的是HTTP/1.1加JSON，gRPC用的是HTTP/2加Protocol Buffers（简称protobuf）。这两种组合的性能差异非常大。
为什么需要gRPC？
想象你有一个电商系统。用户下单后，需要依次调用三个服务：库存服务扣减库存、订单服务创建订单、通知服务发短信。
如果用REST API，每个调用都要走完整的HTTP请求——解析URL、处理头部、序列化JSON。三次调用就是三次完整的HTTP握手。
用gRPC的话，所有调用共用一个TCP连接。服务A直接调用服务B的函数，代码写起来跟调用本地方法差不多。
gRPC的核心优势有三个：
速度快。HTTP/2支持多路复用，一个连接可以发多个请求。加上protobuf的二进制格式比JSON小很多，传输效率更高。
类型安全。你用proto文件定义接口，两边都按这个契约来写代码。编译期就能发现接口不匹配的问题，不用等到运行时才报错。
多语言支持。gRPC支持Java、Go、Python、C++、Node.js等20多种语言。不同语言写的服务可以互相调用。
gRPC是怎么工作的？
核心流程分三步：
第一步：写proto文件。用proto语言定义服务接口和数据结构。比如定义一个UserService，里面有GetUser和ListUsers两个方法。
第二步：生成代码。用gRPC编译器从proto文件自动生成客户端和服务端的代码骨架。你只需要填业务逻辑。
第三步：启动服务。服务端实现生成的接口，客户端调用生成的方法。底层通信由gRPC库自动处理。
举个例子，proto文件长这样：
service UserService {
rpc GetUser(UserRequest) returns (UserResponse);
}
message UserRequest {
int32 id = 1;
}
message UserResponse {
string name = 1;
string email = 2;
}
这4行定义了一个完整的API。编译后，Java、Go、Python等语言都能直接使用。
gRPC还支持四种调用模式：
- 简单RPC：客户端发一个请求，收到一个响应。最常见的用法。
- 服务端流式：客户端发一个请求，服务端返回一个数据流。适合大数据量查询。
- 客户端流式：客户端发送一个数据流，服务端返回一个响应。适合上传大文件。
- 双向流式：双方都可以发数据流。适合实时聊天、游戏同步这类场景。
Protocol Buffers是什么？
gRPC的性能密码之一就是protobuf。它是一种二进制序列化格式，类似JSON但更小更快。
对比一下：同样存一个用户信息，JSON大概100字节，protobuf可能只有40字节。数据传输少了，解析速度也更快。
protobuf还自带版本管理。新字段加了旧代码照样能用，不会报错。这对微服务迭代特别重要——升级一个服务不需要所有服务一起改。
gRPC适合什么场景？
gRPC特别适合这些情况：
- 微服务内部通信。服务间调用要求低延迟、高吞吐，gRPC天然适配。
- 移动端和后端交互。protobuf体积小，省流量，对移动网络友好。
- 实时数据处理。流式调用模式适合推送、订阅类场景。
- 多语言混合架构。团队用不同语言写服务，proto文件作为统一契约。
但它不太适合对外暴露公开API。浏览器原生不支持gRPC，前端开发者需要额外处理。如果你的服务要给外部第三方调用，REST+JSON更合适。
总结
gRPC是Google开源的高性能RPC框架，基于HTTP/2和Protocol Buffers。它在微服务通信中表现优异，速度快、类型安全、支持多语言。
如果你在做微服务架构，或者需要高性能的服务间通信，gRPC值得尝试。先从简单的proto文件开始，感受一下它带来的开发体验提升。
你的项目里有没有需要高性能通信的场景？欢迎留言讨论。