我们生活在信息技术的新时代。所有像我这样在 2000 年代初开始工作的人，都经历了语言、框架和体系结构的不断但渐进的演变。去年标志着我们处理软件版本的方式发生了巨大变化。

推动全球市场的激烈竞争已经改变了公司的文化方式，这些公司现在有了一个里程碑式的目标——缩短上市时间。 尽快发​​布新业务服务的需求是公司的主要目标，无论其业务领域如何。

从信息技术的角度来看，这种需求已转化为对开发平台及其更新和演变过程的全面审查。

从企业的角度来看，这种被定义为数字化颠覆的变化导致需要在角色和技能的组织方面审查公司结构，以及不断更新以跟上市场需求的政策。开发人员的社区方面导致了一段时间以来未见的想法的概念化。

理解围绕这些概念产生的所有想法的最佳方式是通过开源模型。

在本章中，我们将介绍以下主题：

• Open source
• The Java programming language
• OpenJDK 9 and 10
• Java EE – MicroProfile.io – Jakarta EE

首先，我们从开源的定义开始——它是一种思考软件开发的方式，鼓励分享想法和代码。产品的所有部分——文档、源代码等——都应该公开。使用此模型，您可以构建一个能够从社区在标准、安全性和技术发展方面提供的持续改进提升中受益的产品。

有时，人们将开源与免费的概念混为一谈，这意味着我们可以免费使用该技术。 仅根据成本（便宜还是昂贵）使用技术会使您的项目面临非常高的风险，包括未能实现既定目标。 这种看待开源的方式极其简化和危险。

开源更多。它是一种模式，就像一种哲学，鼓励开放式合作和思想分享。如果更多的人合作找出弱点以改进它们并找到正确的解决方案，一个想法就会变得更强大和更有用。其目的是推广这些想法，以创建一个基于构建未来架构的可靠规则的生态系统，并使所有想法免费提供。

通过这种方式，创建了一个社区，该社区不仅可以发展已经出现的想法，还可以继续进行改进、演变和传播的工作。因此，我们可以说，与所有其他领域一样，即使在信息技术领域，团结就是力量。

一旦确定了这些技术所基于的标准，就有可能继续实现它们。在这个阶段，开源也是最好的方法。

如果在开源模型下实施，所有软件堆栈都可以以更好的方式增长。想象一下，有一个遍布世界各地的社区，可以在许多不同的场景中测试、评估、更新和修复您的代码；一个由不同文化和不同技能的人组成的团队，通过一个共同的目标联系在一起——创建和巩固一个开发框架。哪家公司有这么特别的团队？

如果我们考虑一下信息技术中最常用的工具和框架，我们可以立即了解开源社区在我们的工作生活中的参与程度：

• Software foundations:
  
  • Eclipse Foundation: http://www.eclipse.org/
  • Linux Foundation: https://www.linuxfoundation.org/
  • Python Software Foundation: https://www.python.org/psf/
  • OpenJDK: http://openjdk.java.net/
• Operating systems:
  • Fedora: https://getfedora.org/
  • Linux kernel: https://www.kernel.org/
  • CentOS: https://www.centos.org/
• Containers:
  • Docker: https://www.docker.com/
  • Kubernetes: https://kubernetes.io/
• Middleware:
  • Apache Software Foundation: http://apache.org/
  • WildFly: http://www.wildfly.org/
  • Jakarta EE: https://jakarta.ee/
• Operations:
  • Ansible: https://www.ansible.com/community
  • KVM: http://www.linux-kvm.org/page/Main_Page
  • OpenShift: https://www.openshift.com/
  • OpenStack: https://www.openstack.org/
• Storage:
  • Ceph: https://ceph.com/
  • Gluster: https://www.gluster.org/

这只是涉及少数几个关键领域的大量开源社区的一小部分。您是否仍然认为开源仅意味着免费？

开源模式的关键之一是参与。社区中人们之间的协作至关重要，它解决了公司经常遇到的一个大问题——他们应该从头开始构建解决方案，还是购买满足他们要求的解决方案？

很难拥有构建整个开发框架所需的所有技能。从供应商处购买产品可能会解决问题并减少实施工作，但会让您无法知道解决方案的极限和改进的余地。

使用基于开源的解决方案让您有机会准确了解您正在使用什么，让您知道您的解决方案是否能够适应信息技术的未来发展。

您应该根据自己的需要选择开源社区和项目。

现在您已准备好使用开源产品、框架、语言等构建您的环境，并执行以下操作：

• Share your knowledge through blogs, social networks, and all free channels that give you the opportunity to disseminate knowledge and encourage the exchange of ideas.
• Create your source code and donate it to the community, using one of the open source licenses and standards (https://opensource.org/licenses).
• Fork, star, watch, and create issues on open source repositories, such as GitHub, in order to promote good principles and ideas.
• Take part in the source life cycle of the open source project, and submit code that is able to solve issues that you may encounter during your experience.
• Help with documentation, in order to allow an increasingly clear and simple use of open source code.
• Help to test features; this could help the community to increase the strength of code, and gives an easy-to-understand example of usage of code.

换句话说，您可以成为社区的一员，并根据您的技能和可以投入的时间做出贡献。

从应用程序开发的角度来看，开源多年来提供了巨大的贡献。 Java 是一种已经发展起来的最流行的编程语言（感谢开源社区的帮助——这将成为我们微服务之旅的主角）。

Java 是一种功能齐全的通用编程语言，由 Sun Microsystems 的 James Gosling 和 Patrick Naughton 领导的团队于 1991 年发起。让我们看看Java在其开发人员手中的演变。

Sun Microsystems 于 1996 年发布了第一个 Java 公共实现 1.0 版。一次编写，随处运行的概念，承诺软件的高度可移植性和易于开发人员学习和使用（特别是自动内存管理和面向对象范式）都促进了 Java 在信息技术生态系统中的快速传播。

语言的演变和传播是快速而持续的。在 JDK 1.1（1997 年 2 月）和 Java 标准版（JSE）1.2（1998 年 12 月）两个版本之后，Sun Microsystems 发布了 Java Platform, Enterprise Edition （Java EE （以前称为 Java 2 Platform, Enterprise Edition (J2EE)）。

这旨在作为一组规范，基于 Java Platform, Standard Edition (Java SE)，专用于从桌面本地环境快速迁移到本地环境的企业应用程序。网络浏览器环境。

2006年底，Sun公司决定将Java虚拟机（JVM）标准版和企业版的大部分核心代码作为开源软件捐赠通用公共许可证 (GPL) 的条款。 2007 年初，Sun 完成了这一过程，使其所有 JVM 代码在自由软件和开源分发条款下可用。这个过程的最终结果是创建了 OpenJDK，它成为了 Java SE 的开源实现。

从 1996 年第一次公开发布到 OpenJDK 的诞生，再到 2007 年 JVM 内核和 JSE 平台的开源发布，Sun 在这 10 年中所做的工作，理想地发挥了它在以下方面的作用Java 看起来像是一个布道者。

在这个伟大的时期之后，甲骨文公司在 2009-2010 年收购了 Sun Microsystems。

在这个新时代的开始，甲骨文宣布将继续为客户支持和投资 Java。您可以查看以下站点上的声明：https://web.archive.org/web/20100131091008/http://www.oracle.com/us/technologies/java/index.html

尽管有这个声明； Java之父James Gosling于2010年从甲骨文辞职；以及 2012 年针对谷歌的诉讼，涉及在 Android SDK 中使用 Java；改变了社区对 Java 语言未来的看法。

Oracle 试图为 Java 注入新的动力，并在近五年后发布了新的 Java SE 版本（JDK 7 - 2011 年 7 月）和新的 Java 企业版（Java EE 7 - 2013 年 6 月）。此外，OpenJDK 从版本 7 开始成为 Java SE 的参考实现。

业务需求的快速演变和 Java 源代码生命周期的放缓促使 Oracle 改变了 Java 平台的战略，明确押注于开源模型。

OpenJDK 二进制文件是 JSE 平台的参考实现。 OpenJDK 是最新新功能的孵化器，并定义了基于时间的版本，将在每年的 3 月和 9 月交付。版本号遵循年月模式 (YY.M)。与以前的发布方法不同，此发布方法不会延迟等待主要功能完成和稳定——例如 JDK 8 由于 Jigsaw 项目问题而延迟，然后将其重新定位到 JDK 9。

使用新模型，新功能在完成之前不会全部合并到发布源控制存储库中。如果它们还没有准备好包含在新版本中，它们将被重新定位到下一个版本或更高版本。此模型的目的是避免某个功能出现问题，如果该功能尚未准备好，可能会延迟整个发布，而该发布可能包含对开发人员有用的其他功能。

那些不一定想要或不需要快速升级的企业和组织可以根据市场反应自由选择供应商来支持特定的 Java 版本。 Java EE 也做出了同样的选择。

这些年来，这个平台变得非常大。保持向后兼容性的需要以及它所依赖的新 Java SE 版本的延迟，使得该平台非常难以管理，延迟了它的发展，并使其对持续发展的云和微服务等环境没有吸引力。

2017 年底，甲骨文宣布将 Java EE 捐赠给 Eclipse 基金会。最初，该项目被命名为 Eclipse Enterprise for Java (EE4J)。经社区调查，Java EE 的名称已更改为Jakarta Enterprise Edition（Jakarta EE)——新平台的入口点是 Java EE 8。

在 Eclipse 基金会社区的保护下，在主要供应商的承诺下，企业版平台可以开始新的生活，以加速采用云原生世界的业务应用程序实施。

所有源代码向 Jakarta EE 的迁移正在迅速进行，但与此同时，云环境和微服务的发展需要在标准和实施模型方面立即得到答案。

出于这个原因，Eclipse MicroProfile 是 created，因为 它旨在针对微服务架构优化 Enterprise Java。 MicroProfile 旨在促进可能在未来成为标准的创新，但目前需要比有意测量的标准流程速度更快的变化速度。

期望现有的 Eclipse MicroProfile 社区和其他开源社区应该继续引领潮流。 Jakarta EE 会将来自这些项目和社区的 Java 创新整合到新版本中，以便拥有完整和强大的标准。

以下屏幕截图显示了 Java EE 版本的历史记录，包括版本和每个版本之间的持续时间（以月为单位）：

如您所见，发布之间的间隔越来越长，最后一个发布版本，即 Java EE 8，在 52 个月后发布！

在下一节中，我们将分析 OpenJDK 最新版本 9 和 10 以及 Java EE 8 平台的详细信息。这些代表了发现 Eclipse MicroProfile 的基础，这是 Java Enterprise 关于在云环境中实现微服务架构的提议。

Java SE 9 和 10 引入了一些重要的新特性和改进。

对新功能的详细分析超出了本书的范围。我们将研究为在云平台和微服务中使用 Java 带来附加值的主要创新。

让我们从 Java SE 9 开始，革命性的元素需要通过 Jigsaw 项目实现 JDK 的模块化 (http://openjdk.java.net/projects/jigsaw/）。

此新功能的主要目标如下：

• Make Java SE more flexible and scalable
• Improve security and maintainability
• Make it easier to construct, maintain, deploy, and upgrade large applications
• Enable improved performance

社区对 Java SE 平台的两个主要批评是，如前所述，新版本发布缓慢，以及 JDK 在空间占用和类别方面的大小大小（JDK 8 中大约有 4,240 个类）。

在与 物联网 (IoT) 架构相关的云环境和设备中，这些方面是一个重要的限制。

但是，要找到一种解决方案来克服这些限制而不放弃 Java SE 的基石之一——版本之间的向后兼容性——并不容易。

因此，很难通过 Java 反射消除过时的类或删除为内部使用而设计但被密集使用的类，尤其是框架使用的类。最著名的例子是 Sun Microsystems 提出的例子，它与 com.sun.misc.Unsafe 类有关。它指定： sun.* 包不是受支持的公共 Java 接口的一部分。如果您想查看实际版本，可以访问此链接： https://www.oracle.com/technetwork/java/faq-sun-packages-142232.html

通过 Jigsaw 项目，不仅可以将 JDK 的核心代码模块化，而且可以为应用程序的实现提供一个工具，能够将其服务的暴露接口与实际实现显着解耦。

对于 JDK 核心代码，可以对 JDK API 进行电子封装，如 JEP 260 (http://openjdk.java.net/jeps/260)，使用如下方法：

• Encapsulate, by default, all internal APIs that are considered non-critical.
• Encapsulate all internal APIs, that are considered critical, for which exist, in JDK 8, supported replacements.
• Do not encapsulate critical internal APIs, but implement the following steps:
  • Deprecate them in JDK 9
  • Define a plan to remove these APIs in JDK 10
  • Implement a workaround solution via a command-line parameter
  • Remove, from the JDK distribution, a limited number of supported Java Community Process (JCP) standard APIs
  • Remove the extension mechanisms and the endorsed standards override

• Java EE modules, due to the Jigsaw project, are not resolved by default.

通过这种方式，您可以轻松获得一个小型可启动 Java 运行时，其中仅包含您真正需要的类和接口的特性，避免出现无用代码，并且只会在占用空间和空间方面产生负面影响分配。

您可以使用以下命令轻松分析它：

$ java -listmods

如前所述，JDK 和应用程序都可以从模块化开发中受益。解耦应用程序中存在的组件在微服务架构中至关重要，这需要非常敏捷的软件生命周期来缩短上市时间。

使用模块化方法，您可以轻松实现以下目标：

• Loose coupling between components
• Clear contracts and dependencies between components
• Hidden implementation using strong encapsulation

实现中的主要元素是模块。

开发人员可以将他们的代码组织成一个模块化结构，其中在各自的模块定义文件中声明了依赖关系。

模块的属性定义在一个名为 module-info.java 的文件中，该文件包含以下属性：

• The module name
• The module's packages that you want to make available publicly
• The dependencies, direct or transitive, that the module depends on
• The list of the services that the module consumes
• All possible implementation of the service that the module provides

以下是通过module-info.java文件设置模块主要特性的主要关键字：

• module: The module definition file starts with this keyword followed by its name and definition.
• provides ... with ...: The provides keyword is used to indicate that the module provides implementations for a defined service interface. The service interface is expressed using the with keyword.
• requires: This keyword is used to indicate the dependencies of the modules. A module name has to be specified after this keyword and the list of dependencies are set through multiple required directives.
• transitive: This keyword is set after the requires keyword; with this feature, you are declaring that any module that depends on the module defining requires transitive <modulename> gets an implicit dependence on the <modulename>.
• uses: This keyword is used to indicate the service interface that this module is using; a type name, complete with fully qualified class or interface name, has to be specified after this keyword.
• opens: This keyword is used to indicate the packages that are accessible only at runtime; you can also use them for introspection, using Reflection APIs. This is quite important for libraries and frameworks that use reflection APIs in order to be as abstract as possible; the opens directive can also be set at module level—in this case, all packages of the module are accessible at runtime.
• exports: This keyword is used to indicate the packages of the module that are publicly available; a package name has to be specified after this keyword.

但是 Java Jigsaw 模块和 Open Service Gateway Initiative (OSGi) 这两种方法存在一些差异。

OSGi 的采用很大程度上是由于它支持动态组件控制。在这种情况下，插件或组件会动态加载，然后根据需要激活、停用，甚至更新或删除。目前，这种动态模块生命周期不适用于 Java 模块。

此外，与 Java 模块相比，OSGi 支持改进的版本控制。 OSGi 的其他优势与隔离有关。例如，捆绑更改只需要重新编译直接依赖项，而如果只有一个模块发生更改，则需要重新编译 Java 模块的整个层以及所有子层。

缺点是 OSGi 包仍然存在类路径问题，例如缺少依赖项的运行时异常，或同名包的任意类加载。

此外，OSGi 要求每个模块都有一个类加载器，这可能会影响一些只需要一个类加载器的库。 Java 模块不允许拆分包，这被认为是 Java 整体的一大改进，并且没有类似的类加载器要求或限制。 Java 模块相对于 OSGi 的一大优势是编译器支持。

我认为我们可以充分利用微服务架构中应用程序组件的模块化，结合两种技术的优点。总体策略是使用 Java 模块将库（导入或导出）和 JVM 本身模块化，并在顶部使用 OSGi 来处理应用程序模块化和动态生命周期控制。

JDK 10 引入了一些新特性。如前所述，我们将专注于与云环境和微服务架构相关的最重要的特性。

第一个是 Docker 感知，仅支持 Linux。使用此功能，您可以提取有关 CPU 数量（自动）和分配内存（自动）的容器特定信息。

引入了以下新的 JVM 配置参数：

• -XX:UseContainerSupport: The JVM has been updated in order to be aware that it is running in a Docker container. In this way it will extract container specific configuration information and it will not query the operating system. The more important information that it will be extract is the total memory that have been allocated to the container and the amount of CPUs. The value of CPUs available to the Java process is calculated from any specified CPU shares, CPU quotas or CPU sets.
• -XX:ActiveProcessorCount: This value overrides any other logic of CPU detection implemented automatically by the JVM.
• -XX:InitialRAMPercentage/-XX:MaxRAMPercentage/-XX:MinRAMPercentage: This parameters allows users that run the JVM into Docker containers to have more control over the amount of system memory that will be used for the Java Heap allocation.

如 JEP 307 (http://openjdk.java.net/jeps/307)。有了这个特性，full GC 发生在并行线程上，有很大的好处，例如：

• Low latency
• High throughput
• No/fewer stop-of-world (STW) pauses
• Improved G1 worst-case latencies

为了获得更好的性能，它还引入了应用类数据共享（CDS）与JEP 310（http://openjdk.java.net/jeps/310) .当多个 JVM 在同一台物理机上运行时，此功能减少了资源占用，并提高了应用程序的启动时间。

此外，进程和应用程序可以共享来自共享存档（CDS 存档）的公共类元数据（类数据）；在 Java SE 10 之前，CDS 的使用仅限于引导类加载器。

在云等环境中必须尽可能响应的另一个重要元素是线程本地握手功能，在 JEP 312 (http://openjdk.java.net/jeps/312)。这是一种在线程上执行 callback 的新方法，可减少获取堆栈跟踪样本的影响，例如，用于分析操作。它可以廉价地停止单个线程，减少 STW 暂停的停止，并提供更好的 GC 性能。使用 Thread-Local Handshakes 功能，可以停止单个线程，而不仅仅是所有线程或一个都没有 - 这样，您无需设置全局 JVM 安全点，从而极大地提高了性能。

最后但同样重要的是，JDK 10 可以在替代设备上执行堆分配，如 JEP 316 (http://openjdk.java.net/jeps/316)。

这个由 Intel 贡献的强大功能允许 JVM 分配在用户指定的不同内存设备上存储 Java 对象所需的堆，例如 非易失性双列直插内存模块< /strong>（NVDIMM）。

这方面在多 JVM 环境中可能非常重要，您将指示优先级较低的进程使用 NVDIMM 内存，同时指示优先级较高的进程使用 d动态随机存取存储器 (DRAM)。

我只描述了 JDK 9 和 10 中发布的一小部分新特性，它们展示了为改进 Java 语言并使其成为云环境中微服务实现的好选择所做的巨大努力。

2018 年 9 月，JDK 11发​​布，其中包含一些新的强大功能，例如 Epsilon——一个无操作垃圾收集器。

您是否对使用 Java 构建新的微服务架构仍有疑问？

Java EE 平台是创建企业应用程序的主要工具之一，这要归功于一系列标准和规范，这些标准和规范的实现使我们能够管理诸如事务、安全性、可伸缩性、并发性和正在部署的组件的管理等关键方面.

与 Spring 和 Pivotal 技术一起，Java EE 代表了现代基于 Java 的企业应用程序在任何类型的部署平台上的实现模型。

如前所述，平台发展的延迟以及因此能够满足与在云环境中实施微服务相关的新要求的新版本的发布在社区中产生了对其使用的不信任感。

我不想引发某种宗教战争，Java EE、Spring 或其他技术被认为是实现现代应用程序的最佳技术。 Java EE 7 是最新的稳定且受支持的版本，于 2013 年发布，得到了社区非常积极的反馈。

Spring 对 Java EE 的影响是显而易见的，并且通过显着降低复杂性来帮助改进平台，例如，通过以下方式：

• The arrival of Spring and Hibernate has provided new ideas and approaches to development, which has given birth to EJB 3 and JPA 1, which represent the two major innovations introduced in Java EE 5.
• Spring Dependency Injection was the base on which Context and Dependency Injection (CDI) was built.
• Spring Batch has merged into JBatch specification (JSR 352 https://www.jcp.org/en/jsr/detail?id=352).

自创建以来，Spring 在开发人员中广受欢迎，这要归功于易于使用的方法和快速的上市时间，这使我们能够快速采用技术创新，例如微服务和云原生应用程序。

相反，Java EE，特别是在版本 5 之后，上市时间较慢；原因与编写规范所需的时间长度以及实施和认证时间有关。通常，规范发布需要几个月的时间才能得到应用服务器的支持和认证。

最近，这个差距扩大了：

• Spring Boot has increased its ease of use through the convention-over-configuration principle.
• Spring Cloud is becoming the major platform used in cloud-native developments by leveraging open source components from Netflix, which creates modules that implement important cloud concepts such as service registry, service discovery, load balancing, monitoring, and so on.

现在的问题可能是——Java EE 仍然是制作微服务和云-原生应用程序的好选择吗？

在我看来，答案是肯定的。

首先，Java EE，尤其是第 8 版，引入或整合了大量对微服务实现极为有用的规范，例如：

• CDI 2.0
• Java API for JSON Processing (JSONP) 1.1
• Java API for JSON Binding (JSON-B) 1.0
• Java API for RESTful Web Services (JAX-­RS) 2.1
• Java Servlet 4.0

CDI 2.0 定义了 Java EE 容器之外的 CDI 行为，即使在第三方实用程序库等上下文中也允许使用控制反转等模式。

该规范分为三个部分——核心 CDI、Java SE 的 CDI 和 Java EE 的 CDI。这种拆分使 CDI 更加模块化，以帮助其他 Java EE 规范更好地与其集成。

微服务环境中 API 通信的事实标准是 JSON 格式。 Java EE 有两个很棒的规范，JSON-B 和 JSONP，可以帮助开发人员轻松生成和处理 JSON 有效负载。

JSONP 提供强大的支持，包括 JSON Pointer、JSON Patch、JSON Merge Patch 等实用程序，以满足 Internet Engineering Task Force (IETF< /strong>) 标准 (https://www.ietf.org/standards/ )。它还为 JSONObject 和 JSONArray 添加了编辑操作，并引入了帮助类和方法以更好地利用 Java SE 8 Stream 操作。

JSON-B 设置了一个类似于 JAXB 的 API 来轻松地将 Java 对象编组到 JSON 或从 JSON 解组。它创建了类和 JSON 之间的默认映射，以及为 JAX-RS 处理 application/JSON 媒体类型的标准支持。它是 JSONP 规范的自然后续，缩小了 JSON 支持的差距。

JAX-RS 2.1 标准化了微服务开发中最常用的一些特性，如下所示：

• Server-­sent events
• Non-­blocking I/O in providers (filters, interceptors, and so on)
• Reactive programming paradigms to improve JAX-­RS asynchronous clients
• Hypermedia API enhancements

通过这种方式，它促进了与其他 JSR 和框架的集成。

Servlet 4.0 引入了对 HTTP/2 协议的支持以及请求/响应多路复用、服务器推送通知等的使用。它还与最新的 HTTP 1.1 RFC 保持一致。

前面描述的所有规范和特性当然有用，但不足以使 Java EE 适合满足云-原生应用程序和微服务的需求。

现在，主要目标如下：

• Deploy the applications onto the cloud
• Build microservices in an easy manner
• Enable more rapid evolution of applications

社区，通过 Java EE 守护者 (https://javaee-guardians.io/< /a>) 和 Java 用户组 (JUG) 推动了适用于云和微服务环境的 Java EE 现代化。目标是扩展 Java EE 平台，使其能够构建微服务架构，同时仍保持与以前的 Java EE 版本的向后兼容性。此外，社区需要一条迁移路径，将整合的应用程序发展为可利用新的云开发和部署模型的云就绪应用程序。

具体来说，该请求是为了获得如下功能：

• Client-side circuit breakers in order to make remote REST invocations fault-tolerant
• A standard way of health checking Java apps
• A secret vault to shadow sensitive data
• Multitenancy support to accommodate the needs of complex applications
• OAuth and OpenID support technologies have rapidly emerged as a de facto standard in security context implementation
• An externalized configuration store to make it an easy process to promote applications across environments

这些请求的答案基本上有两个，如下：

• The creation of the MicroProfile.io project, in the middle of 2016
• The new life on Java EE with the Jakarta EE community project at the end of April 2018

MicroProfile.io 是企业 Java 微服务的开源社区规范，旨在针对微服务架构优化企业 Java。

新版 Java EE 发布的延迟，以及技术场景的快速变化（越来越面向云平台和微服务架构），推动了个人、组织和供应商在开源中协作的社区(Eclipse) 项目，为企业 Java 社区带来微服务功能。

Java EE 平台历史上的一些主要参与者都参与了这个项目，例如 Payara、Fujitsu、Tomitribe 、IBM、Red Hat、Hammock、SmartBear、Hazelcast 和 span>Oracle 等等。

该项目基于使用新规范扩展 Java EE 的主要特性的想法，这些规范对于满足新技术环境的要求至关重要。

撰写本书时，该项目为1.3版本，由如下所示的规范组成：

如前所述，除了用于通过 RESTful Web 服务以 JSON 格式公开 API 的 CDI、JSONP 和 JAX-RS 相关规范外，还有许多新规范，例如配置、容错、< strong>JSON Web 令牌 (JWTs)、指标、健康检查、JWT 传播、OpenTracing、OpenAPI 和 REST 客户端能够在云环境中实现微服务。

在接下来的章节中，我们将详细分析这些规范，并附上代码示例，让我们更好地理解它们的目的。现在，让我们根据 GitHub 存储库中给出的描述快速介绍每个新规范的目标：

• Config: A common feature, not strictly related to cloud or microservice architecture, is the ability of the applications to be configured based on the running environment. Usually they use properties files in different formats, but the request is to have the opportunity to update the configuration properties without the need to rebuild and repackage the application. Also, the changed values should be retrieved by the client without the need to redeploy and restart the application. This requirement is extremely important for microservices running in a cloud environment. The MicroProfile Config specification defines the way to implement this concept.
• REST client: This specification defines how to invoke RESTful services over the HTTP protocol. The REST client implementation outlines a continuity with Java EE/Jakarta EE, suggesting the use of JAX-RS 2.0 specifications in order to give the ability to reuse code written in tradition Java EE applications.

• Fault tolerance: One of the most important features required in cloud and microservice environments is resiliency to failure. This specification defines a way to provide different strategies to drive the execution and the result of computation implemented by the code; for example, providing fall backs and an alternative result when code execution fails due to unexpected exceptions. Retry strategies, bulkheads, and circuit breakers are enterprise integration patterns that you should implement to adhere to this specification.
• Metrics: In a distributed environment such as a Platform as a Service (PaaS), it is essential to retrieve metrics related to the execution environment. Usually, companies use agents that shadow the complexity to retrieve this information. In the past, the Java Management Extension (JMX) was implemented for this purpose. This specification extends JMX and defines another two main aspects, as follows:
  
  • A standard way for MicroProfile servers to expose monitoring data to management agents
  • A standard Java API that applications should use to expose their telemetry data to operations teams
• OpenAPI: The main goal of this specification is to define a standard Java API that implements the OpenAPI version 3 specification defined here: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md. The applications should adhere to this specification to expose their API documentation.
• JWT propagation: The most used technology in microservice architecture is the RESTful web service as compared to the HTTP protocol, and so the security of the APIs exposed must be guaranteed. The RESTful architecture services should be stateless—this means that any security state associated with a client is sent to the requested service every time a new request is performed. The security context is always recreated and the systems must perform both authentication and authorization validation on every request. The principal security protocols are based on security tokens—OAuth2, WS-Federation, OpenID Connect, WS-Trust, and Security Assertion Markup Language (SAML) are the main ones. The target technologies of JWT propagation specification are based on standards defined by OAuth2, JWT, and OpenID Connect.
• OpenTracing: The microservice usually runs in distributed system environments, so it's extremely important to trace requests in order to rebuild the execution flow of the code. This specification defines APIs that describe how incoming and outgoing requests should be traced by an OpenTracing-compliant Tracer Object. They also set the way to access a configured Tracer Object.

• Health check: The monitoring of the production infrastructure is a key point of the operation teams—it's important to always know the state of a node in order to react quickly if there are issues. These APIs describe the rules for determining the state of a node. In a PaaS health check specifications could be used to determine whether a node needs to be discarded and replaced by another instance using automatic mechanisms, reducing the out-of-service time.

这些规范的主要目标之一是与知名云平台（例如 Kubernetes）的兼容性。

预计 MicroProfile 2.0 会将所有 API 与 Java EE 8 对齐，以获得一组特性，如下所示：

目前，有一些产品已经通过了上述 JSR 的技术兼容性套件（TCK）测试，或者正在进行中 状态。

主要产品如下：

• Open Liberty (https://openliberty.io/)
• WebSphere Liberty (https://developer.ibm.com/wasdev/websphere-liberty/)
• Thorntail (https://thorntail.io/)
• Payara (https://www.payara.fish/upstream_builds)

您可以在 Eclipse MicroProfile Wiki (https ://wiki.eclipse.org/MicroProfile/Implementation）。

所以，现在我们有了一个很棒的社区，即 MicroProfile.io 社区，它正在构建一个基于类固醇的 Java EE。但是，Java EE 将如何发展，MicroProfile 提供的新功能将如何包含在其中？

Java EE 的演变是 Jakarta EE。

去年 9 月，Oracle 在 IBM 和 Red Hat 的支持下宣布，Java EE 将转移到 Eclipse 基金会。从那时起，其他一些重要的公司也以战略或参与级别的承诺加入了该计划。

以下是参与 Jakarta EE 项目的成员：

• Strategic members:
  • Fujitsu
  • IBM
  • Oracle
  • Payara
  • Red Hat
  • Tomitribe

• Participating members:
  • CloudBees
  • DocDoku
  • Genuitec
  • IncQuery Labs
  • Lightbend
  • Microsoft
  • Mizuho
  • Pivotal
  • RCP Vision
  • SAP
  • UseOpen
  • Vaadin
  • Webtide

社区要求 Jakarta EE 平台比 Java EE 发展得更快——为了继续成为快速发展的云架构和微服务的参考平台，有必要将来自开源的新功能快速整合到平台的新版本中社区，例如 Eclipse MicroProfile。

Jakarta EE 应该使开发人员能够利用 Java EE 所依赖的数十年开发人员经验构建云原生和任务关键型应用程序。

从 Java EE 到 Jakarta EE 的迁移过程很复杂，但尽管如此，它的进展相对较快。

在处理完规范中与使用名称 Java 和 javax 相关的所有法律问题后，它开始了将项目、规范和参考实现迁移到Eclipse 基金会存储库。

此过程需要大量工作，因为大约有 110 个存储库要转移。您可以在此处找到包含项目状态的完整列表 https://dmitrykornilov.net/2018/05/09/jakarta-ee-projects-summary/。

社区正在进行以下活动：

• Internal license checking in order to make sure licenses are correct.
• Internal third-party analysis in order to identify what dependencies should be replaced with their latest versions to fix major bugs and security issues.
• Renaming the original projects with the following scheme:
  • Eclipse Project for XXX for API projects
  • Eclipse XXX for implementation projects
• Issuing transfers in order to preserve issue numbers and history without losing the previous job.
• Building environments in order to create the infrastructure needed to compile and run, in an agile continuous-integration way, the projects that make up the Jakarta EE platform.
• Aligning the previous projects' repositories in order to set a message that communicates that the project has been transferred to the Eclipse Foundation.

Jakarta EE 的最终第一个版本的基本版本是 Java EE 8。

在流程结束时，我们将拥有一个平台，该平台将使所有参与者（供应商、Java 社区、个人等）能够作为对等方进行交互，而没有一个供应商持有，就像开源模型的精神一样。

那么，凭借 Jakarta EE 和 MicroProfile 所表达的开源模型的强大功能，您认为 Java 还能成为云和微服务领域的主要参与者吗？

在我看来，答案是肯定的，在本书的其余部分，我们将一起了解如何最大限度地发挥 Java 和 PaaS 的潜力，在分布式环境中创建微服务。

在本章中，我们介绍了开源模型的基础知识和 Java 的起源。我们回顾了 Java SE 和 Java EE 平台的演变，以了解 Jakarta EE 和 MicroProfile 实体诞生的原因。

在下一章中，我们将讨论已经彻底改变了企业应用程序的新架构方法——微服务和反应式架构。