微服务 WildFly Swarm 简介

我们将看到的最后一个Java微服务框架是一个相对较新的场景，它利用了 JBoss WildFly 应用服务器中已试过且受信任的 JavaEE 功能。WildFly Swarm 是 WildFly 应用服务器的一个完整的拆下来的组件，可以被组装并形成一个利用 JavaEE API 的微服务应用程序，这些组件被称为片段大小的、可重用的组件。组装这些部分就像在 Java Maven(或Gradle) 构建文件中包含依赖项一样简单，而 WildFlyS 负责处理其余部分。

近15年来，应用服务器和 JavaEE 一直是企业 Java 应用程序的操纵者。WildFly(以前的 JBoss Application Server)是一个支持企业的开放源码应用服务器。许多企业大量投资于 JavaEE 技术(无论是开放源码的还是专有的供应商)，从他们如何雇用软件人才，以及整体培训、工具和管理。JavaEE 始终能够通过提供 servlet/JSP、事务、组件模型、消息传递和一致性等功能来帮助开发人员构建分层应用程序。JavaEE 应用程序的部署被打包为 EAR ，它通常包含许多 WAR、JAR 和相关配置。一旦您有了Java存档文件(EAR/WAR)，您就需要找到一个服务器，验证它是按照您期望的方式配置的，然后安装您的归档文件。您甚至可以利用动态部署和重新部署(虽然在生产中不建议这样做，但它在开发中可能很有用)。这意味着您的档案可以相当精简，并且只包括你需要的商业代码。不幸的是，这导致了 JavaEE 服务器的膨胀，必须考虑到应用程序可能需要的任何功能。它还导致了过度优化，包括哪些依赖项要共享(只需将所有内容放在应用服务器中！)以及哪些依赖项需要隔离，因为它们的变化速度与其他应用程序不同。

应用服务器为在应用服务器的单个实例中管理、部署和配置多个应用程序提供了单一的点。通常，您可以通过在不同节点上创建应用服务器的实例来对它们进行集群以获得高可用性。当太多的应用程序共享一个部署模型、一个进程和一个JVM时，问题就开始出现了。当开发应用服务器中运行的应用程序的多个团队拥有不同类型的应用程序、更改速度、性能或 SLA 需求等时，就会产生阻抗。只要微服务体系结构能够实现快速变化、创新和自治，那么 JavaEE 应用程序服务器和将应用程序集合管理为单一的、集于一身的服务器并不能实现快速更改。此外，从操作的角度来看，精确地管理和监视在单个应用服务器中运行的服务和应用程序变得非常复杂。从理论上讲，单个JVM更容易管理，因为这只是一回事，但是JVM中的应用程序都是独立的部署，应该将其视为独立部署。当我们试图将单个进程中的单个应用程序和服务视为“一件事”时，我们会感到这种痛苦，这就是为什么我们有非常昂贵和复杂的工具来尝试和完成这种反省。团队解决其中一些问题的方法之一是将单个应用程序部署到应用服务器。

尽管 JavaEE 环境中应用程序的部署和管理可能不适合微服务环境，但是 JavaEE 提供给应用程序开发人员的组件模型、API 和库仍然提供了很多价值。我们仍然希望能够使用持久性、事务、安全性、依赖注入等等，但是我们希望在需要的地方按̀顺序使用这些库。那么，我们如何利用我们对 JavaEE (它在微服务环境中所带来的力量)的知识呢？这就是 WildFly Swarm 群适合的地方。

WildFly Swarm 可以使用 pom.xml (或 Gradle 文件)，确定您的微服务实际使用的 JavaEE 依赖关系(例如CDI、消息传递和servlet)，然后构建一个 JAR (就像 SpringBoot 和 Dropwizard 一样)，其中包含运行服务所需的最小 JavaEE API 和实现。这个过程被称为“just enough application server”，它允许您继续使用您熟悉和喜爱的 JavaEE API，并以微服务和传统应用程序风格部署它们。您甚至可以开始使用现有的WAR项目，WildFly Swarm可以自动和正确地审视它们，包括必要的 JavaEE API/片段，而不必显式地指定它们。这是一种将现有应用程序迁移到微服务风格部署的非常强大的方法。

原文：