文章目录

最近因为太忙了,停更了两个多月。今天开始正式更新,先对最近的项目进行复盘写起吧。

有的时候,我们需要将一部分报表数据以 Excel 文件的形式进行导出,并以离线的方式进行查阅。对于 Excel 报表导出,一种做法是服务端提供 JSON 格式的报表数据,前端基于 HTML5 的 JavaScript 功能控件实现 Excel 的导出功能,这种做法的好处在于服务端的 API 接口具有复用性,减少服务端的性能压力,并将生成报表的压力转移到了前端。但是,如果存在 Excel 的样式渲染,就有点力不从心了。

另一种做法是全部由服务端实现 Excel 的生成与渲染,并提供给前端进行导出。Java 语言中,最常用的操作 Excel 的类库包括 jxl 和 poi。 jxl 是一个比较老的框架,只能支持低版本的 excel,即 .xls 格式的 Excel,比如 Excel 95, Excel 97, Excel 2000, Excel 2003 等版本,但是在 65535 行以下量级的数据性能更好些。poi 是 apache 的项目,可以支持 .xlsx 格式的 Excel,包括 Excel 2007, Excel 2010 等版本。因此,现在主流操作 Excel 的类库是 poi。现在,我们来参考 poi 操作 Excel 的类图。

值得注意的是,一般情况下,报表导出是同步执行,通过字节流的方式与前端通信。此外,我们也可以将生成的 Excel 报表文件先上传的资源中心,并生成 URL 地址返回给前端供用户下载,这样可以利用 CDN(内容分发网络)将网络内容发布到靠近用户的边缘节点,使不同地域的用户在访问相同网页时可以就近获取。

为了减少服务端的压力,对于报表导出的数量需要进行限制,例如一次只能导出 5 万条记录,并且建议用户分批导出。

此外,如果数据源都是在存放在当前系统中,那么处理起来就方便地多,只需要通过 JDBC 获取到数据源并且进行 Excel 的生成与渲染。然而,如果部分数据源存储在外部系统中,那么就需要 RPC 调用或者 RESTful API 调用才能获取到。这样,一方面会很大影响到性能,另一方面可能存在接口调用超时。此时,优先考虑将数据冗余到本地,其次折中的处理方案是,调用失败或者调用超时进行重试来实现数据补偿,并且在重试之后无法获取到某些外部数据时,进行一个友好的提示,例如“系统太累了,暂时没有取到哟”。

有时,报表导出等待时间太久会导致 Nginx 超时,我们可以将报表导出改变成异步方式,当用户发起报表导出请求后,服务端立即响应应答,并异步执行 Excel 的生成与渲染。当完成任务时,通过消息队列或者心跳包机制通知前端进行下载。

(完)

微信公众号

文章目录