IBM 发布 Open Liberty 18.0.0.4,支持 MicroProfile 2.1 和反应性扩展框架

阅读数:5741 2019 年 1 月 28 日

IBM 在 2018 年第四季度发布的 Open Liberty 18.0.0.4 提供了对 MicroProfile 2.1、反应性扩展框架和连接池指标的全面支持。根据发布说明:

Open Liberty 现在对 JAX-RS 2.1 进行了反应性扩展,这样你就可以使用来自 Apache CXF 和 Jersey 的提供程序。在 ops 方面,Liberty 运行时提供了一些连接池指标,现在,你可以从 MicroProfile Metrics 特性提供的 /metrics 端点访问这些指标。

Open Liberty 于 2017 年 9 月首次推出,是 IBM WebSphere Liberty 应用服务器的开源实现,用于构建微服务和原生云应用程序。Open Liberty 对 MicroProfile 的持续支持确保了最新版本包含在季度发行版中。简单看一下 Open Liberty 的发行历史就能明白这一点:

  • 2017 年 9 月:17.0.0.3 —— MicroProfile 1.2

  • 2017 年 12 月:17.0.0.4 —— JSF 实现

  • 2018 年 3 月: 18.0.0.3 —— MicroProfile 1.3

  • 2018 年 6 月: 18.0.0.2 —— Java EE 8

  • 2018 年 9 月: 18.0.0.3 —— MicroProfile 1.4 和 MicroProfile 2.0

  • 2018 年 12 月: 18.0.0.4 —— MicroProfile 2.1

MicroProfile 2.1

Open tracking 1.2 MicroProfile 2.1 中唯一更新的 API,于 2018 年 10 月 19 日发布。新特性及改进特性包括:允许更有针对性的跟踪结果;更容易将跟踪请求与应用程序的 URL 关联起来;跳过 JAX-RS 请求跟踪;使用另一种 Open Tracing Span 名称格式;添加了新的 MicroProfile Config 1.3 API 键,支持新的 Open Tracing 函数。

JAX-RS 请求可以通过指定一个与UriInfo.getPath()相匹配的正则表达式排除在跟踪之外,该正则表达式定义在一个新增的配置键mp.opentracing.server.skip-pattern中。正则表达式必须符合java.util.regex.Pattern。IBM Open Tracing 知识中心详细说明了为什么排除 JAX-RS 请求跟踪:

可以通过指定跳过模式排除服务器端跟踪。你可能希望排除一些跟踪信息,以便跟踪特定的东西。在这种情况下,你可以选择排除服务器端跟踪,以减少所创建的 Span 数量。

新增的 Open Tracing Span 名称替代格式如下:

复制代码
<http method>:/<endpoint>/<endpoint method>

如 Open Liberty Open Tracing指南所示,下面是该格式的一个示例:

复制代码
GET:/inventory/list

要了解更多细节,请查看 Open Tracing规范

JAX-RS 的反应性扩展

使用 Open Liberty 18.0.0.4,可以通过 Apache CXF 和 Jersey 等提供程序对 JAX-RS(JSR-370)进行反应性扩展。在 Open Liberty 博客中,IBM Web 服务架构师 Andy McCright 最近讨论了 Open Liberty 中的 REST 新特性:

JAX-RS 2.1 引入了反应性客户端,但是规范只要求供应商使用 Java 8 的 CompletionStage API 实现它。其他反应性框架框架可以与反应性框架客户端集成,但在规范中这是可选的。借助 Liberty 18.0.0.4,我们现在可以使用这些扩展。我们已经使用来自 Apache CXF 和 Jersey 的提供程序对 RxJava 1 和 2 进行了测试,我们计划进行更多测试。

IBM WebSphere MicroProfile 和 Jakarta EE(EE4J)架构师 Kevin Sutter 向 InfoQ 介绍了这个最新版本,以及 2019 年关于 Open Liberty 的计划。

InfoQ:在即将发布的 Open Liberty 版本中,为 MicroProfile 的当前版本提供全面支持是否遇到了挑战?

Kevin Sutter:Open Liberty 曾经在 Eclipse MicroProfile 项目发布后的三个月内提供了完全支持的、可用于生产的 MicroProfile 规范实现。从项目的第一天起,我们就把这作为一个目标,并且我们很高兴能够遵守这个时间表。这有挑战性吗?当然。但是,这是一项大型的团队工作,这样更可行。我们参与每一项 MicroProfile 规范。有些是我们负责的,有些我们只是参与。但是,我们确实参与每一项规范。这给了我们一个优势,因为我们已经熟悉了各种规范的要求。在大多数情况下,在更广泛的 MicroProfile 团队正在继续定义它的时候,我们正在实现规范。在某些情况下,我们通过每月的 Liberty Beta 交付早期版本的实现。这些 Beta 版的反馈也可以反馈到规范的开发中。所有这些前期工作都有助于我们及时实现 MicroProfile 的目标。

MicroProfile 规范发布的其中一个要求是有一个开源的“兼容实现”。这个兼容的实现不一定是最终的版本或产品。但是,它必须证明规范是可实现的,并且 TCK 在上面成功执行。此外,它必须可用、可构建,并且可以通过一些公共的开源存储库进行测试(如 GitHub)。对于我们负责的大多数 MicroProfile 规范,我们在 Open Liberty 中开发兼容实现。一个例外是我们负责的 MicroProfile Rest 客户端项目,其兼容实现是 Apache CXF。但是,由于 Apache CXF 是 Open Liberty JAX-RS 实现的基础,因此,我们仍然间接地在 Open Liberty 中进行开发。无论如何,这些兼容实现并不是最终的版本。我们还有额外的工作要做,以确保这些实现是生产就绪的,并且得到完全支持。但是,为把它们加入 Open Liberty 的下一个发行版中,我们有了一个很好的开端。

InfoQ:关于 Open Liberty,2019 年有什么计划?

Sutter:我们在 2019 年所做的一个主要改进是采用四周一次的发布周期(而不是过去几年的季度发布)。压缩后的发布周期对我们的 MicroProfile 开发工作提出了一些新的挑战。如你所知,MicroProfile 每年都会发布几个版本。去年,MicroProfile 发布了三个平台版本(包括对 Java EE 8 的支持)。今年的计划是在 2 月、6 月和 10 月再发布三个平台版本。过去,我们的目标是在下一个季度的 Open Liberty 中支持这些 MicroProfile 版本。但是,在四周一次的发布周期中,“下一个 Open Liberty 版本”可能无法实现。因此,我们的新目标是在 MicroProfile 提供其平台版本之后进行两个为期两周的开发迭代。这实际上把我们之前在一个季度(12 周)内提供实现的目标压缩到了大约 8 周。我们看看能不能跟上。但是,按照我们的敏捷流程,我们只会在功能准备就绪时发布它——完全测试、生产就绪和完全支持。

InfoQ:您目前负责什么,也就是说,您每天都做些什么?

Sutter: 我的主要职责是为混合云组织的 MicroProfile、Jakarta EE 和 Java EE 总体开发提供指导。这就是我在“IBM 的工作”。在外部,我非常积极地与 MicroProfile 社区合作,共同领导 Eclipse 项目。我参与了一些组件规范,但我的主要关注点是确保平台交付的顺利进行。我还参加了 Jakarta EE 指导和规范委员会。将 Java EE 工件和流程移到 Eclipse 环境中是一项具有挑战性的工作——保留好东西,删除不好的东西。作为 PMC 和平台项目的一员,我还参与了 EE4J 工作的日常活动。这方面的最新活动是完成 Eclipse Glassfish 的 Java EE 8 兼容性测试。下一步工作涉及 Jakarta EE 8 的发布及其未来规划。

相关资源

查看英文原文:

https://www.infoq.com/news/2019/01/ibm-releases-open-liberty-18.4

收藏

评论

微博

发表评论

注册/登录 InfoQ 发表评论