通用下载组件，你会吗

前言

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

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

原始

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

弊端：

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

针对这些弊端，我们将一一解决！

解决方案

1、异步下载：

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

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

2、下载文件统一存储

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

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

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

3、抽象通用组件

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

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

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

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

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

更优解

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

怎么优化？

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

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