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

王建观 发布于 09/17 10:16
阅读 166
收藏 1

*架构介绍:

image.png

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

问题:

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

image.png

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

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

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

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

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

so

求解,,,感谢

加载中
0
gammey
gammey

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

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

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

王建观
王建观
redis压力是很大
王建观
王建观
不好回复你,呵呵,这个是我考虑的方案之一,但是这个落地难,
0
yekern
yekern

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

王建观
王建观
数据并非是多表关联就能够查出来的,而是要经过代码计算的
0
Joyzhou
Joyzhou

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

Joyzhou
Joyzhou
回复 @王建观 : 正常导出数据怎么会跨数据源的?如果数据结构建议在数据库层面做处理,比如做一个专门用于统计的库,或者放在es等地方,再进行处理
王建观
王建观
如何共用,涉及到多数据源的,除非也要把数据源封装,您说的这个方案我试过,行不通
返回顶部
顶部