使用 Anthos 实现 Java 应用现代化:用户指南

本文档概述了使用 Anthos 对旧版单体 Java 应用进行现代化改造的流程、最佳做法和工具。

本文档适用于 CTO、CIO、企业架构师、应用开发者、IT 安全管理员、应用开发者、DevOps 团队和站点可靠性工程 (SRE) 团队。假定您具备容器化的基础知识,并熟悉其运营和开发优势。

本文档介绍了一个两阶段的现代化方法:

  1. 容器化。在此阶段,您将合适的候选应用容器化并部署到 Anthos 平台(无论是在本地还是 Google Cloud 中)。此阶段使用各种服务和技术,例如 Migrate for Anthos、现代持续集成/持续部署 (CI/CD) 做法和系统集成商工具。
  2. 重构和改换平台。随着时间的推移,您会对旧版单体式应用进行重构和改换平台,使其成为现代 Java 框架(如 Spring Boot)和微服务。

本文档为每个阶段提供指导和资源。它还提供备用路径,以便将企业内部保留在虚拟机 (VM) 上。

现代化案例

许多组织在努力保持业务应用运行的同时,还试图进行创新。开发和运营团队必须满足应用服务的新需求,并且能够维护、运营和改进现有应用组合。

来自数字商业计划和数字转换的目标的这一新需求可改进现有功能。根据 Gartner 报告(构建多平台应用现代化业务案例,2019 年 11 月),90% 的当前应用可以使用到 2025 年,支持和管理这些应用的技术负债将继续叠加,并且会消耗 40%以上的当前 IT 预算。

虽然企业会开发和采用新应用,但大部分应用仍然是传统的单体式应用。许多旧版应用在专有商业应用服务器(如 IBM WebSphere 或 Oracle® WebLogic)上运行。由于这些应用通常经过充分优化、维护和管理,因此企业面临着在其上进行创新的挑战。此外,专有应用服务器会增加运营开销,并且需要(在许多情况下)费用控制许可协议。

许多研究表明,通过将传统应用现代化而不是重写现有的应用代码,组织可以节省时间和金钱。任何对旧版应用进行现代化改造的策略都必须专注于缩短现代化的时间和成本。

现代应用

现代应用可帮您为客户提供更好的体验,从而留住客户并提高客户满意度,进而提高盈利能力。现代应用和平台开发的原则强调了数字化转型的优势。以下部分介绍了这些原则。

提高开发者和运营者的工作效率

旧版应用通常是单体式应用。这些应用具有一个执行若干函数的大型代码库。随着应用以及开发和管理团队的发展,快速维护应用和发布新功能变得越来越困难。团队之间存在的许多依赖项,必须先进行协调和批准,才能将更改发布到生产中并交付给客户。这种动态会导致开发者和运营人员的工作效率降低,同时降低客户满意度。

现代应用使用微服务构建。单体式应用的不同网域会拆分为单独的服务,每个服务负责特定功能(称为“微服务”)。该架构具有以下优势:

  • 对于开发者。将服务彼此分离,使您的开发人员可以独立于其他服务使用其特定功能。这种方法可以提高开发者的工作效率,因为开发者可以向他们的服务添加功能,而无需紧紧依赖其他服务和团队。
  • 对于运算符。每个微服务版本都实现了细微更改,相比于一个大型复杂更改,这些细微更改更容易被运营团队管理。如果发布失败,以受此可控方式部署较小的更改可降低风险,从而增加操作效率。
  • 对于客户。与单一架构相比,现代架构的开发和运营效率有助于您的团队更快地向客户交付新功能。

专注于服务和 API

旧式应用通常从基础架构的角度考虑。服务器、虚拟机 (VM)、网络和存储空间是单体式应用的关键设计元素。现代应用从服务和 API 角度考虑。专注于服务和 API 上具有的诸多优势:

  • 服务冗余和弹性。您可以在任何位置(通常是虚拟机、容器或集群)运行服务。
  • 服务可用性。以服务为中心进行操作可以提高应用的整体可用性。只要服务可用,基础架构故障就会变得无关紧要。根据服务和 API 而不是基础结构进行设计和思考会强调正常运行时间-正常运行时间有助于您达到服务等级目标 (SLO)

在容器中作为微服务运行。

旧版应用通常作为虚拟机或裸机运行。这些平台价格昂贵,使用率低(具有未使用的 CPU 和 RAM),比现代云端平台(尤其是裸机服务器)更难以管理。现代应用程序在容器中作为微服务运行,因此具有多项优势,具体如下所示:

  • 更小、更高效的应用。容器可将微服务打包为比单体应用小两到三个数量级的微服务。
  • Linux 用户空间隔离您可以在单个主机上运行多个容器,以便高效利用主机。
  • 不同环境和基础架构之间的可移植性。由于容器将应用及其所有依赖项和所需的库封装在一起,因此您可以在任何环境(本地数据中心或公共云环境)中运行容器。

基于开放式标准构建

旧版应用通常使用商业或许可产品实现功能。这种方法不仅因许可费用而价格高昂,而且还使应用高度依赖于商业平台。

在某些情况下,商业软件受其基础架构或硬件的限制。例如,如果软件只能在本地运行,则您的企业必须管理昂贵的数据中心和基础架构(例如网络、存储、服务器、电源和 HVAC)。

现代应用和服务通常是使用开源软件构建的,具有以下优点:

  • 可扩展性和可移植性。您可以在任意位置运行服务。
  • 支持。Kubernetes 和 Docker 等经过广泛采用的开源技术通常具有强大的社区(由众多公司组成),构建不受单个公司约束或也不能从单个公司获益。这种开源方法可为产品提供总体上更好的特征集。与几乎所有商业等效产品相比,您采用的开源技术(例如Kubernetes)越多,功能集就越强大。
  • 灵活性。在此模型中,您的企业不再需要为应用平台或基础架构锁定单一供应商。通过接受开放式标准,您可以根据客户和业务需求做出应用和基础架构方面的决策。

现代平台

现代应用需要现代平台。现代平台必须满足多个需求。

快速,可靠和安全的功能发布

现代平台必须支持快速、可靠且安全的新功能发布。

  • 快速。此要求取决于足够自动化的部署服务和新功能。自动化消除了人工作业和错误,提高了交付速度。
  • 可靠。平台必须让团队逐步发布功能,或者在功能不起作用时将其恢复到原始状态。
  • 安全。平台必须支持精细的访问权限控制。只有获得授权的运营商才能访问服务或将功能和服务部署到该平台。

服务优先级

现代应用在设计,开发和运行时会考虑服务而非基础架构。这种服务的优先级取决于能修复基础架构故障的平台。现代平台具有从硬件和软件故障中恢复服务(和平台本身)的内置功能。

具有一致性控制平面的各种混合云和多云端方法

作为数字化转型的一部分,许多企业正在为自己的服务组合采取多云端或混合云策略。也许您无法将某些应用从本地数据中心迁移到公有云(出于监管、合规性或安全性方面的原因),但仍想将云用于其他服务。现代平台会(经常)在多个环境中运行,例如本地数据中心、私有云或一个或多个公共云。在各种基础架构上运行时,现代平台必须向开发者和运营商提供统一的一致性控制平面体验,从而提高运营效率。

所有内容都作为声明式代码

旧版平台(如虚拟机)本质上是命令。运营商通常会创建资源和提供在应用运行时执行的脚本和配置。当运营商更改应用时,它们会直接对运行应用的虚拟机进行更改。此过程可能会导致配置偏移,这意味着在任何时间点,都无法保证应用和平台处于预期状态。在这种环境中,很难进行问题排查和故障恢复。

现代平台是声明系统,其中所有资源均被定义为代码,也称为基础架构即代码 (IAC)。基础架构、服务、部署、安全性和政策会被编码到定义平台预期状态的资源文档中。此声明方法使运营商通过统一语言定义其服务、安全性和政策。由于这些资源都是代码,因此可以存储在代码库中,并且进行与应用相同的代码检查审查。当平台的状态位于 Git 代码库(以及每个状态更改的所有提交历史记录)中时,在系统故障或灾难发生时,其更容易恢复到之前的状态。

Anthos 平台

Anthos 是 Google Cloud 的现代应用平台。借助开放式混合式多云 Anthos 平台,您可以对现有应用进行现代化改造,构建新应用,并以更安全的方式在任何位置运行这些应用。Anthos 以 Google 开创的开源技术(包括 Kubernetes、Istio 和 Knative)为基础构建而成,可帮您实现本地和云环境之间的一致性,并加快应用开发速度。

下图显示了典型企业环境中的 Anthos 组件及各组件之间的互动:

Anthos 平台支持的核心现代化函数。

以下部分简要介绍了 Anthos 的核心组件。

Anthos 集群:容器编排

Anthos 的主要计算环境依靠 Anthos 集群来管理您打算部署应用的环境中的 Kubernetes 安装。这些产品捆绑了上游 Kubernetes 版本,使您可以创建、扩缩和升级一致的 Kubernetes 集群。

Kubernetes 包含两个主要部分:控制平面节点组件。当使用 GKE 时,Google Cloud 托管控制平面,Kubernetes API 服务器是客户唯一能够访问的控制平面组件。GKE 使用 Compute Engine 中的实例管理客户项目中的节点组件。使用 Anthos 集群时,所有组件都托管在客户的本地虚拟化环境中。

安装并运行 Kubernetes 后,您可以访问管理应用部署、配置、升级和扩缩的常规编排层。

Anthos Config Management:政策管理

借助 Anthos Config Management,您可以使用被称为配置的文件管理单个集群、多租户集群和多集群 Kubernetes 部署。将配置存储在 Git 代码库中。

一些配置是 Kubernetes 对象清单。其他配置不是对象清单,但提供了 Anthos Config Management 所需的信息。您可以使用 YAML 或 JSON 编写配置。 Anthos Config Management 会监控这些文件的更新,并自动将更改应用于所有相关集群。

通过“配置即代码”方法,您可以使用与管理部署的应用相同的原则来管理 Anthos 集群的配置。

Anthos Service Mesh:服务管理

Anthos Service MeshIstio 兼容框架,可用于连接、监视和帮助保护在 Anthos 集群上运行的服务。借助 Anthos Service Mesh,无需更改服务代码,即可创建已部署服务的网络(例如负载平衡、服务到服务身份验证和监控)。

Anthos Service Mesh 会自动为每个应用的 Pod 注入 Sidecar 代理Pod 是 Kubernetes 应用的基本执行单元。Pod 会封装应用的容器(或者在某些情况下,有多个容器)。在 Anthos Service Mesh 中,每个 Pod 都包含两个容器:应用容器和一个 Envoy 代理容器(也称为 Sidecar 代理)。Sidecar 代理会拦截进出 Pod 的所有网络流量。Anthos Service Mesh 还配置了一个入站流量网关来管理该网格的入站流量。您可以使用开源 Istio API 来配置在辅助信息文件和网关上强制执行的政策。

现代化之旅

Google Cloud 提供了一个规范性过程,用于将 Java 应用从单体式状态迁移到微服务。您可以选择采用以下步骤,并以最适合自己业务需求和需要的速度移动:

  1. 从在虚拟机中运行的应用中提升合适应用到在容器中运行的应用中,并对其进行现代化改造而无需重写任何代码。
  2. 使用现代 CI/CD 做法将容器化应用部署到 Anthos 平台。某些应用可能不是容器化的理想之选,可能仍然作为虚拟机存在。
  3. 随着时间的推移,将应用重构为 OSS 应用堆栈、现代框架和微服务。

以下流程图说明了此旅程。

现代化改造的步骤流。

这些重要步骤将在下一部分中介绍。

现代化改造步骤

以下部分介绍了现代化过程的每个步骤,以及 Anthos 和 Migrate for Anthos 在每个阶段的作用。

第 1 步:将 Java 应用容器化

在这种现代化改造步骤中,您可以将作为虚拟机运行的适当 Java 应用容器化。

针对现代框架和封装应用的容器化。

容器化是一个将应用代码及其操作的所有依赖项和库打包在一起的过程。您可以在单个主机上运行多个容器,每个容器都有自己隔离的独立应用环境。容器是虚拟机的轻量级、可移植且高效的替代品。

通常,您可以使用 mavengradle 等工具构建 Java 应用并打包为 JAR 文件。然后,可以在虚拟机或裸机服务器上运行二进制文件。

您可以通过以下两种方式之一将 Java 应用容器化:

  1. 使用 Migrate for Anthos 来提升应用并对其进行现代化改造。
  2. 使用系统集成商工具构建容器。

使用 Migrate for Anthos 进行升级和现代化改造

您可以使用 Migrate for Anthos 将应用直接从虚拟机迁移到容器化工件(例如 Dockerfile 或 Kubernetes 资源清单)。然后,将容器部署到 Anthos(在 GKE 上以及在 Anthos clusters on VMware 上)。

使用 Migrate for Anthos 进行迁移

使用 Migrate for Anthos 迁移应用的过程如下:

  1. 确定迁移候选项。在此步骤中,您将评估哪些应用适合迁移。两种适合迁移的应用类型:
    • 源代码无法访问的应用。也许开发者已不再在公司,并且代码库也不再受支持。您可以使用 Migrate for Anthos 中的简化容器化流程,将应用迁移到 Anthos,而不是将这些应用作为虚拟机进行管理。
    • 已维护但未开发的应用。某些应用程序可能未积极开发,但由于对其他服务的依赖性,所以企业仍然需要它们。Migrate for Anthos 简化了平台现代化过程,该平台支持这些应用。
  2. 迁移到 Anthos。在确定合适的迁移候选者之后,您可以使用 Migrate for Anthos 将虚拟机转换为可以通过现代 CI/CD 做法部署到 Anthos 的容器化工件(请参阅下一部分)。Migrate for Anthos 还可帮助转移应用数据和状态。
Migrate for Anthos 和极具挑战性的迁移

企业管理的应用数量可能为数千个。要迁移的应用程序数量或容器化的复杂性可能会阻碍企业继续推进重要的云计划。企业可能会因此错过业务机会和一流公共云服务的优势。这些服务可能是数据和分析服务(例如 BigQuery)、人工智能应用(例如 AutoML)或机器学习 (ML) 应用(例如 Google Cloud 的预训练 API)。

Migrate for Anthos 可通过以下方式帮助您应对应用组合的挑战和复杂性:

  • 处理大规模应用迁移。使用 Migrate for Anthos,您可以将许多应用迁移到 Anthos 中,并对其进行现代化改造,而不会给开发人员和运营商带来技术负担。
  • 简化容器化。容器化众多的应用可能很复杂,企业可能没有足够的技能或资源来及时支持大型现代化工作。对于此类情况,Migrate for Anthos 为您提供了简化且高效的 Anthos 和现代化路径。

如需了解详情,请参阅 Migrate for Anthos 文档

其他容器化工具

Docker 是一种广泛使用的构建容器映像的平台。Dockerfile 是一个文本文档,其中包含您可以在命令行上调用用于组装映像的所有命令。要创建 Docker 容器,需要构建二进制文件(JAR 文件),然后将其打包到 Dockerfile 中。创建 Dockerfile 后,您可以在 CI/CD 流水线中使用它。下图说明了使用 Dockerfile 的工作流。

可在容器化中使用的工具。

第 2 步:使用现代 CI/CD 将应用部署到 Anthos

在此现代化步骤中,您可使用现代软件交付做法将容器化 Java 应用部署到 Anthos。

使用 CI/CD 的容器化过程。

应用需要一种精心设计的、自动化的、可重复的和可靠的方法来构建、测试和交付给客户。由于多个开发团队会不断添加功能,因此他们经常通过使用 CI/CD 来构建、测试和部署容器化应用。

现代软件交付实践的优势

借助 Anthos 的现代 CI/CD 或软件交付平台,您可以执行以下操作:

  • 创建和更新预配应用的最佳做法。
  • 通过入门版(或样板)项目上手新应用。
  • 在不干扰其他应用开发的情况下开发和迭代应用。
  • 跨平台无缝实施和传播政策。
  • 使用 GitOps 进行部署、改进版本管理和更改跟踪。

使用 Anthos 的软件交付平台

下图中的组件构成了一个完整的软件交付平台,该平台可以与 Anthos 平台一起使用。

在 Anthos 平台中找到的核心软件交付组件。

每个组件都向系统中运行的系统和应用提供功能。通常有多个团队(例如开发、操作和安全团队)负责维护平台的正常运行时间、配置、稳定性和规模。

软件交付平台的核心组件是 CI/CD 系统。在开始定义 CI/CD 过程时,您需要确保每个组件都会生成或使用符合标准化接口的工件。在使用标准接口时,当市场上有更好的实现方案时,会更容易更换每个组件。在为容器化应用创建平台时,您可以从三种标准接口中选择:

  • Git 代码库
  • Docker 映像
  • Kubernetes 清单

准备好这些接口后,您可以按照下图所示的流程创建一个可重复使用的灵活 CI/CD 流水线。

可重复使用的持续交付和部署流水线中的组件映射

具体过程如下:

  1. 开发者将应用代码提交到应用的 Git 代码库。
  2. CI 系统会测试代码,创建 Docker 映像工件,并将该映像存储在注册表中。
  3. 准备好部署工件之后,对工件的引用将添加到应用配置文件中。
  4. 该应用配置被渲染为 Kubernetes 可读格式,并存储在代码库中,该代码库可将其部署到预生产环境中。
  5. 在更改提交到代码库后,运营商会查看更改,然后合并到主分支。
  6. 应用会部署到生产环境中。
  7. 当运营商希望在整个组织中进行更改时,这些变更会提交到其代码库,用于触发应用配置。开发者部署下一个更改时,开发者会选择运营商的更新。
  8. 同时,安全工程师可以实施和调整政策,用于定义可通过提交给自己的政策存储库来部署的内容。

第 3 步:优化旧版 Java 应用本地虚拟机

在此现代化步骤中,Java 应用在本地数据中心或 Google Cloud 中作为虚拟机运行,如下图所示。

决策是要迁移应用还是在本地优化应用。

某些 Java 应用可能不太适合容器化,原因如下:

  • 您的某些应用属于关键业务。如果将业务关键型应用迁移到容器的风险过高,您仍然可以通过将虚拟机迁移到 Google Cloud 来获享基础架构弹性成本收益。在 Google Cloud 中,可通过自定义虚拟机的大小来最大化其使用费。
  • 运营团队不熟悉如何管理现代平台。某些运营团队可能不太适用虚拟机环境,或者不具备在现代容器化平台上进行操作所需的技能。例如,您的团队可能已熟悉当前用于管理旧版应用连接性和依赖项的工具链,但需要花时间在生产环境中操作一个容器化的平台。
  • 需要分阶段采用云。例如,您可能希望开始采用云,但不想一次进行太多更改。或者,由于风险,您可能不希望同时更改环境(从数据中心到云端)和平台(从虚拟机到容器)。
  • 预算和运营限制。这些限制可能包括硬件/基础架构、许可或应用架构要求。

运行虚拟机工作负载的选项

您可从以下选项中选择一个或多个,来更高效地运行虚拟机工作负载:

  • 在 Google Cloud 上。您可以通过两种方式在 Google Cloud 上运行虚拟机:
    • 作为 Compute Engine 实例。Compute Engine 提供了在 Google 数据中心中运行的可配置虚拟机,其可访问高性能的网络基础架构和块存储。该选项使企业无需管理本地数据中心和服务器和为虚拟化商业许可(如果适用)付费。
    • 作为 VMware 即服务 VMware 和 Google Cloud 强强联手,提供一个开放的平台,来确保多云端环境和混合云环境中的云应用具有一致的部署、操作和安全性。此选项适用于目前正在运行 VMware 的企业,该 VMware 依赖于特定 VMware 功能。企业要么在混合云环境中,希望用一个一致性控制平面来管理其虚拟机(跨多个环境),要么希望不再自行管理数据中心和服务器基础架构。
  • 本地数据中心。出于以下某些原因,您可能会将某些应用作为虚拟机作在本地运行:
    • 监管或合规性注意事项
    • 要求离用户或其他应用更近的性能需求
    • 本地硬件的当前投资

用于迁移虚拟机的工具和解决方案

Google Cloud 提供了可用于将虚拟机迁移到 Google Cloud 的各种工具和解决方案。借助 Migrate for Compute Engine,您可以在数据在后台以透明方式进行迁移的几分钟内验证、运行应用并将其迁移到 Google Cloud。如需了解如何迁移到 Compute Engine,请参阅迁移到 Google Cloud:使用入门

对于向 VMWare 即服务的迁移,Google 与值得信赖的合作伙伴合作,提供可帮助 VMware 迁移到 Google Cloud 的专业服务。

第 4 步:将应用重构为微服务

对平台进行现代化改造后,您可以专注于对平台上运行的应用进行现代化改造。在此阶段,您将获取在 Anthos 平台上运行的应用并将其重构为微服务。

重构应用在现代化流程中所处的位置。

您可能有一些应用仍然在容器中作为单体应有运行,但这不是问题。对应用进行现代化改造的前提条件是将应用迁移到现代平台(例如 Anthos)。迁移后,随着时间的推移,可能会将应用现代化改造为微服务。

迁移到 Anthos,可让开发者和运营商熟悉新的应用和平台管理方式。开发者习惯于更快地合并代码并经常进行测试,而运营商更熟悉构建、测试和向客户交付软件的现代方式。

对于在 Anthos 平台上运行的应用,业务线可以优先考虑哪些应用将现代化改造为微服务。Google 和 SI 合作伙伴提供了多种开发者和运营商工具,以帮助企业完成这一现代化步骤。以下部分将讨论这些资源。

Spring Cloud GCP

作为重构的一部分,您可以将 Java 应用移植到现代 Java 框架(如 Spring Boot)。Spring Boot 和 Spring Framework 为基于 Java 的现代企业应用提供了全面的编程和配置模型。Spring Cloud 为开发者提供了各种工具,用于快速构建分布式系统中的一些常用模式 - 例如,配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全球锁定、领导者选举、分布式会话和集群状态。

为了简化从 Spring Boot 应用使用 Google Cloud 的流程,Spring Cloud GCP 项目提供了几个库和功能来支持以下 Google Cloud 产品:

  • Pub/Sub:Spring Integration 和 Spring Stream
  • Cloud Spanner、Datastore 和 Cloud SQL:Spring Data
  • Cloud Logging 和 Cloud Trace
  • Firestore:Spring Data Reactive Repositories
  • Cloud Storage:Spring Resource 和 Spring Integration
  • Cloud Vision API:CloudVisionTemplate 模板
  • Identity-Aware Proxy (IAP):从 IAP 标头中提取的 Spring Security 身份信息
  • BigQuery:Spring Integration

开发者工具

Google Cloud 提供的工具可帮助您创建现代的容器化 Java 应用。其中一些工具包括:

  • Cloud Code Cloud Code 可为 Kubernetes 应用的整个开发周期(从创建用于开发和测试的集群到在生产环境中运行已完成的应用)提供 IDE 支持。Cloud Code 还会为您提供可直接运行的示例、开箱即用的配置代码段以及量身定制的调试体验,让您可以使用 Kubernetes 进行开发!Cloud Code 提供了简化的 Google Kubernetes Engine (GKE) 体验,其简化托管在 Google Cloud 上的集群创建过程,并更好地与 Cloud Source Repositories、Cloud Storage 和各种 Cloud 库等 Google Cloud 工具进行集成。您可以将 Cloud Code 与 VS CodeIntelliJ 搭配使用。
  • Artifact RegistryArtifact Registry 提供了一个用于存储工件中心位置,并构建依赖项作为集成的 Google Cloud 体验的一部分的。Artifact Registry 提供用于管理软件包、库和 Docker 容器映像的单个位置。您可以在本文档前面介绍的现代 CI/CD 流水线中使用这些工件(软件包和容器映像)。
  • 构建工具,如 JibBuildpackJib 和 Buildpacks 允许您使用已知的 Java 工具(例如 maven 或 gradle)来构建容器。如果没有此类构建工具,您必须手动创建和测试 Dockerfile。这种手动方法需要运行 Docker 守护程序的主机来创建和运行容器。此过程包括更多步骤,对于希望尽可能快速,无缝地将代码投入生产环境的开发人员来说,该过程可能是重复的。在单个构建步骤中,Jib 编排二进制文件的构建,创建容器映像,并将该映像推送到 Container Registry。Jib 使用开发者熟悉的构建工具,提高开发者的工作效率。将 Java 容器推送到注册表后,您可通过 CI/CD 流水线对其进行部署。下图显示了 Buildpack 或 Jib 的总体流程。

    在创建微服务的过程中适合使用其他开发人员工具的地方。

重新平台化到开源应用服务器

对于某些应用,重构 Java 应用还需要重新平台化 Java 应用服务器。为了降低许可费用,在商业应用服务器平台(例如 WebSphere 或 WebLogic)上运行的 Java 应用被重新平台化为开源组件(例如 JBoss 或 Tomcat)。

旧版 Java 应用架构

旧版 Java 应用通常采用 3 或 4 层 JEE 架构。JEE 架构支持多层企业应用的基于组件的开发。下图显示了通常在 JEE 应用系统中找到的层级。

多层平台架构,包括演示文稿层级、应用层和企业数据层。

层级如下:

  • 演示文稿层级。在演示文稿层级中,网络组件(如 Servlet 和 JavaServer 页面(JSP 或 JSF))或独立 Java 应用为中间层级提供动态接口。
  • 应用或中间层级。在应用层级或中间层级中,企业 Java Bean 和网络服务为应用封装了可重复使用、可分发的业务逻辑。这些服务器层级组件包含在 JEE 应用服务器上,该服务器为这些组件提供执行操作和存储数据的平台。
  • 企业数据层级。在数据层级中,企业数据通常在关系型数据库中存储和持久化。

这些不同的层级通常部署在虚拟化环境中,并依赖于应用服务器,这可能会产生高昂的许可费用。

改用开放式标准的优势

改用开放式标准可降低许可费用,并提供基于云的部署方法和平台的优势。

工具和解决方案

Google Cloud 合作伙伴与各种系统集成商 (SIs) 合作,这些集成商具有经过验证的方法和工具,可用于重新平台化 JEE 应用并采用 OSS 技术。

重新平台化的过程从评估旧版 Java 应用开始。评估时会考虑多种因素,包括应用的复杂性、功能、使用情况指标以及业务关键性。此评估会生成一个要重新平台化的候选应用的优先级别序列表。SIs 提供开发者和 DevOps 工具,帮助企业从源代码中移除所有商业应用服务器依赖项。在进入下一阶段(部署)之前,系统会考虑每个应用的测试和退出条件。此阶段适用于可访问源代码且存在平台开源变体的应用。

重构最佳做法

以下两篇 Google Cloud 文章介绍了从单体式应用迁移到微服务的优势和过程:

使用 Anthos Service Mesh 将微服务连接到虚拟机

企业拥有各种应用。几乎所有企业最终都会在以下某个平台上运行应用:

  • 用于在容器中运行微服务的 Anthos 平台
  • 用于运行虚拟机的虚拟化平台

通常,在这两种平台中运行的服务会相互依赖,并且能够安全地相互通信。对于在 Anthos 平台上运行的微服务,Anthos Service Mesh 为虚拟环境中在 Anthos 外部运行的虚拟机提供了一个安全增强型连接。

使用虚拟机的 Anthos Service Mesh 的优势

  • 虚拟机可以利用与在 Anthos 上运行的容器和微服务相同的 Kubernetes 风格的声明性策略和安全管理框架。这种方法使运营商可以确保在 Anthos 上运行的容器和在另一个环境中运行的虚拟机之间存在安全增强型 (mTLS) 认证连接。
  • 无需对现有虚拟机进行重新编码,即可使其显示为 Anthos 平台的服务。虚拟机显示为服务后,Anthos 会将其视为在 GKE 中运行的服务。
  • 运营商无需任何检测即可获取虚拟机增强了的可观察性(指标)这些指标使其看起来如同一个在 Anthos 上运行的服务。

虚拟机容器化

随着时间的推移,您可以将现有的重构虚拟机移动到容器。这种方法允许您按照自己的进度进行现代化改造,对要现代化的应用进行优先排序。

后续步骤