背景：
随着4.x的系统改造深入和进展，后续将会启动5.x，架构部已先行研究了5.x需要用到的部分技术，其中有不少是基于JDK1.8进行的。所以，我们考虑将先行的JDK1.7升级到JDK1.8.
分析：
JDK升级主要关注点：
1.系统内部组件（jar）的兼容性
2.系统运行的容器支持
3.系统间jar包（接口）依赖的兼容
整体升级策略：
逐渐升级，由上而下，通过不断尝试，找出升级可能出现的问题。ps：已用管理员账号登入jenkins查过，是可以支持配置多个jdk版本的。
步骤：
1.从dubbo和mq等管理平台上拉出系统整体上的调用层次关系。（或者人工梳理）
2.找出被依赖最少的几个系统，然后挑最不重要的系统，作为测试系统；
测试系统建议涵盖多种技术类型（无需同时），如web，dubbo，mq，Job，pc，手机端等。
链路层次短的关联系统一并参与测试。
对于少数依赖系统已升级，被依赖系统来不及升级的情况，将依赖方提供的接口层代码用低版本jdk打包后，供被依赖方使用。
3.切分支，升级开发环境jdk，修改问题，记录过程。
4.jenkins打包
5.一测发布x系统及对应的关联系统（含java环境升级）
6.排查、修复发现的问题，记录过程。
7.发布到二测
8.排查、修复发现的问题，记录过程。
9.发布到生产并验证及修复
10.升级成功
备注：
关于回滚操作：
1.原则上不建议安排回滚，主要通过充分的测试进行问题排除，对于微量遗漏的问题，上线后作为bug处理。
2.对于最初的或最重要的系统升级，如果考虑回滚，则准备一套相同配置的新设备发布完成后，停机切换，如果验证失败，则向反方向进行切换。具体步骤暂略。
经验汇总：
待升级的系统分两种情况：
- 要升级系统的被0个系统依赖
POM中添加依赖包
<dependency>
<groupId>org.javassist</groupId>
<artifactId>javassist</artifactId>
<version>3.18.2-GA</version>
</dependency>
- 要升级的系统被大于0个系统依赖
POM中添加依赖包
<dependency>
<groupId>org.javassist</groupId>
<artifactId>javassist</artifactId>
<version>3.18.2-GA</version>
</dependency>
同时提供1.7的jar给依赖方