使您的应用程序现代化，了解并应用正确的策略

现代化和重构您自己的代码很困难。使用其他开发人员的遗留代码来做这件事更加困难。应用程序现代化是一个复杂的过程，您需要仔细规划。

与任何复杂流程一样，您可以将应用程序现代化分解为多个步骤，其中每一步都可以增加价值。我们可以应用增量更新的敏捷实践来采取增量步骤，帮助管理复杂性并降低风险。

在某些情况下，您可能会发现不值得花费成本对您的遗留应用程序进行现代化改造，而是决定停用它们或只是不接触它们。在其他情况下，你会采取最低限度的措施，而是通过它们迁移到任何一个公共云或私有云现代化的室内应用，提升和转变或重新托管策略。

但是，实际上，要真正实现应用程序的现代化，您将应用以下一种或多种策略：

• 容器化应用程序

• 更新应用程序运行时

• 将单体重构为微服务

单体应用架构

下图是单体应用架构的一个例子，也是我们应用各种策略的起点。

上图是单体应用架构的一个很好的例子：

• 有一个由应用程序组件使用的数据库层。

• 该应用程序通过一个名为 的 Enterprise JavaBean 层公开其数据模型CustomerOrderServices。这些组件利用 Java Persistence API 以最少的编码工作将后端数据模型公开给调用服务。

• 应用程序的下一层，名为CustomerOrderServicesWeb，通过基于 REST 的 Web 服务公开必要的业务 API。该组件利用 JAX-RS 库以最少的编码工作创建基于 Java 的 REST 服务。

• 应用程序的用户界面也通过CustomerOrderServicesWeb组件以基于 Dojo Toolkit 的 JavaScript 应用程序的形式公开。

• 最后，还有一个名为的附加集成测试组件，CustomerOrderServicesTest用于快速验证应用程序的构建和部署到给定的应用程序服务器。

理解为什么这是现代化的候选者的核心是构建和部署此应用程序的方式。这个企业 Java 应用程序虽然是多层的，但由紧密耦合的组件组成，并整体运行在 WebSphere Application Server 上，这使得分发或轻松移动功能变得困难。单体应用程序的可扩展性是资源密集型的，因为需要整个应用程序的新实例（包括应用程序服务器）来支持增加的工作负载。此外，必须增加资源以满足资源最密集的组件的需求，即使绝大多数其他组件不需要内存、CPU 优先级、GPU 访问和网络等资源分配级别。

通过使用本文中描述的策略对这样的应用程序进行现代化改造，将实现以下目标：

• 无需更新整个应用程序即可更灵活地更新功能。

• 更灵活地部署功能以满足用户体验、网络带宽或计算资源要求。

• 更好地控制扩展和资源分配。

策略 #1：容器化应用程序

应用程序现代化之旅的第一步是将旧应用程序容器化。通过使用容器，您的应用程序可以利用云原生技术的一些运营优势，包括可移植性、安全性和可扩展性，而无需重写任何应用程序或更改运行时环境。一旦进入容器环境，就可以在主要云平台和现代内部部署服务器上运行您的应用程序。容器化提供了上述传统单体应用程序所缺乏的一些部署和资源灵活性。

要了解迁移到容器的好处，请从本系列文章的第 1 部分开始。然后，阅读遗留应用程序的容器化。

为了帮助分析您的遗留应用程序，您可以使用 IBM Cloud Transformation Advisor 之类的工具来创建应用程序内容和结构的高级清单，并生成一个迁移包，以帮助您对现代化应用程序进行容器化和部署。Transformation Advisor 生成可用于在容器中运行应用程序的 Dockerfile 和 Python 脚本。

红帽 OpenShift 是一个强大的企业级 Kubernetes 实施方案，可以在您将应用程序的架构和设计从单体迁移到云原生环境时，快速且可扩展地构建、测试和部署应用程序。容器化通常是这条道路上的第一步，但可能不是最后一步。通过选择基于开源软件构建的容器编排器，因为 Red Hat OpenShift 是基于 Kubernetes 构建的，因此您可以在任何云上运行容器，包括IBM Cloud。

策略#2：更新您的应用程序运行时

在对遗留 Java EE 应用程序进行现代化改造时，您可以采取的最简单的步骤之一是使用现代、模块化的企业 Java 运行时（如Open Liberty项目或WebSphere Liberty）来更新您的应用程序运行时，这些运行时已准备好用于基于容器的部署或云部署。

在现代化您宝贵的 Java 应用程序的第 1 步中阅读更多信息。

即使不重构您的单体应用程序以使用微服务，迁移到轻量级应用程序服务器也会降低效率并增加很多价值。您可以通过对应用程序运行时进行现代化改造来降低成本（许可证和资源）和技术债务，并更接近于应用程序的敏捷交付模型。从我们的示例单体应用程序架构来看，这将应用程序服务器的占用空间减少到仅应用程序所需的服务，而不是整个企业 Java 堆栈。

Open Liberty 等现代运行时向上兼容并为您现有的应用程序提供最佳性能，构建在不断发展的 Jakarta EE 和 MicroProfile 规范的云原生架构之上，同时继续支持早期的 Java 构造和功能。

Open Liberty 和 WebSphere Liberty 专为云原生和云应用程序交付而构建。轻松容器化您的企业 Java 应用程序并将其部署到任何基于云 Kubernetes 的容器平台，例如 Red Hat OpenShift，以针对任何公共云（例如 IBM Cloud 或 AWS）、私有云或本地基础设施。然后可以使用 OpenShift 更一致地构建、部署和管理应用程序。

阅读本文以根据您的架构风格为工作选择正确的 Java 运行时。

对于需要在容器中运行的 Java 工作负载，最好使用开源 JVM Open J9。最近，AdoptOpenJDK 项目转移到 Eclipse 基金会的 Adoptium 工作组，以帮助推动高质量 Java JVM 运行时和技术的交付。Eclipse OpenJ9 虽然不直接通过 Adoptium 项目分发，但将通过 IBM 的Semeru Runtimes 项目提供。与其他 JVM 相比，OpenJ9 仅使用一半的内存，并且它的启动速度是其他 JVM 的两倍。

对于 Java 开发平台，IBM 的轻量级多功能云原生框架、Open Liberty项目或Quarkus是一个“Kubernetes Native Java 堆栈”，可帮助您转向反应式编程，同时提供编译-原生能力。

策略#3：将单体重构为微服务

最终，非常需要将您的业务关键型单体应用程序重构为由云原生架构支持的微服务。正如单体应用程序架构的描述中所指出的，这打破了在更换组件或解决服务中发现的问题时更新整个应用程序的需要，并在扩展、保护和分发应用程序的各个部分方面提供了灵活性。反应更灵敏的方式。同样重要的是，可以快速开发新功能以响应不断变化的业务需求。

虽然典型的微服务很小并且功能职责非常狭窄，但并非单体应用的所有功能都可能需要重构为微服务，因为紧密耦合且高度内聚的服务更好地重构为粗粒度的组件。对于那些需要重构为微服务的能力，仍然存在挑战。

您可以在 Mono2Micro简介学习路径中了解有关 Mono2Micro 的更多信息。

IBM 开发了一个名为 Mono2Micro 的工具，可帮助开发人员将其单体应用重构为合适的微服务。Mono2Micro 使用机器学习和深度学习的 AI 技术来分析应用程序工件并自动生成微服务建议（建议的类分组）。

已经开发了几种架构模式来帮助解决上述问题。您可以使用这些架构模式来帮助将您的应用程序重构为微服务：

• 微服务架构的扼杀者模式

• 事件驱动的架构模式

• 分离前端并构建微前端

扼杀者模式

您可以阅读Martin Fowler在 2004 年定义的 Strangler 模式的更多信息，以及 Kyle Brown 于 2017 年在他的文章“将 Strangler 应用程序模式应用于微服务应用程序”中所写的内容。

基于微服务的架构有几个好处，例如能够相互独立地扩展服务。扼杀者模式是围绕现有单体构建微服务的好方法。从本质上讲，您可以在单独的服务中将单体应用的关键功能外部化，而无需重构或重新实现所有内容。Strangler 模式让您可以分阶段实现应用程序的现代化，仅将单体应用的关键功能具体化。

Strangler 模式可帮助您从上述分布式整体策略逐步发展您的架构。微服务在分布式环境中运行。您拥有的微服务越多，通常发生的网络流量就越多。这增加了复杂性，而不是减少了复杂性，这也是您首先使用微服务的原因之一。在重构应用程序时，目标不应该是拥有微服务，而是尽可能地解耦组件，这可能映射也可能不映射到拥有大量微服务。

事件驱动的架构模式

在本文中了解有关如何使用事件驱动和微服务架构构建分布式、高度可扩展的系统的更多信息。

服务可以通过多种不同的方式进行通信：不同的协议、同步与异步、不同的序列化技术等等。启用服务之间通信的最常见和最简单的方法之一是通过同步 REST API 调用。然而，当谈到基于微服务的架构时，这种技术通常被认为是一种反模式，因为来自单体架构的依赖仍然存在，而且它们现在在分布式系统中更难管理。

在将单体分解为微服务时，重要的是尽量减少它们之间的依赖关系。您应该使用异步的、事件驱动的架构，而不是同步 REST API 调用（反模式）。这并没有完全消除依赖关系，而是将它们最小化以实现松散耦合的组件。

您可以使用使用异步消息传递技术（如Apache Kafka）的消息传递架构模式来开发事件驱动的、基于微服务的应用程序。

将单体分解为微服务时，目标是最小化服务之间的依赖关系。事件驱动的架构可帮助您开发松散耦合的微服务。

应用领域驱动的设计方法可以帮助您定义所需的微服务并将它们集成到一个事件驱动的系统中。

分离前端并构建微前端

在对应用程序进行现代化改造时，您采取的一个小步骤是将前端与后端分开。但是，要实现真正的端到端微服务架构，您还应该构建微前端。

通过使用现代框架（例如single-spa ）重构整体式 Web 应用程序，您可以将 UI 的不同部分构建到不同的微服务中。您可以解耦微前端并为微前端构建单独的 CI/CD 管道。

总结和后续步骤

对现有的关键业务应用程序进行现代化改造的决定是正确的。但是，当您转向云原生架构时，正确的策略可以在成功迁移或无法管理的问题积压之间产生差异。

正如本应用程序现代化战略回顾中所讨论的那样，您可能会发现投资回报并不能保证对旧应用程序进行现代化改造的努力。相反，您可能会决定停用它们，或者在完全容器化、基于微服务的云原生应用程序的过程中采取增量的、基于价值的步骤。

转自作者：Niklas Heidloff