Java 11迁移成功案例

栏目: Java · 发布时间: 5年前

内容简介:这篇文章总结了如何成功将微服务从Java 8迁移到Java 11。对于每项服务,已经完成了以下步骤:实际上,我们有一些额外的步骤,因为当我们开始迁移时,Java 11还没有发布,我们只能使用Java 10. 假设代码是在Java 10上编译的,那么迁移到的工作就不会那么多了。 Java 11和Jigsaw项目引入了Java 11作为模块化的最大变化。谢天谢地,就是这样!

这篇文章总结了如何成功将微服务从 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.0Spring Boot 2.1 的官方迁移指南编写得很好并且详细。

  • 配置文件加载已经演变
  • 属性轻松绑定是有点不够放得开
  • 某些属性已重命名,其他属性不可用(例如security.basic.enabled property,必须替换为a WebSecurityConfigurerAdapter)
  • 一些端点被重命名(例如执行器健康检查)
  • 现在默认禁用bean重载,这是我们在集成测试中使用的东西,我们不得不使用新属性重新启用它spring.main.allow-bean-definition-overriding。

在Spring 5迁移 是从视图与一些小的改动代码点非常简单。困难的部分与项目遗留的事实有关,我们必须处理复杂的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/”
alias setjava10=”export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home/”
alias setjava11=”export JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk-11.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。它可能取决于包含哪些功能。


以上所述就是小编给大家介绍的《Java 11迁移成功案例》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

运营笔记

运营笔记

类延昊 / 天津人民版社 / 2016-12-1 / CNY 39.80

运营是入门浅但学问深的行当。一个入门很久的人不见得能在11年内爬到塔尖,同样一个初入龙门的人占据高位也不见得非用11年。 到底该怎么做运营?如何做运营才不至于让自己忙死累死甚至茫然不知所措?如何和用户进行有效沟通?如何把握住处于塔尖20%的核心用户?如何强敌逼阵时快速找到突破口?如何挤破头皮提高转化率? 在这本书里,类类以自己常年战斗在一线摸爬滚打的经验给予了有效而真诚的解答。一起来看看 《运营笔记》 这本书的介绍吧!

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

在线进制转换器
在线进制转换器

各进制数互转换器

SHA 加密
SHA 加密

SHA 加密工具