内购订单进行二次处理_订单导出复杂逻辑信息及性能优化的思考

PS：在家办公期间，总结一些思考和实例case，脱敏发出。愿与广大知乎的研发伙伴一起探讨技术，交流思想。欢迎私信~

一、背景

订单导出需要增加员工部门、成本中心、商品明细、地址所属城市、楼宇等信息，同时需要以其他商品增加一个sheet展示订单信息，功能上看似比较简单，但是这些信息并没有记录到订单信息表中，需要直接或者间接调用第三方soa服务获取和组装，相对本地处理，soa调用比较耗时，尤其是在大批量导出等时候容易暴露各种各样等问题。

二、研发过程

1. 功能分析与排期：
   与多数同样简单地认为只是加几个字段的导出和展示，简单地排了比较短的时间；
2. 开发过程：员工部门：订单表中没有部门信息，需要通过企业id加手机号通过基础的soa接口进行获取这样一来一条订单数据可能就需要调用多次soa服务来获取部门信息；成本中心：每条订单需要调用一次soa接口获取；商品信息：需要通过订单id本地批量查数据库，量多了导致单次查询耗时比较久；城市楼宇：每条订单需要调用一次soa接口获取；优惠券明细：每条订单需要调用一次soa接口获取，同时需要比较复杂的解析和拼接包装操作；
3. 踩坑：
   单次导出每一条订单数据需要接近10次的soa接口调用，依赖网络io操作次数很多，耗时比较久；
   导出Excel表格涉及到接近40个字段的处理、组装甚至是字符串的转化和拼接操作，cpu消耗比较高；
   导出Excel需要将全部需要的数据在内存中处理好一次性上传到文件服务器，对内存的消耗比较大，大批量数据导出很容易导致oom；
   历史代码冗长难读，逻辑不够清晰，理解成本极高，本次对代码逻辑做了一次梳理；
   所有的订单逻辑处理过程中任何一小处一个字段没有做好防御就可能导致异常抛出导出失败，用户体验比较差；
   导出服务与C端服务公用集群机器和服务，在大量导出任务的情况可能导致C端接口访问性能下降甚至超时、服务趋于不可用；

三、性能及问题暴露

需求功能开发完成后于11月19日上线后发现以下性能问题，并及时进行降级处理：

1. 出现多次oom；
2. 在导出的时候jvm出现多次的fullGC操作；
3. C端接口耗时比较高；
4. CPU出现飙高现象；
5. 查询数据库耗时较长；
6. 运营同学发出批量导出订单请求后等待半小时文件才能提供下载；
7. 导出少量数据发现任务一直停滞于导出中的状态；

四、优化方法与效果

1. 存量数据：将以上需要的关联数据离线组装并写入到elastic search中存储；
2. 增量数据：在订单创建和完结的时候将相应的关联数据增量写入到elastic search中，导出的时候只需要做少量解析操作即可满足要求，快速导出；
3. 优化功能11月28日发布，效果比预期想象当中的要好，导出数据耗时如下，总体性能呈现耗时与导出条数基本成正比的关系：
   导出27,630条订单数据耗时14S
   导出44,723条订单数据耗时23S
   导出113,723条订单数据耗时68S

五、总结思考

1. 对于任何的业务设计都需要从功能性、性能要求等多维度进行设计思考与评估；透过表象往本质等方向多思考；
2. 目前企业订餐订单量呈现与日俱增等良好趋势，对于订单数据的导出性能需求日益凸显，需要优化和提升等想象空间依然不小；
3. 深入运营和业务的纬度，去了解一下导出等目的和用途是什么，哪些信息是必要等，哪些可以删节，是否可以更加精化？
4. 从产品功能的纬度，存在导出按钮误点，而默认等条件是当月等数据，日后单月等数据量可能是数百万上千万级，我们是否将导出按钮进行一些二次确认校验甚至是权限上等限制？
5. 从技术的纬度，将导出的文件内存操作转化为流式化写入硬盘的操作可以进一步实现，可有效解决吃内存的问题。

六、存在的问题思考与探讨Q&A

1、Q:离线存储如何保证每一个需要soa扩展调用的字段都获取成功？
A:离线数据完整性做强check的成本会比较高，可以考虑做成调用获取失败后记录和通知机制，自己消费消息对问题部分进行重试补全，由于此类数据通过后台可以进行实时查询，所以这里考虑通过此类方式达到弱一致性的最终目的；
2、Q:内存中大数据量处理，如何隔离，避免系统oom，间接影响其他正常接口（也许就是一个非关键路径影响关键路径的事故）？
A:目前已经将后台服务走独立的集群，跟C端服务物理隔离，避免影响到核心到C端链路；
A:通过POI的SXSSF的流式生成文件的方式，不在内存中生成整个文件一次性导出，而是通过分批处理进行文件追加到文件中，内存能够及时回收，进而有效避免出现OOM问题导致服务不稳定到问题；
3、Q:从产品体验角度，导出时间是否可以预估，如何预估？
A:要实现有效预估，必须要保证全链路的服务能够有高可用高性能的基本保证，在此基础上，可以达到该目的，导出时间与导出条数成正比的线性关系。现状是会受到下游ES性能的制约，在下单高峰期，ES的性能有所下降会导致耗时比较高，可以考虑ES集群隔离部署。

若有疑问或者更优的方案欢迎交流探讨。