高并发压测时，发现来自网关的消息出现粘包现象；分包就是势在必行的
前置和处理平台（暂时）使用netty通话，由于都是服务器平台使用DelimiterBasedFrameDecoder来解决分包
和网关的通信，找出包长的字段，使用LengthFieldBasedFrameDecoder来解决分包；
这个类拥有很多构造器，对于底层的通信协议，只要上报的数据有字段标识了变长内容的长度，可以通过计算得到包长的，都可以通过该类解决；
剩下的两种文中也有详细说明
LineBasedFrameDecoder解码器
LineBasedFrameDecoder是回车换行解码器，如果用户发送的消息以回车换行符作为消息结束的标识，则可以直接使用Netty的LineBasedFrameDecoder对消息进行解码，只需要在初始化Netty服务端或者客户端时将LineBasedFrameDecoder正确的添加到ChannelPipeline中即可，不需要自己重新实现一套换行解码器。
FixedLengthFrameDecoder解码器
FixedLengthFrameDecoder是固定长度解码器，它能够按照指定的长度对消息进行自动解码，开发者不需要考虑TCP的粘包/拆包等问题，非常实用。
对于定长消息，如果消息实际长度小于定长，则往往会进行补位操作，它在一定程度上导致了空间和资源的浪费。但是它的优点也是非常明显的，编解码比较简单，因此在实际项目中仍然有一定的应用场景。
下文对netty的粘包问题有比较详细的说明
https://blog.csdn.net/a925907195/article/details/74942472
Netty是目前业界最流行的NIO框架之一，它的健壮性、高性能、可定制和可扩展性在同类框架中都是首屈一指。它已经得到了成百上千的商业项目的验证，例如Hadoop的RPC框架Avro就使用了Netty作为底层通信框架，其他的业界主流RPC框架，例如：Dubbo、Google 开源的gRPC、新浪微博开源的Motan、Twitter 开源的 finagle也使用Netty来构建高性能的异步通信能力。另外，阿里巴巴开源的消息中间件RocketMQ也使用Netty作为底层通信框架。
TCP黏包/拆包
TCP是一个“流”协议，所谓流，就是没有界限的一长串二进制数据。TCP作为传输层协议并不不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。
粘包问题的解决策略
由于底层的TCP无法理解上层的业务数据，所以在底层是无法保证数据包不被拆分和重组的，这个问题只能通过上层的应用协议栈设计来解决。业界的主流协议的解决方案，可以归纳如下：
1. 消息定长，报文大小固定长度，例如每个报文的长度固定为200字节，如果不够空位补空格；
2. 包尾添加特殊分隔符，例如每条报文结束都添加回车换行符（例如FTP协议）或者指定特殊字符作为报文分隔符，接收方通过特殊分隔符切分报文区分；
3. 将消息分为消息头和消息体，消息头中包含表示信息的总长度（或者消息体长度）的字段；
4. 更复杂的自定义应用层协议。
Netty粘包和拆包解决方案
Netty提供了多个解码器，可以进行分包的操作，分别是：
* LineBasedFrameDecoder
* DelimiterBasedFrameDecoder（添加特殊分隔符报文来分包）
* FixedLengthFrameDecoder（使用定长的报文来分包）
* LengthFieldBasedFrameDecoder
netty分包
原文地址：https://www.cnblogs.com/heroinss/p/9873093.html