微服务 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/片断，而没必要显式地指定它们。这是一种将现有应用程序迁移到微服务风格部署的很是强大的方法。

 

原文：

做者源码：https://github.com/redhat-developer/microservices-by-example-source

有什么讨论的内容，能够加我微信公众号：