2. 单体报表导出服务的现状分析：代码耦合、性能瓶颈、扩展性差、典型问题复盘

在微服务拆分之前，绝大多数报表导出功能都生长在单体应用内部。本章从代码结构、性能特征、扩展能力三个维度剖析单体模式的痛点，并通过一个真实案例复盘，为后续的 gRPC 接口契约设计提供“反面教材”。

2.1 代码耦合：导出逻辑与业务逻辑的“意大利面条”

单体报表导出模块最典型的症状是职责混杂。一个导出请求往往横跨多个业务领域，而代码层面却集中在同一个 Service 类中。

2.2 性能瓶颈：内存与 I/O 的双重挤压

单体架构下，报表导出是典型的“重操作”，对应用服务器的内存和线程资源造成巨大压力。

• 内存溢出风险：导出百万级数据时，List<Object> 一次性加载到堆内存，频繁触发 Full GC，甚至 OOM。
• 线程阻塞：导出操作通常占用一个 Tomcat 线程直到文件生成完毕，高并发下线程池迅速耗尽，影响正常 API 响应。
• 数据库连接耗尽：导出查询执行时间长，占用数据库连接池连接，导致其他业务查询排队等待。

2.3 扩展性差：加功能等于加风险

单体导出模块的扩展性困境体现在三个层面：

1. 新增报表类型困难：需要修改核心导出路由，增加 if-else 分支，容易破坏已有报表逻辑。
2. 无法独立扩缩容：导出是 CPU 密集型 + I/O 密集型操作，却与无状态 API 共享同一进程，无法单独为导出分配更多资源。
3. 技术栈锁定：所有导出逻辑必须使用与单体相同的语言和框架，无法引入更擅长处理大数据量的专用工具（如 Spark、Flink）。

2.4 典型问题复盘：一次“导出拖垮全站”的事故

某电商平台在双十一大促期间，运营人员触发了一次“全量订单报表导出”。以下是事故时间线：

2.5 单体模式的核心矛盾总结

从上述分析可以提炼出单体报表导出服务的三个核心矛盾，这些矛盾正是后续 gRPC 服务拆分和接口契约设计要解决的目标：

• 资源隔离矛盾：导出操作与业务操作共享线程池、内存、数据库连接，缺乏故障隔离能力。
• 伸缩性矛盾：导出负载特征（长耗时、高内存、低并发）与业务 API（短耗时、低内存、高并发）完全不同，却无法独立扩缩容。
• 契约模糊矛盾：导出接口没有明确的输入输出契约，参数透传内部数据结构，导致调用方与实现方高度耦合。