026、微服务通信：gRPC与Protocol Buffers一、从线上一个诡异的数据截断问题说起上周深夜收到告警，某个订单查询接口间歇性返回数据不全。日志里没有异常抛出，但客户端拿到的订单列表总是缺最后几个字段。抓包发现HTTP响应体长度正常，但反序列化后的对象里amount和currency字段经常是默认值零和空字符串。第一反应是数据层问题，但检查数据库记录完整。接着怀疑序列化框架，这个服务用的是JSON over HTTP，字段名大小写、日期格式都反复核对过。直到在网关日志里看到一条线索：某个实例的响应时间明显偏长，触发网关超时截断了响应体。但为什么截断后还能解析成合法JSON，只是字段丢失？根本原因出在JSON的流式解析特性上——解析器遇到截断的JSON时，可能只抛出异常，也可能静默忽略后续字段。这种不确定性在微服务跨实例调用时被放大：网络抖动、实例负载不均、超时配置不合理，加上JSON这种无schema的协议，让问题像幽灵一样时隐时现。正是这次排查，让我重新审视微服务间的通信协议选择。二、为什么需要gRPC和Protocol Buffers微服务拆得越细，通信成本越高。JSON over HTTP看似简单直观，但在大规模部署时暴露出几个硬伤：冗余传输：字段名反复出现在每个请求