java透传

java.io包里的透传InputStream和OutputStream，就是透传干这个的。透传这词听着玄乎，透传拆开看就是透传“原样搬运”。不解析、透传不修改、透传不加工，透传字节从哪进就从哪出。透传像一根管子，透传水流过去，透传管子本身不关心水是透传脏是净。

我在一个物联网项目里干过这事。透传设备上报数据，透传走TCP长连接，透传服务端要转发给后端消息队列。透传最初有人提议在转发时顺便解析一下报文，把关键字段抽出来，重新封装成JSON再发。我说别，万一设备固件升级改了字段含义，你解析逻辑就得跟着改，改了还容易出bug。直接透传，原封不动扔给下游，让下游自己操心。后来设备协议真改了两版，我们的转发服务一行代码没动。

透传的实现，朴素得有点无聊。一个循环，从输入流读字节数组，写到输出流，flush一下。但细节里藏着坑。缓冲区大小设多少？设1024，遇到大包就得多读几次；设64KB，内存占用又上去了。我见过有人设了4字节，结果转发速度慢得像蜗牛爬——每次只读4个字节，系统调用开销全耗在往返上了。还有更隐蔽的：读完一次就flush一次，高频小数据包时性能还行，但遇到大流量，频繁flush反而拖慢吞吐。折中方案是攒够一定量或超时再flush，但这就不是严格意义的“原样”了——时序上有了延迟。

另一个坑是半包和粘包。TCP是流协议，没有消息边界。你读到的字节可能只是一条消息的前半截，也可能是两条消息挤在一起。透传不管这个，它只管把当前读到的字节全交出去。所以真正要透传的场景，下游必须自己懂分包逻辑。我们当时把原始字节流直接怼到Kafka里，消费端自己按协议头里的长度字段切分。这样反而干净——谁消费谁负责解析。

有人觉得透传太低端，显得没技术含量。但我觉得恰恰相反，透传是对“未知”的尊重。你没法预测未来协议会怎么变，那就别做聪明人，老老实实做管道。很多系统死在过度设计上——今天加个字段校验，明天加个格式转换，后天再加个版本兼容。透传省掉这些，让系统保持简单，简单的东西不容易坏。

当然，透传也有代价。你放弃了在中间层做鉴权、过滤、日志的机会，什么都得靠下游自己干。调试问题时，报文经过透传层就像进了黑箱，只能两端抓包对比。我那次排查一个丢包问题，抓了半小时包才发现是设备端发送频率太高，服务端读缓冲区满了，跟透传代码本身没关系。所以用透传前得想清楚，你愿意把灵活性交给下游，那就要接受排查问题时的痛苦。

写透传代码，核心就那几行。但想清楚什么时候该透传、什么时候不该透传，比写代码难多了。我的经验是：当你不确定数据会被谁用、怎么用的时候，透传就是最稳妥的答案。它不聪明，但它不会错。

本文地址：http://www.79wt.cn/news/1155b1999865.html