Eclipse Foundation最近发布了MicroProfile 1.2版,该版本提供了下列新增API:
\\Health Check API可以判断计算节点是否即将终或关闭,随后会使用正常运行的新实例替换这样的节点。该API包含了内建的类注释@Health
,该类必须实现HealthCheck
接口并覆盖call()
方法。
Health Metrics API为每个计算进程提供了众所周知的监视端点和度量值,并提供了下列内建注释,可添加到任何类或方法中:
\\@Counted
- 将方法、构造函数或类型标记为计数器(Counter)。 \\ @Gauge
- 将方法标记为计量器(Gauge)。 \\ @Metered
- 将方法或构造标记为已度量(Metered),并追踪它们的调用频率。 \\ @Timed
- 将已注释对象的方法或构造标记为已计时(Timed),并追踪这些已注释对象的调用需要花多长时间完成。 \\ @Metric
- 请求注入或注册某个度量值(Metric)。\Fault Tolerance API提供的新策略以及相应的注释可添加至任何类或方法:
\\@Timeout
- 定义必须的超时时间。 \\ @Retry
- 定义必须进行重试的条件。 \\ @Fallback
- 为失败的执行提供了备选解决方案。 \\ @Bulkhead
- 防止系统超载或无限等待。 \\ @CircuitBreaker
- 隔离失败,让系统的其余部分可以正常运转。\JSON Web Token(JWT)Propagation API是一种基于令牌的身份验证/授权系统,其中包含一系列互操作标准。
\\Config 1.1 API按照设计可在运行时注入配置值,此次更新修复了一些Bug,并增加了一些原本不具备的重要功能,借此改善了与相关规范的配合效果。
\\按照官网介绍,这个版本还提供了其他一些收益:
\\按照MicroProfile路线图的未来规划,后续的MicroProfile 1.3版计划在2017年12月15日发布,会新增下列API:
\\MicroProfile 2.0计划在2018年3月31日发布,将包含对下列Java EE 8 API的升级:
\\MicroProfile自从2016年9月发布时,就承诺将在Java中采用微服务。有关此次发布最新版的详细信息可参阅MicroProfile 1.2规范。
\\IBM CDI和MicroProfile开发主管Emily Jiang,以及Payara公司Java中间件顾问Michael Croft向InfoQ介绍了本次发布的新版本。
\\InfoQ:你们对于新增的EE4J项目有何看法?
\\\\\Emily Jiang:新增的EE4J项目是开源领域一个了不起的创新。所有社区,包括由于许可条款限制而无法使用Java EE TCK的社区,都能从中获益。该项目已经尽可能保持敏捷、灵活、开放、兼容,Java开发者当然是最大的受益者。希望该项目的新版发布节奏可以进一步加快,借此彻底终结Java EE四年甚至五年为单位的发布周期。TCK的开放可以让所有应用程序服务器获益,尤其是原本因为许可费用缘故,未能进行TCK认证的程序。
\\希望能有越来越多的Java容器和框架社区以开放和公开为背景展开合作,与Java开发者进行更坦率的交流。每个开发者都能对项目做贡献,提出或讨论问题。我很看好新的EE4J项目,并且希望继续为项目的发展贡献自己的力量。
\
\\\Michael Croft:我本人对此很激动,我觉得过去多年来,业界发生的很多事情已经证明了开源软件的力量,尤其是类似Oracle和IBM这样的重量级选手也开始投身社区工作。对于JSF,一些专家组成员已经提出要以社区的力量推动相关规范继续发展。对于EE4J,入门的门槛已经大幅降低,我们已经通过邮件列表和GitHub获得了大量的反馈。
\
InfoQ:在EE4J的贡献中,你们觉得MicroProfile扮演了什么角色?
\\\\\Jiang:MicroProfile已经诞生多年。在一年时间里,已经成功发布了MicroProfile 1.0(CDI 1.2、JAX-RS 2.0、JSON-P 1.0)、MicroProfile 1.1(Config 1.0)和MicroProfile 1.2(Config 1.1、Fault Tolerance 1.0、Health 1.0、Metrics 1.0和JWT 1.0)。已经发布的规范为Java EE提供了众望所归的微服务开发功能。例如Config JSR是JCP在十多年前提出的,但提出之后除了两次失败的尝试,从来没被接受过。
\\与之相对的,MicroProfile Config只用了几个月就公开发布了,并且获得了大量反馈。MicroProfile社区很有创新精神,完全是由开发者推动的,一切都维持开放和透明。这里取得的所有成果都为敏捷、开放、灵活和兼容设立了绝佳的典范。在类似目标以及Eclipse的推动下,未来的EE4J也将能轻松接纳MicroProfile技术。
\
\\\Croft:围绕MicroProfile的诸多努力都是为了以更快的节奏实现创新。从最开始,MicroProfile的目标就在于独立发展,同时依然维持与Java EE的密切关系,毕竟MicroProfile是基于Java EE API发展起来的。
\\MicroProfile的角色早已通过MicroProfile开发出的第一个API彰显出来了:配置(Config),在最初公布了要迁移至Eclipse之后,该API就以JSR的形式顺利提交。很明显,这两个项目可以通过很多方式相互关联,不过目前依然保持了这样的形式。
\\我觉得,MicroProfile已经具备继续发展所需的一切。它已经在很大程度上实现了与Java EE/EE4J的兼容,而MicroProfile发展出的任何规范都会直接提交至EE4J。
\
InfoQ:随着MicroProfile 1.3的发布,Open Tracing API 1.0和Open API 1.0能为大家带来些什么?
\\\\\Jiang:MicroProfile Open Tracing定义了一种追踪微服务请求跨越服务边界流动的模型。请求在多个服务之间流动,这是微服务架构中一种常见的情况。这个规范定义了一种基于opentracing.io的API,并定义了相关的行为,可以让服务轻松参与到启用了分布式追踪的环境中。该规范还定义了一种更简单的方法,可以让微服务通过注释使用分布式追踪能力。此外该规范还提供了一个很棒的功能,可以让JAX-RS应用程序无需更改代码,即可自动参与到分布式追踪工作中。
\\MicroProfile Open API主要是为了提供一个统一的Java API,该API由OpenAPI v3规范定义,所有 应用程序开发者都可以使用它暴露自己的API文档。由于OpenAPI v3规范本身是语言中立的,因此基于Java的Open API也可直接被应用程序服务器所采用。这个规范基于SmartBear的Swagger库,而SmartBear也是MicroProfile成员。MicroProfile Open API规范还将进一步完善API,以更好地满足微服务开发需求。
\\除了MicroProfile Open Tracing API和Open API,MicroProfile最近还创建了另一个规范:MicroProfile REST Client,计划将与MicroProfile 1.3一同发布。该规范提供了一种类型安全的方法,可通过HTTP调用RESTful服务。这个规范主要侧重于REST客户端,目的在于简化客户端的创建,而客户端与服务器之间的通信可由服务器应用程序处理。
\
\\\Croft:在最近一次的“两周电话讨论”中,还真的讨论过这一点。MicroProfile 1.3目前计划在12月发布,并通过状态报告帮助每个项目了解截止期限信息。目前与OpenAPI的情况类似,OpenTracing和Typesafe REST Client API很可能会包含在即将发布的新版中。OpenAPI规范相当庞大,因此主要的挑战还在于TCK。该规范本身可以兼容由Swagger发起的第3版OpenAPI规范,很多开发者其实已经熟悉它了。
\\Typesafe REST Client主要是为了向开发者提供一种类型安全的方法,通过定义到程序的接口来使用远程REST服务。具体目的与OpenAPI规范有些重合,但围绕这一领域的所有重要讨论都已被延后到1.0版发布之后。此外还有一个领域可能有待讨论:需要通过某种方式从OpenAPI定义生成REST客户端接口,这样才能更自然地融入现有工具中。
\\最后,OpenTracing让MicroProfile获得了OpenTracing标准,并可兼容诸如Zipkin或Jaeger等追踪方面的实现。
\
InfoQ:Java SE新的发布周期是否会影响MicroProfile和/或EE4J的开发?
\\\\\Jiang:Java SE提速后的新发布周期会对MicroProfile和EE4J的开发产生非常积极的影响,这意味着我们新制定或更新的规范也可以快速用上新增的最新版Java SE功能。目前MicroProfile的编程模型要求至少具备Java 8,一些很棒的功能,例如FunctionalInterface、默认的接口实现等已经广泛应用在MicroProfile规范中。
\
\\\Croft:我们的客户围绕Java SE有很多问题,但这些问题主要与Payara Server或Payara Micro有关。我觉得,Java SE可以通过相同的方式做出改变,并且对EE4J和MicroProfile的实现产生远大于规范本身的影响。
\\然而MicroProfile最初的目标在于创新,着眼于未来,因此我希望在2018年能围绕Java SE的变化展开一些讨论,毕竟Java 8将于明年9月寿终正寝,而Java 11(目前的叫法)将成为新的LTS版本。
\
InfoQ:你们觉得Java 9什么时候可以兼容MicroProfile?
\\\\\Jiang:我们还没有在MicroProfile的GoogleGroup上讨论过这个问题。对于Java 9,一个重要问题在于,由于发布周期加快为六个月,可能无法获得像Java 8那么长的支持时间。因此以后的情况还无法确定。这也会对MicroProfile产生一定的影响。MicroProfile什么时候能够采纳Java 9,这取决于诸如Open Liberty、Wildfly Swarm、TomEE以及Payara等应用程序服务器什么时候能支持Java 9。
\
\\\Croft:与Java 9+的兼容主要是实现方面的问题,毕竟已经有很多现有的模块系统,例如Payara Server中的OSGi以及其他一些系统。我怀疑对于Java 9可能不会有官方的支持了,因为Java 9并不是LTS版本,因此对后续Java版本的官方支持可能会从9月开始选择Java 11。
\
InfoQ:您目前在IBM主要负责什么?也就是说,您的日常工作具体在做些什么?
\\\\\Jiang:作为IBM的MicroProfile开发主管兼CDI架构师,我会积极参与有关MicroProfile的讨论并从事与各种规范有关的工作。同时我还负责管理该规范在Open Liberty中的具体实现方式。我还管理着MicroProfile Config和Fault Tolerance规范的开发,并参与了其他规范,例如Metrics、Health、REST Client、Open Tracing等的相关工作。作为MicroProfile社区有影响力的成员,我还尽可能完善整个社区的工作方式,以确保MicroProfile保持敏捷和精益。我十分看好MicroProfile编程模型,并在很多会议(Devoxx US、Devoxx UK、JAX London、Voxxed Belgrade、EclipseCon Europe)上推广MicroProfile,并就如何在后续版本中进行改进收集反馈。此外我还是Configuration JSR共同规范的负责人,主要负责MicroProfile Config现有成果的标准化工作,并确保Config JSR和MicroProfile Config的同步,借此Config JSR的新功能也可以尽快实现到MicroProfile Config中。
\
InfoQ:那么Croft您目前在Payara主要承担什么职责,日常工作都在做些什么?
\\\\\Croft:我的职责非常广泛!目前我担任Payara支持团队的主管,因此首要职责主要围绕我们的客户,其次是整个社区。我有幸能与我自己团队,以及我们公司开发团队中一些非常天才的人以及专职人员共事。我们会共同为产品提供商业支持,写文档和博客文章,在会议上发言,为MicroProfile社区做贡献,提供社区支持,方方面面都包括在内!虽然工作很繁忙,但能获得大量用户的反馈也让我们觉得获益匪浅。
\
参考资料
\\