本文共 6012 字，大约阅读时间需要 20 分钟。
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 - 隔离失败，让系统的其余部分可以正常运转。\（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月发布时，就承诺将。有关此次发布最新版的详细信息可参阅MicroProfile 1.2。
\\IBM CDI和MicroProfile开发主管，以及公司Java中间件顾问向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定义了一种追踪微服务请求跨越服务边界流动的模型。请求在多个服务之间流动，这是微服务架构中一种常见的情况。这个规范定义了一种基于的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社区做贡献，提供社区支持，方方面面都包括在内！虽然工作很繁忙，但能获得大量用户的反馈也让我们觉得获益匪浅。
\
参考资料
\\阅读英文原文：
转载地址：http://qwwzx.baihongyu.com/