IT行业媒体充斥着关于成功迁移到云的公司的成功报道，每天都在创建更多新的云本机应用程序。但是，大多数已移至云的应用程序都是已经非常适合云环境的应用程序。但是在过去的几十年中，公司投入了大量的精力来构建更多的应用程序。2020年的大流行只会增强这些现有资产对我们社会的重要性，需要这些应用程序以最小的投资来适应新的需求。

公司希望从现代应用程序中受益：

• 大大缩短了创新服务的上市时间
• 通过与客户进行实时交互以最小程度的干扰来重新定义客户体验
• 优化IT资源以降低成本和复杂性，并获得竞争优势
• 提高安全性并保护敏感数据

要选择正确的现代化方法并提供正确的投资回报，您需要首先了解每个应用程序的当前状态和您的业务需求。针对您的应用程序进行现代化更新的正确方法可能是：

• 将它们保留在传统体系结构上（不是真正的现代化，而是对某些应用程序的有效选择）
• 对现有应用程序进行现代化改造并可能对其进行重构（利用现有投资来生产现代应用程序）
• 从头开始构建新的替换应用程序（在某些情况下有效）

本文简要介绍了第一个和第三个选项。本文将详细讨论第二个选项，以及通过更新运行时，更新操作和更新应用程序体系结构来更新现有应用程序的含义。

为您的Java应用程序选择正确的现代化方法

您对每个应用程序采取的现代化方法可能会有所不同，并且应基于许多因素：

• 应用程序的预期寿命
• 应用程序的业务需求（例如，创新，敏捷性）
• 成本，无论目的是降低成本还是投资增长
• 技术技能和代码重用

尽管针对在容器中运行的应用程序使用微服务架构存在很多有效的讨论，但这并不意味着它是所有应用程序的最佳选择，而架构的选择会极大地影响运行时的选择。最终，目标是使每个应用程序都在为企业提供最佳投资回报的环境中运行。下图显示了可用的主要现代化选择：

让我们仔细看看为什么您会选择每个现代化选项。

保留传统建筑

您可以选择将应用程序保留在传统体系结构上，因为该应用程序不是战略性的，或者由于各种原因其使用寿命有限。现在花费时间和资源来使应用程序现代化可能并不值得。保留传统架构可以保护您的投资，同时您还可以计划其他现代化措施，例如重新架构和重新编写应用程序。

如果您不移动，则无需执行任何操作，特别是如果您已经在受支持的基础结构上。但是，如果基础结构失去了服务和支持，请考虑升级到受支持的级别。这对于保持最新的重要安全漏洞修复并在遇到问题时能够获得帮助非常重要。您还将获得对新功能和性能改进的访问。

如果您的运行时是传统的IBM WebSphere Application Server（版本8.5.5和9.0.5），则至少需要在2030年前提供支持，而无需脱离Java8。如果需要迁移到新版本，请考虑执行以下操作：运行时现代化作为替代方案。运行时现代化所节省的成本可能使它获得更好的投资回报，并且如果需要的话，它将在将来实现进一步的现代化。

现代化到云原生

对于战略应用程序，将其现代化并将其移动到云有助于降低成本并提高敏捷性。在许多情况下，最终目标是能够在现代云基础架构和运行时上快速更新，重用和扩展应用程序的各个组件，从而极大地缩短了实现价值的时间。一劳永逸地到达那里可能具有挑战性和风险，因此我们建议考虑三个现代化步骤，每个步骤都为企业带来价值，例如减少技术债务和运营成本，以及提高敏捷性：

1. 运行时现代化 （迁移到针对云和容器进行了优化的现代运行时）
2. 运营现代化 （迁移到基于Kubernetes的平台）
3. 架构现代化 （重构为可单独部署和可扩展的微服务）

此顺序是最常见的方法，但是可以按顺序或同时进行运行时和操作现代化。通常，首先进行运行时现代化的选择可能取决于公司是否已经选择并推出了容器平台策略，例如Red Hat OpenShift。如果还没有，那么运行时现代化将是为容器做好准备的重要第一步。

让我们更详细地看一下每个现代化步骤。

步骤1.使运行时间现代化：降低运营成本和技术债务

行动

将您现有的应用程序从传统的运行时迁移到现代的，针对云和容器进行了优化的运行时。

价值

传统的应用程序服务器可以很好地扩展您的应用程序，并且高度可用且可靠，那么为什么要进行现代化？传统应用程序服务器的问题不在于这些质量，而是到达生产中的工作负载以及生产中这些工作负载的效率所花费的时间和成本。

现代敏捷交付最佳实践在连续集成（CI）和连续交付（CD）管道的驱动下，在基于容器的部署中涉及轻量级运行时。这些方法消除了应用程序交付中的低效率。他们：

• 降低运营成本（轻量级运行时消耗更少的资源，并获得更高的吞吐量）
• 减少技术债务（更大的能力来部署最新，安全和受支持的软件）

传统的应用程序服务器运行时根本不是为敏捷性或云设计的，因此它们最终将抑制您实现云原生承诺的能力。是的，您可以通过将现有应用程序和运行时放入容器中来实现操作现代化（这是迈向云原生的有效步骤），但是最终，您需要迁移到专为敏捷交付现代应用程序而设计的现代运行时。

指导

现代化您的应用程序以在Liberty（Open Liberty或WebSphere Liberty（取决于应用程序）上运行，因为WebSphere Liberty提供了一些旧的和传统的特定于WebSphere的API，您的应用程序可能正在使用这些API）。请记住每个应用程序要去的地方。您可能需要在操作上将其现代化为容器/ Kubernetes，并有可能将您的体系结构现代化为微服务。您需要选择一个支持此过程的运行时。现代化的运行时需要支持单片应用程序，微服务以及两者所需的API（Java EE，Jakarta EE，Eclipse MicroProfile或Spring Boot）。如果选择不具有这些特征的运行时，那么您就没有现代化-您将侧身转移到另一个传统运行时或进行重写，并且重写很有可能会带来更高的风险和更高的成本。Liberty，它支持Java EE，Jakarta EE，MicroProfile，

客户体验

美国领先的医疗保健提供商在对Liberty执行运行时现代化时，将资源利用率优化了75％，并将基础架构占用空间减少了50％。

请参阅“ Open Liberty是开发和部署微服务的理想选择的6个理由”（IBM Developer，2020年10月），以了解使用Liberty的好处。

当然，转移到新的运行时并不是一件容易的事，这就是为什么我们建议使用IBM Cloud Transformation Advisor来提供帮助的原因。Transformation Advisor可以：

• 评估您现有的应用程序甚至部署
• 提供有关需要更改的领域以及进行这些更改所需的工作的指导
• 生成配置以帮助迁移

步骤2.现代化操作：降低成本和复杂性，并提高灵活性

行动

通过采用基于Kubernetes的容器编排平台使操作现代化。

价值

采用诸如OpenShift之类的容器编排平台可以使您摆脱专有的部署和集群方法，例如传统的WebSphere Network Deployment单元。这样，您将获得许多好处：

• 通过技术和技能标准化降低了运营成本和复杂性。您将拥有一种在容器中部署，扩展和监视应用程序，数据库，缓存和消息传递的单一方法。
• 跨私有云和公共云提高了操作可移植性。很难找到不支持Kubernetes的云，并且所有主要云都支持OpenShift。

值得注意的是，Kubernetes环境因云而异，因此，尽管Kubernetes在单个环境（例如IBM Cloud Kubernetes Service）中为您提供了一些好处，但选择由OpenShift这样的由多云管理的Kubernetes解决方案可以为您提供这些优势多云带来的好处。您可能不想将其部署到很多云，或者您认为不需要，但是出于法规原因（例如GDPR），您可能会这样做。

指导

转移到容器编排平台需要您开始构建包括您的应用程序和配置的最佳实践容器映像，并在提供公共库，运行时，Java和基础OS的容器映像的基础上进行构建。

如果您已经执行了对Liberty的运行时现代化，那么您所处的运行时就是迁移到容器的理想选择。在转型顾问与传统的WebSphere配置移动创建容器的图像和建议的工具帮助部署到Kubernetes部署。此外，每个Liberty版本都在Docker Hub中提供了容器映像：

• UBI上的WebSphere Liberty容器映像
• Ubuntu上的WebSphere Liberty容器映像
• 在UBI上打开Liberty容器映像
• 在Ubuntu上打开Liberty容器映像

用于创建这些映像的指令，脚本和Dockerfile可在开源中获得，以供您构建自己的容器映像：

• 构建WebSphere Liberty容器映像
• 建立开放的自由容器映像

最后，Open Liberty Operator在Kubernetes环境中帮助Liberty部署和管理。该运营商对WebSphere自由和开放自由的工作在支持基于Kubernetes的平台运营框架，包括OpenShift。

如果您选择在运行时现代化之前进行操作现代化，因此您的应用程序当前在诸如传统WebSphere之类的传统应用程序服务器上运行，则可以将应用程序和服务器部署在单个容器中，并使用OpenShift对其进行扩展。注意，并非Kubernetes / OpenShift中提供了WebSphere ND中所有可用的集群功能（例如，远程EJB集群），因此需要注意确保应用程序正确运行和扩展。

为了帮助使用传统的WebSphere Applications Server进行操作现代化，IBM维护了当前支持版本的docker映像。

将传统的应用程序服务器移动到容器中仅应被视为迈向云原生的垫脚石。传统的服务器运行时从来没有为容器，现代DevOps实践或云原生的最佳实践设计，例如12要素应用程序。从长远来看，迁移到专为容器和微服务设计的运行时将为您提供更好的服务，而Liberty是理想的选择。

步骤3.使架构现代化：实现最佳的扩展能力和云原生敏捷性

行动

将单片应用程序重构为更细粒度的云原生微服务。

价值

您已将操作现代化到基于Kubernetes的平台，并将整体应用程序迁移到可以在针对容器和云优化的运行时上运行。下一步是开始转向微服务。这样，您将能够真正释放云原生微服务的全部优势：

• 通过持续集成，持续交付管道，敏捷交付单个服务更新。更新的交付不再受整个整体交付的约束。
• 独立地扩展单个服务的能力，以优化云使用和成本的方式对不断变化的工作负载需求做出反应。

指导

架构现代化有很多方面，但是第一步是要确定整体应用程序中重构为微服务的功能。一个新的由AI驱动的工具称为IBM Mono2Micro（可在beta中使用）可以分析您的整体应用程序，并提出“分区”作为候选对象以分离成微服务。您不必采取大爆炸的方法来分解整个整体。实际上，诸如“扼杀模式”之类的策略已成功地用作增量方法。

在将整体拆分为微服务时，您需要考虑如何不仅分离业务逻辑，而且分离任何关联的数据。将您的应用程序重构为较小的可部署单元会有好处，并且可以用作朝着独立微服务迈出的一步，但是，如果您仍然使用单片数据存储来支持所有服务，那么您的服务仍然是耦合的。数据现代化可以成功采用“ Strangler”风格的策略来随时间解耦数据。这些措施包括为新服务设置单独的数据存储，批处理数据复制，双重写入以及代理来自整体的数据请求，以使新存储联机并与整体一起运行新服务。

迁移到松散耦合的逻辑和数据的本质是需要了解对事务的影响。CAP定理指出，您只能同时保证一致性，可用性和分区容忍这两种质量。在传统应用程序中，使用分布式两阶段事务管理器来始终确保一致性。将应用程序分成数十个或数百个微服务，每个微服务都由其自己的数据存储支持，这使得分布式事务变得不切实际。这导致了有利于可用性并最终实现一致性的方法。有两种方法可以实现此目的：Sagas（例如，MicroProfile Long Running Actions）和命令查询责任分离（CQRS）。在任何时间点，系统状态都可能因设计而不一致—视图数据可能无法立即反映最新更新，并且允许微服务之间“协调”的活动独立完成。

后续步骤 ：探索将单片应用程序现代化为微服务的挑战和模式。

建立新的云原生

对于特别具有挑战性的应用程序，其现代化成本超过了收益，则可以考虑从头开始构建新的云原生应用程序。这样，您就有可能实现前面现代化部分中概述的优势，例如降低基础架构成本和提高敏捷性。

选择运行时以跨技能，技术和成本进行优化很重要。如果要对现有应用程序进行现代化以及重写或编写新应用程序，则有必要优化所使用的运行时和API的数量。您选择的运行时应该使用支持新的云本机API（例如MicroProfile）和现有API（例如Java EE）以及您可能使用的体系结构样式（例如，整体式，微服务）的运行时。 ）。还应考虑基础架构以及与使用运行时相关的许可成本。不要以为所有新应用程序都应作为微服务来实现，因为这样做的收益和成本可能与您的应用程序目标不符。

考虑不同体系结构样式的利弊，以帮助您选择合适的运行时，以及为什么要使用Liberty。

DevOps的重要性

如果您已经在进行DevOps，持续集成和持续交付，则需要在每个阶段考虑现代化的影响。本文讨论的每种现代化类型都会影响您的DevOps工作：在具有新操作功能的新运行时上进行构建，测试和部署。

如果您尚未进行DevOps，持续集成或持续交付，则需要将其纳入现代化战略中。在现代化过程中尽早采用DevOps有很多优势，但是当您转向微服务时（例如，作为体系结构现代化的一部分或构建新的应用程序），这绝对是强制性的。您的微服务策略将无法通过人工，劳动密集型的交付流程和孤立的组织获得成功。

许可证灵活性有助于现代化

无论您采用哪种现代化策略，您的软件基础架构需求都会不断发展。虽然您可能会开始在传统的WebSphere Application Server上运行现有应用程序，但是随着您的前进，某些工作负载可能会迁移到Liberty，并可能带有新的架构，例如在Kubernetes上运行的容器化微服务。

IBM提供了灵活的许可选项来帮助完成此过程。WebSphere Application Server的每个单独的版本都包含Liberty的权利。因此，例如，您可以选择对传统的WebSphere或Liberty使用WebSphere Application Server网络部署权利。如果要在各个版本之间重新平衡，那么IBM WebSphere Application Server Family Edition之类的产品也使您能够做到这一点。您可以从运行WebSphere Application Server Network Deployment开始，然后在Kubernetes上部署到Liberty时，只需缩减所拥有的已部署WebSphere Application Server Network Deployment服务器的数量，而使用这些权利来部署Liberty。

结论

本文提供了一个框架，可以为每个应用程序选择适当的现代化方法。本文概述了如何将现代化分为三个步骤，每个步骤都提供价值，以及Transformation Advisor和Mono2Micro之类的工具如何提供帮助：

• 运行时现代化：转向现代的，微服务和容器优化的运行时，以减少基础架构成本和技术负担。
• 运营现代化：迁移到基于Kubernetes的平台，以降低运营成本和复杂性，并提高跨公共云和私有云的可移植性。
• 体系结构现代化：分解为可单独部署和可扩展的微服务，以提高交付敏捷性并优化云资源的使用。

本文描述了选择正确的运行时进行现代化的重要性：支持单体应用程序和微服务的运行时，以及两者所需的API，以及该运行时如何为Liberty。本文还描述了Kubernetes作为通用云基础架构的好处，以及像OpenShift这样的平台如何真正实现跨公共云和私有云的自由部署。

我们希望这些信息对您计划和执行现代化有帮助。

本文由大飞翻译，大飞作为it的一员也希望和更多程序员们共同交流，可以私信我。如果你想不踩坑都可以私信我“Java”可获取大飞精心整理的大厂全套面试资料及技术视频。