微服务架构中列表和导出的问题

Question

*架构介绍：

前端页面http请求gateway，usercore和filecore均是两个独立的dubbo服务，暴露rpc接口，gateway网关rpc请求usercore和filecore两个模块

问题：

现在有一个管理后台，后台中有一个列表，这个列表分别有这样几个字段

表格中班级编号字段和班级名称字段是从“班级表”中取得，其他字段均是从“学习时长表”、“学生表”等各个表中获取数据进行计算得来的，并且还需要根据“参与度百分比”排序

基于现有的架构，我们在usercore的模块中开发了一个service，在service中先通过mybatis请求了各个表，然后在代码中将数据汇总、计算、排序、分页，得到一个列表，然后将这个列表返回给前端，前端进行展示

现在还有一个需求，就是需要将个列表进行excel导出，由于整个列表的数据量大，导出时的文件处理非常占内存和io，所以我们设计了filecore来做文件相关的处理

但是这个地方的问题在于，由于列表中的数据需要请求多张表，然后进行计算、汇总、统计、排序等一系列复杂的操作，并且这些操作已经在usercore实现过了

难题： 1、如果在filecore做文件导出，势必需要在写一遍usercore已经有的计算统计逻辑，重复代码难维护 2、如果在usercore做文件导出，那么非常占io和内存，对usercore这样一个在线服务的压力太大 3、如果在usercore将数据查询出来，再请求到filecore，那数据的传输太大，非常占网络带宽 4、如果在usercore将数据查询出来并且存储到缓存中，再由filecore来读取并生成文件，这样对redis的压力过大，可能导出的数据有几十万，如果遇到多个人同时导出，那么压力会成倍增加

so

求解，，，感谢

Answer 1

如何共用，涉及到多数据源的，除非也要把数据源封装，您说的这个方案我试过，行不通

Answer 2

回复
@王建观 : 正常导出数据怎么会跨数据源的？如果数据结构建议在数据库层面做处理，比如做一个专门用于统计的库，或者放在es等地方，再进行处理

Answer 3

可以把逻辑封装在service，然后共用service。

Answer 4

数据并非是多表关联就能够查出来的，而是要经过代码计算的

Answer 5

数据库预先做个表视图了解下? 然后直接查这个虚拟表 

Answer 6

不好回复你，呵呵，这个是我考虑的方案之一，但是这个落地难，

Answer 7

redis压力是很大

Answer 8

第四个方案比较靠谱，redis压力如果大可以做集群（理论上不会太大）。

对于导出大量用户要导出这样的场景，建议设置队列，导出完成后上传到对象存储，给客户提供下载链接即可。

你可以参考下一些服务商提供的数据库备份下载的体验和逻辑。