介绍

IBM 收购 Red Hat 意味着联合公司现在拥有许多 Java 应用程序运行时，包括：

• 传统的 IBM WebSphere Application Server
• JBoss EAP / WildFly
• WebSphere Liberty / Open Liberty
• 夸库斯

这不可避免地导致客户提出两个问题：

• 我应该选择哪个运行时？
• “运行时 A 和 B”何时会合理化？

第二个问题的答案很简单——没有删除或合并任何运行时的计划。每个都有重要而忠诚的客户群，他们需要他们使用的运行时的连续性。通过在开源项目（例如 SmallRye 和 Apache CXF）中的协作，已经实现了开发效率。

本文将解决第一个问题。答案并不像“使用运行时 X”或什至：“对于微服务，使用运行时 X”那么简单。为了选择一个或多个运行时，了解三件事很重要：

• 您现有的应用程序资产、业务需求和这些应用程序的策略
• 每个运行时的应用程序架构风格优势
• 您希望采用的应用程序架构风格

本文的后续部分详细介绍了后两点。本文还讨论了如何基于所有三者选择运行时。

运行时的演变

要了解每个运行时的特征以及它们可能如何应用，值得回顾一下它们的历史，因为这极大地影响了它们最适合的应用程序类型。

传统企业应用

万维网的商业化和 Java 应用服务器技术的标准化促使许多供应商创建应用服务器产品。WebSphere Application Server 以及后来的 Wildfly 和 JBoss EAP 于 1990 年代后期首次发布。按照今天的标准，它们运行的硬件具有适度的计算能力——网络速度明显较慢，尚未围绕以太网标准化，内存和磁盘容量有限（第一个 1TB 硬盘驱动器发布需要 10 年时间）。Waterfall 和相关的工程实践也主导了软件交付。这自然导致了单体应用程序的开发和交付。当然，在那个年代，因为没有其他类型，所以它们只是被称为“应用程序”。值得一提的是，单体应用程序还不错——不可维护的单体应用程序很糟糕，并且可以使用任何架构风格构建不可维护的系统。在 2000 年代初期，虚拟机作为一种简化服务器部署的方法出现，但集群是以特定于您部署的每种运行时类型（例如，WebSphere ND Cells）的方式完成的。

约束、实践和较长的交付周期导致企业 Java 运行时被优化以实现长期、稳定、高性能的正常运行时间；一旦您部署了服务器和应用程序，您就希望它无论如何都能继续运行。

业务敏捷性需要运行时敏捷性

在随后的几年中，对更快、更具可扩展性的交付不断增长的需求推动了基础设施和方法的重大进步。处理器、网络和存储的速度和容量都在增长，软件交付采用了敏捷实践。对更快上市时间的推动导致对更轻量级运行时的需求不断增加，这有助于更快地交付应用程序的目标。为响应这些需求，2012 年，IBM 创建了WebSphere Liberty。

Liberty 重新审视了如何满足快速应用程序开发和交付的需求：轻量级、易于配置、易于部署以及支持新兴最佳实践和工具的需求。当时开发的应用程序仍然主要是单体应用程序，但在 Liberty 的帮助下，可以更轻松、更快速地交付。Liberty 开始支持简单的 Web 应用程序，但根据客户需求很快就支持完整的 Java EE 功能。Liberty 能够安装和配置“刚好足够的运行时”——只有应用程序需要的那些能力——意味着它不会受到通常与企业应用服务器相关的运行时膨胀的影响。早于容器和容器编排平台，

在接下来的五年中，开源成为软件采用的一个越来越重要的方面。为支持这种转变，2017 年，Liberty 通过在 Eclipse 公共许可证下将WebSphere Liberty开源为Open Liberty，转向了开源优先的开发模型。

用于快速、灵活、可扩展部署的架构

多年来，许多单体应用程序不断增长，并且经常失去对其模块化的任何考虑，使它们难以维护和扩展。寻求进一步缩短交付时间并提高可扩展性以满足更大工作负载需求的企业发现自己受到单体应用固有的“全部部署，全部扩展”性质的限制。为了实现更大的灵活性和可扩展性，这些应用程序需要被重新设想为许多更小的单元，这些单元可以独立开发、部署和扩展，即微服务和功能（通常部署到功能即服务 [FaaS] 环境中的云） .

从单一应用程序向多个微服务或功能的转变推动了对既能简化操作又能降低基础设施成本的技术的需求。以红帽 OpenShift® 为代表的容器和基于 Kubernetes 的容器编排平台已迅速成为微服务的代名词。容器支持轻量级隔离部署，Kubernetes 支持一致的容器部署、管理和集群，无需以运行时为中心的集群方法，例如 ND Cells 和 Liberty Collectives。

微服务的普及导致对新 API 标准的需求，因此许多供应商和 Java 用户组聚集在一起，创建了Eclipse MicroProfile规范。MicroProfile 迅速发展为提供一整套开放的微服务 API，同时提供支持的多个运行时，包括 Liberty、WildFly、JBoss EAP、Payara、TomEE 和 Quarkus。

部署为微服务或功能的细粒度组件的驱动导致对更轻、更快的运行时的需求增加。2019 年，红帽发布了 Quarkus，这是一个专门为这些架构风格量身定制的运行时。这样做时，它将 Quarkus 牢固地定位于新功能和微服务，仅支持本地编译涵盖的 Java API 子集。

Liberty 和 Quarkus 都为微服务提供了基于 JVM 的出色运行时配置文件，可在大约一秒钟内响应第一个请求。此外，Quarkus 提供编译本机功能，提供非常适合函数的执行配置文件，其中单个请求的优化很重要。

建筑风格谱

过去几年，人们非常关注微服务架构的交付。与任何新概念一样，该行业会经历一个发现过程，并最终学会如何最好地应用它。在达到这种开明状态之前，有一种过度应用技术的趋势，导致结果不佳。Gartner 将这个学习过程称为“ Gartner 炒作周期”，目前将微服务定位在“幻灭的低谷”。这并不意味着微服务不好；这只是意味着我们正处于这样一个阶段，我们才刚刚开始真正意识到微服务在哪些方面是合适的，哪些方面不合适。

快速搜索互联网会发现越来越多的文章讨论了单体应用、微服务和功能。还有一些例子讨论了单体应用和微服务之间的风格，使用了诸如“宏服务”或“宏应用”之类的术语。在某些情况下，这是对过度分解为过于细粒度的微服务的反应，导致系统过于复杂，其复杂性超过了收益。在其他情况下，这是在每种架构风格的功能性和非功能性特征之间找到正确平衡的直接尝试。随着时间的推移，公司改变架构风格的引人注目的例子包括Uber 团队现在部署更粗粒度的宏服务和微服务，以及Segment，他从单体应用切换到微服务，然后又回到单体应用。

很明显，我们看到人们越来越多地了解不同架构风格的优缺点，我们预计这种情况在未来几年会继续增加。与其假设所有应用程序都是微服务，更好地了解应用程序需求、基础设施和团队能力将有助于选择合适的架构风格。随着需求的发展，部署多种架构风格以及在架构风格之间不断发展的开放性将会增加。

建筑风格的特点

在选择可能适合的架构风格时，了解它们的特征很重要。下面显示了一些关键特征以及它们在不同架构风格之间的差异。重要的是要了解，某些特性不是通过架构风格的选择自动实现的；它们是潜在的利益，需要技术或组织投资才能实现。例如，如果您不投资自动化技术，您将难以更频繁地交付微服务更新。

从最底层的特征开始，让我们更详细地了解它们：

• 定价： CapEx（资本支出，一次性的购置前期成本）和 OpEx（运营支出，有权/涵盖使用的常规费用）各有利弊。功能即服务本质上是运营支出，并且是任何模型中最细粒度的衡量标准。单体通常是资本支出，但有一些方法可以将成本平滑到更多的运营支出模型（例如，承诺期限许可）。

• 交付频率/复杂性和操作复杂性： 这些都与这样一个事实有关：随着我们从粗粒度架构风格转向细粒度架构风格，我们正在增加我们创建、部署、管理、调试和服务的工件数量。有与此相关的成本，但也有好处。

• 模块化： 单体的一大缺点是难以使它们模块化并随着时间的推移保持模块化。当我们从粗粒度转向细粒度时，我们将应用程序进一步分解成越来越小的部分，但也引入了流程和网络边界作为强制模块化的一种方式。这增加了创建更松散耦合、更灵活的解决方案的机会。不过，请注意一点，因为有些人发现创建分布式单体非常容易——这是两全其美的（没有什么可以替代好的架构）。

• 网络需求和故障隔离： 这两者是相辅相成的。随着越来越多的组件的分布，对网络的使用和依赖也随之增加。网络性能成为影响整体解决方案性能的关键控制因素。网络可靠性也会影响整体解决方案的可用性。增加隔离有助于避免导致整个解决方案崩溃的级联故障，但需要采用防御性容错技术，例如隔板、重试和回退，以利用隔离。

• 运行时要求： 不同的架构模式不仅有利于不同的运行时特性，而且有利于使用不同的运行时方法。对于粗粒度的应用程序，交付周期通常更长，因此有利于长时间的运行时稳定性。优先级是让运行时在部署应用程序的较长时间内表现良好。服务器也是您直接管理和优化的东西，然后部署一个或多个应用程序。对于更细粒度的应用程序，由于交付周期更短、请求数量更少、实例数量更多，因此重点是运行时小且启动快。还有一个从以服务器为中心的部署转变为以应用程序为中心的部署，其中服务器与应用程序（例如，

  我们将在下一节探讨的最后一点是 API 需求与架构模式之间的相关性。对于粗粒度的应用程序，您通常会在单个应用程序中使用许多不同的 API，而对于细粒度的应用程序，每个函数或微服务都有更适度的 API 需求。

选择运行时

我们已经看到每个运行时的历史和演变如何强烈影响它们最适合的架构风格。我们已经看到企业越来越重视不同架构风格的好处，以及有多少可以灵活使用。我们还看到了与每种架构风格相关的许多特征，以及如何使用这些特征来帮助决定使用哪种风格，并且很可能随着时间的推移混合或改变风格。但这在运行时选择方面意味着什么？

基于每个运行时的历史和演变，下图显示了每个运行时适用的架构风格，根据应用程序的“API 需求”绘制（应用程序的 API 需求往往与应用程序的“大小”相关）应用程序）。

该图表明，无论选择哪种架构风格，IBM 和 Red Hat 都涵盖了它。仔细检查后，我们发现单体应用有三个选项（传统的 WebSphere Application Server、JBoss EAP 和 Liberty），微服务有两个选项（Liberty 和 Quarkus）。然而，与其讨论哪种架构最适合特定的架构风格，重要的是要考虑每个运行时的遗产、每个应用程序的策略以及您可能使用的架构风格。以下示例场景应该会有所帮助：

• 如果您希望以最少的工程投资保持工作和稳定的现有单体，那么它们应该保留在传统的 WebSphere Application Server 和 EAP 上。

• 如果您正在寻找部署新功能和新微服务，那么 Quarkus 的目标 API 和本机编译是一个不错的选择。Quarkus 的本机图像功能将为您提供非常适合函数的运行时特性。

• 如果您希望对现有企业应用程序进行现代化改造，那么 Liberty 的轻量级全 Java 运行时是一个不错的选择。这些应用程序通常是用 Java EE 编写的，因此从长远来看，选择具有完整 Java EE 功能的现代运行时将为您节省成本。如果您正在从传统的 WebSphere Application Server 进行现代化，那么 WebSphere Liberty 还提供了旨在简化此现代化路径的 API。

• 如果您希望创建新的现代单体、新的微服务或介于两者之间的任何东西，那么 Liberty 的功能和灵活性使其成为一个不错的选择。这是因为 Liberty 被设计为用于单体应用程序的现代全 Java 运行时，并针对轻量级、高性能的微服务进行了优化，让您可以灵活地在这些架构风格之间进行选择和切换。

结论

本文展示了行业对不同应用程序架构风格的评价如何演变为更细致入微的观点，其中架构风格是根据应用程序的业务需求、技术和组织能力来选择的。本文还讨论了 Java 运行时的历史如何强烈影响其对不同架构风格的适用性。最后，通过使用少量场景，本文提供了一种方法来选择正确的运行时或运行时，以适合您首选的架构风格。我们希望您发现这很有用。