大报文之道：优化策略与实践

liaozxbj

已于 2024-03-27 21:01:34 修改

阅读量738

点赞数 19

文章标签：架构后端分布式 java

于 2024-03-27 20:59:05 首次发布

本文链接：https://blog.csdn.net/liaozxbj/article/details/137089302

版权

本文探讨了在接口开发中如何识别和处理大报文问题，特别是针对主子模型的接口，提出了从AppA和AppB两个角度优化的策略，包括设置超时与重试、压缩数据、异步处理、分批处理和多线程等方法，以确保系统的稳定性和性能。

摘要由CSDN通过智能技术生成

写在前面

在做正常的需求开发时，当我们提供了一个接口或是调用别人接口时，我们需要考虑接口除了正常的逻辑处理外，还需要考虑接口能接收报文的上限，性能，响应时间等一系列非功能性需求。如果不注意这些问题，就可能在某一天的某个时刻收到一系列系统告警，严重者甚至导致系统不可用，引发线上事故。如涉及明细列表相关的接口中没考虑明细的上限，某一时刻上游下发了一个大明细从而可能就引发了上述的问题。这就是日常所说的大报文，其特点就是单次请求的数据量特别大，超出了系统正常的处理能力，需要耗费较长的时间才能处理完成。面对此类非功能性需求，在日常的开发中如何去避免和解决呢，今天主要带来的是主子模型下，明细行过大的处理。

一、识别大报文

大报文一般来源于批量接口或单个接口中入参为主子模型的接口，如果是消息队列，则是一次发送的消息中消息报文里发送了多条业务消息或是消息的报文结构也为主子模型的消息导致。

批量接口模型
Response<List<T>> method(List<T> list);

单个接口入参为主子模型
T method(OrderInfo orderInfo);

class OrderInfo{
   List<OrderDetailInfo> orderDetailInfoList;
}

class OrderDetailInfo{
}

对于批量接口或是消息队列里发送了多条业务消息的情况在这不做过多阐述，通常的逻辑是改为分批调用或分批