通用下载组件,你会吗

前言

下载,是一种常见的业务场景,而【下载】这个动作,其实可以从业务中抽离出来,使其作为一个通用的下载组件,有需求的业务方直接接入即可,避免重复开发。

通用数据下载中心(导出),旨在提供通用的,接入便捷,高效,稳定的数据下载服务

原始

每个服务自己写下载操作:

弊端:

  1. 如果数据量大,将假死在下载页面,交互上不友好
  2. 不方便管理
  3. 代码冗余

针对这些弊端,我们将一一解决!

解决方案

1、异步下载:

针对第一点,数据量大的情况下,我们可以采用异步的方式

  • 用户点击下载时,同步返回下载任务taskId
  • 前端轮询通过taskId获取下载数据

2、下载文件统一存储

针对弊端2(不方便管理),我们一般将下载的文件统一存储,比如 云服务商提供的OSS,对外暴露文件链接即可。

业务上可以自己统一管理这些下载的文件,同时也可以多次下载。

这里你一般需要额外提供一个下载管理页面,管理下载的状态、链接等等,类似于:

3、抽象通用组件

到目前为止,你可能发现了,每一个服务都在自己处理下载操作,并且下载动作的雷同,代码看起来很冗余,接下来我们尝试将下载进行抽象成独立于业务之外的组件。

方案1:写一个通用组件SDK,有需要的应用直接依赖SDK,这样一来,应用方就不需要关注下载这块逻辑,只需要写提供数据的部分即可。

可以看到,SDK统一封装下载逻辑,下载中心生成、管理下载任务,当然,文件上传可以直接从SDK到云OSS,也可以先从SDK将数据推送到下载中心,再由下载中心生成文件上传到云OSS。

方案2:让下载中心承担更多,主要做下载任务提交、下载管理、上传OSS等能力,应用层则提供数据接口,方便下载中心通过接口获取数据。

当然,以上两种方式都已经在生产实践过,各有各的好处,你可以按需选择。

更优解

当你需要导入的数据量级比较大时,你的系统压力可能会过载,频繁GC,最终可能会导致OOM。

怎么优化?

拉取一批数据追加写入到本地文件然后释放内存,保证对象在新生代可回收,预计大数据量导出时内存增长为锯齿波型图。

这里我们通过方案2进行优化:

相关推荐
夜月yeyue几秒前
个人写HTOS移植shell
c++·mcu·算法·性能优化·架构·mfc
沐雨橙风ιε11 分钟前
Spring Boot整合Apache Shiro权限认证框架(应用篇)
java·spring boot·后端·apache shiro
考虑考虑15 分钟前
fastjson调用is方法开头注意
java·后端·java ee
小蒜学长35 分钟前
springboot基于javaweb的小零食销售系统的设计与实现(代码+数据库+LW)
java·开发语言·数据库·spring boot·后端
brzhang44 分钟前
为什么 OpenAI 不让 LLM 生成 UI?深度解析 OpenAI Apps SDK 背后的新一代交互范式
前端·后端·架构
EnCi Zheng1 小时前
JPA 连接 PostgreSQL 数据库完全指南
java·数据库·spring boot·后端·postgresql
brzhang1 小时前
OpenAI Apps SDK ,一个好的 App,不是让用户知道它该怎么用,而是让用户自然地知道自己在做什么。
前端·后端·架构
Lei活在当下1 小时前
【业务场景架构实战】7. 多代智能手表适配:Android APP 表盘编辑页的功能驱动设计
android·设计模式·架构
LucianaiB2 小时前
从玩具到工业:基于 CodeBuddy code CLI 构建电力变压器绕组短路智能诊断系统
后端
Jolie_Liang2 小时前
保险业多模态数据融合与智能化运营架构:技术演进、应用实践与发展趋势
大数据·人工智能·架构