这篇文章总结了如何成功将微服务从Java 8迁移到Java 11。
对于每项服务，已经完成了以下步骤：
- 使用Java 11编译代码
- 在Java 8上运行Java 11兼容服务
- 在Java 11上运行该服务
实际上，我们有一些额外的步骤，因为当我们开始迁移时，Java 11还没有发布，我们只能使用Java 10. 假设代码是在Java 10上编译的，那么迁移到的工作就不会那么多了。 Java 11和Jigsaw项目引入了Java 11作为模块化的最大变化。谢天谢地，就是这样！
1.使用Java 11编译代码
我们不得不提高我们正在使用的大多数框架和工具的版本。特别是，我们必须处理从Spring Boot 1到2以及Spring 4到5的迁移。由于这些是主要版本，我们必须修复几个重大变化。
对于Spring Boot 2，Spring Boot 2.0和Spring Boot 2.1的官方迁移指南编写得很好并且详细。
- 配置文件加载已经演变
- 属性轻松绑定是有点不够放得开
- 某些属性已重命名，其他属性不可用（例如security.basic.enabled property，必须替换为a WebSecurityConfigurerAdapter）
- 一些端点被重命名（例如执行器健康检查）
- 现在默认禁用bean重载，这是我们在集成测试中使用的东西，我们不得不使用新属性重新启用它spring.main.allow-bean-definition-overriding。
在Spring5迁移是从视图与一些小的改动代码点非常简单。困难的部分与项目遗留的事实有关，我们必须处理复杂的Spring XML配置和迁移到Dropwizard Metrics 4。
很少有框架仍然与Java 9+不兼容，除非它们没有得到社区的积极维护。在我们的案例中，我们必须找到Cassandra Unit的解决方法。我们不打算花时间更改测试框架，因此我们计划迁移到DynamoDB。
我们还必须处理Maven依赖地狱，因为一些必需的依赖项带来了与Java 9+不兼容的旧依赖项。在大多数情况下，在POM中添加一些排除项解决了这个问题。
我们在bash配置文件中添加了一组简单的别名，以便在Java版本之间切换。
alias setjava8=”export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home/” |
在IntelliJ上，可以从项目设置（“Project SDK”下拉列表）更改Java版本。
CI环境：
对于持续集成方（我们使用Bamboo），我们更新了代理以使用Java 11. 我们注意到，由于计划配置是全局的，因此不可能为分支计划和主计划提供不同版本的代理。这意味着如果其他人正在将更改推送到master（例如，新功能或完全独立于Java 11迁移的错误修复），则将代理更新为Java 11将破坏master。
为了缓解此问题并避免红色构建，我们必须确保项目正在使用Java 11进行编译，并且在更新代理之前所有测试都在本地传递，以便快速合并Java迁移拉取请求。另一个选择是在Java 11上分支计划为绿色时暂时将代理程序设置为Java 8，而不会忘记在合并之前将其设置回Java 11。
2.在Java 8上运行Java 11兼容服务
一旦所有内容都修复，合并并且主构建为绿色，我们必须确保Java 11兼容版本在我们的测试环境中正常运行。基本上确保没有任何损坏...我们有单元，集成和端到端测试，所以我们的信心水平相当高。
为了安全起见，我们对API进行了一些额外的探索性和手动测试，并提供了一些异常和边缘案例请求，以确保其行为正确。我们还确保日志和Grafana仪表板都很好。
下一步是将新版本推向生产。即使代码与Java 11兼容，该服务仍然使用Java 8运行，我们不想同时引入太多更改，毕竟我们不喜欢有风险的版本。由于多次重构和版本提升，我们特别小心处理此版本。在查看Grafana仪表板几天后，比较迁移前后的指标，结果表明一切顺利。
3.在Java 11上运行服务
最终目标是在Java 11上运行服务。理论上，它将像更新Docker文件一样简单，比如使用Java 11映像并在生产中推送工件。然而，在实践中它并不那么简单......
首先，我们必须更新Java JVM参数（该-d64[url=https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8180286]参数已弃用[/url]，将阻止服务启动，我们还必须更新GC日志参数）
然后，我们很快意识到服务日志已经从我们的本地生产环境中的Splunk中消失了，这些日志实际上是在AWS上正常工作时显示的。我们必须以更新的logback配置来解决这个“时间失真”;通过更新）日期模式从%d{ISO8601}到%d{yyyy-MM-dd’T’HH:mm:ss.SSSZ,UTC}。
在部署到生产期间出现了另一个奇怪的错误VerifyError: Bad type on operand stack，AppDynamics因为一些奇特的字节码操作而阻止某些实例启动。由于某些原因，它在prod-canary上很好，然后在几个实例上成功部署后开始失败！我们不得不禁用AppDynamics，这很好，因为我们在团队中没有使用此工具。
当我们转向Java 11时，我们还必须更新一些Grafana仪表板以使用新垃圾收集器的G1。
结论
今天，我们项目中使用Spring Boot 2提供用户通知的3个服务，以及使用Spring 5提供网站页眉和页脚的1个服务已经在Java 11上运行顺利有几个星期了。使用默认的G1垃圾收集器，我们没有遇到任何与内存占用或任何其他性能问题相关的奇怪行为。另一方面，我们的响应时间没有任何改善。
下一步是什么？Java 12将于2019年3月发布。目前，我们仍然不知道是否将使用此版本或等待下一个Java LTS。它可能取决于包含哪些功能。