微服务拆得越细，服务间调用的通信协议就越关键。gRPC和REST是最常见的两个选项，选错了轻则性能拉胯，重则整个调用链路变得难以维护。
序列化效率的本质差距
REST通常用JSON做数据序列化，人类可读但体积大。gRPC用Protobuf，二进制格式，体积比JSON小30%到50%，序列化和反序列化的速度也快一个数量级。在服务间高频调用的场景下，这个差距会被放大。假设A服务调B服务100次/秒，每次传2KB的JSON，换gRPC可能变成1KB的Protobuf，网络带宽和CPU开销都直接砍半。
但Protobuf的代价是需要维护.proto文件，每次改接口定义都要重新生成代码。JSON那边改个字段，服务端加个key就行，前端兼容起来也灵活。这就是灵活性和效率之间的经典取舍。
流式传输和双向通信
gRPC原生支持流式传输——服务端流、客户端流、双向流。这在实时数据推送、大文件分块传输、聊天系统这种场景下几乎是唯一选择。REST要做到类似效果得用SSE或者WebSocket，复杂度上去了，一致性也没有gRPC好。
但gRPC有个硬伤：浏览器不能直接调用。gRPC基于HTTP/2和Protobuf，浏览器原生不支持。虽然gRPC-Web可以做转换，但需要额外部署Envoy代理，增加了一层运维负担。所以面向浏览器或移动端的API，REST仍然是首选。
选型建议
给出三个具体建议。第一，微服务内部通信，尤其是同构环境（都是Go或Java），优先用gRPC。性能优势明显，接口契约通过.proto文件强约束，减少扯皮。第二，面向外部调用方或前端的API，用REST。通用性好，文档直观，调试方便。第三，如果你的系统同时有内部和外部调用，可以服务间用gRPC，在API网关层做gRPC到REST的协议转换。Kong、APISIX都支持这个能力，Envoy更是原生自带。
别为了统一而统一。内部gRPC加外部REST的混合方案，在中等规模以上的微服务架构里是最常见的做法。