TOMCAT升级——容器升级，通用方案

在容器升级后，碰到两个问题，现象及解决方案如下：

问题一：容器迁移完成后，启动项目后报错

问题原因：项目springboot框架实现 ，并且基于java8，修改配置启动后，心war包并没有实际进入Tomcat容器

解决方案：通过mvn clean install 后修复

问题二：相应目录权限不足，公司通过nginx反向代理了多个Tomcat容器，在请求路由过程中，nginx需要访问对应目录的文件，但是没有相关目录执行权限。

问题原因：nginx和Tomcat分别通过不同户用启动，在Tomcat启动脚本catalina.sh中默认设置了umask为0027，把其他用户的执行权限都取消了，通过修改umask值为0022后完美解决

那Tomcat升级后，测试需要如何入手来完成收尾工作呢？

1、Tomcat的变更记录，科一简单梳理一下

1）重点在序列化和连接池模块，是否有较大的变更，如果有，需要从请求处理，持久化和性能方面进行针对性测试，最简单方法可以从报文对比入手

2）部署测试环境变更（软硬件两方面）是否与产线环境类似，特别是目录路径、启动用户及相关权限是否一致，设置是否合理，列如出于安全考虑，大部分情况下，产线用户权限比测试环境少的多；

3）启动参数是否有变更等。

3、Tomcat的自身功能。Tomcat一般用于作为servlet和jsp的容器，在互联网公司，一般用于动态资源访问的处理，所以需要关注服务是否正常启动，是否可以正确处理http和https的各种请求，是否可以正确支持文件下载及上传请求等。

4、Tomcat的上下文链路，在互联网整个架构体系中，Tomcat作为大部分层的默认容器，通常和nginx等配合使用，所以需要从nginx或者其他需要读取Tomcat相关目录的程序方面入手，例如前面的权限不足问题。

5、Tomcat升级流程完整顺序，前后依赖要梳理清楚，做到上线过程中有条不紊，不会因为顺序错乱导致未期错误。

6、Tomcat升级过程中，多版本并存对业务兼容性的影响，这个主要取决于后台服务的发布方案，是否存在新老版本Tomcat容器并存接受产线流量的情况，如果类似蓝绿发布，可以不考虑这种情况。

7、Tomcat升级业务监控大盘，是否确定了发布时的监控大盘及监控方案，做到问题发生时，可以第一时间知晓，而不是客诉。

8、Tomcat升级失败的回退方案，由于产线情况的复杂性，测试人员在测试环境只能尽可能保证绝大情形下的质量交付，如果未知错误发生时，需要第一时间回退，保证业务的连续性和稳定性，而不是业务的停顿。

9、Tomcat升级完成后，前端新旧版本应用及不同入口(例如安卓或者iOS等，甚至不同打包工具版本的差异)的兼容性，主要是序列化、反序列化及数据传输格式的差异可能会带来未知错误。