一个奇葩问题，虽然解决了，但还是没弄清楚，小记一笔。
年后回来，测试人员对年前的3次迭代的功能进行了回归测试，然后发现所有excel导入的功能都失效了。作为后台开发人员，当然是第一时间打开运行日志排查原因啦。但奇怪的是，后台日志中并没有ERROR信息......于是乎转战到前端，通过chrome的开发工具发现如下异常：
org.springframework.web.multipart.MultipartException: Could not parse multipart servlet request; nested exception is java.io.IOException: The temporary upload location [/tmp/tomcat.439562935221680911.8769/work/Tomcat/localhost/ROOT] is not valid org.springframework.web.multipart.support.StandardMultipartHttpServletRequest.parseRequest(StandardMultipartHttpServletRequest.java:112) org.springframework.web.multipart.support.StandardMultipartHttpServletRequest.(StandardMultipartHttpServletRequest.java:86)
.......
从异常信息来看，其实不难理解，就是上传文件的临时目录失效了，百度以后确实如此。但是为什么过完年回来目录就突然失效了呢？
继续查询相关资料后了解到，springboot启动时会创建一个用于上传文件的临时目录，而系统会在10天后自动清除该目录。
解决方法：
1、重启服务，重新生成目录；
2、手动创建该目录；
3、在启动服务的main方法中，添加以下代码，指定上传文件的目录：
@Bean
MultipartConfigElementmultipartConfigElement() {
MultipartConfigFactory factory =new MultipartConfigFactory();
factory.setLocation("/data/apps/temp");
return factory.createMultipartConfig();
}
4、在应用的配置文件中添加以下配置，原理同3：
server:
tomcat:
basedir: /data/apps/temp
实践证明，以上方法都没有解决我的问题...
接着，我进入到服务器的tmp目录，发现里面已经创建了多个tomcat的临时文件，看日期应该是我多次重启产生的。那么正常情况下，解决方法1应该已经生效了（虽然不能永久性解决这个问题），为什么还是报异常呢？令人蛋疼的是，新创建的临时目录的端口都是8491，就是我重启的服务的端口，但是异常中的临时目录端口是8769，而8769正是zuul网关的端口。于是，我在zuul的配置文件里加上了解决方法4的配置信息，果然就好了...
令我不解的是，如果是zuul的问题，那么一开始应该就无法上传，而不会等到年后才出现问题。
