前言

业务的临时需求，需要开发一个订单EXCEL导入的功能，从开发到上生产差不多是5天。在SIT环境上，导入400条数据大概是1分钟，于是和客户沟通的是100条数据随便导，但在UAT环境却发现100条数据导入超时的情况。由于数据的导入涉及多库多表的存储，所以对几个核心的feign接口都打上了日志，重新发了版UAT，发现在对主数据做校验的接口上，在SIT和UAT上耗时相差甚远。于是检查了数据库发现，SIT的主数据量在1万多条，UAT是18万条！这件事对我影响还蛮大的，让我在之后思考的时候会从更多的维度去做考虑。

解决问题的思路

由于时间比较赶，客户马上就需要在生产上使用该功能，于是我打算从配置出发，先解决问题，在优化代码。先看前端的请求。 1分钟就超时了。所以我打算先调长前后端的交互时间，保证数据的正常导入。先看下配置中心网关的配置。 将ribbon的超时时间和hystrix的熔断时间都调长，这里的单位是毫秒。然后重启网关。 前端仍然显示超时，但后端仍在运行，并且所有的数据都保存到了数据库中。认真看了下请求的response，发现里面有一段日志 If you are the system administrator of this resource then you should check the error log for details. Faithfully yours, nginx 于是我去检查了下nginx的错误日志，发现里面有一段 upstream timed out (110: Connection timed out) 百度了一下发现，nginx的server里缺少了一段配置 large_client_header_buffers 4 16k; # 读取大型客户端请求头的缓冲区的最大数量和大小 client_max_body_size 300m; #设置nginx能处理的最大请求主体大小。 client_body_buffer_size 128k; #请求主体的缓冲区大小。 proxy_connect_timeout 600; proxy_read_timeout 600; proxy_send_timeout 600; proxy_buffer_size 64k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k;

如果 proxy_connect_timeout、proxy_read_timeout、proxy_send_timeout不做配置，则默认是60S，到此前端超时导入失败的原因就解决了。

根据业务数据定制代码

回过头来看看代码是如何优化的。导入耗时主要是在对主数据的校验，验证name是否存在，然后拿回code进行赋值。我看了下业务导入的数据发现，基本是按同一家公司的数据进行导入的，于是在对主数据校验之前，我加了一个判断 如果和前一个的数据相同，则直接赋值，不再调用feign接口进行校验，也减少了微服务之间交互的次数。至此，导入功能成功满足客户需求，按时生产上线。