应用程序部署类型

  • 5 分钟

可通过多种方式将 Java 应用程序部署到云。 本单元将探索各种选项，以便在下一单元中更好地了解 Azure 提供的服务。

虚拟机、容器或平台即服务？

主要问题是需要或需要将应用程序部署到虚拟机（VM）、容器内还是作为平台即服务（PaaS）解决方案部署。

  • 使用 虚拟机时，你位于类似于本地或经典数据中心环境的世界。 Azure 提供一组预配置 VM，这些 VM 运行主要作系统（Windows 和 Linux），需要配置和维护这些计算机。

    我们建议你最初采用此解决方案，因为它最接近大多数企业在迁移到云之前已经使用的解决方案。 他们通常安装自己的配置管理软件，安装自己喜欢的 Java 版本，然后可以像过去一样运行 Java 工作负载。

    如果拥有一个经验丰富的运营团队来配置和维护 VM 解决方案，并且有特定的用例，则 VM 解决方案可以正常工作。 例如，你可能使用的是某些本机库或某些专有软件，例如 Oracle WebLogic Server 或 IBM WebSphere 应用程序服务器。

  • 使用 容器时，仍拥有 VM 的大部分控制权，但作工作量较少。 可以安装自己的 Java 虚拟机（JVM）或某些特定软件，容器将在本地或任何云提供商上运行。

    由于容器提供了很多自由，因此它们遭受了与 VM 相同的一些问题。 如果你提供自己的 JVM，则需要根据需要更新和修补它。 因此，Docker 映像需要良好的持续集成和持续交付（CI/CD）工具链才能正确维护容器。 由于 Docker 映像可以在本地运行且比 VM 更轻，因此它们还提供出色的开发人员体验。

  • 使用 平台即服务 解决方案，云提供商将负责处理大部分维护和运营负担。 操作系统（OS）更新、Java 修补程序、安全性和合规性均已提供。 因此，此选项通常更安全且成本更低。 它还附带了一些可伸缩性功能，这应允许应用程序更好地适应客户的需求。 当流量较少时，它还会导致负载下的性能更好，成本更低。

    可以使用 PaaS 解决方案实现更多目标。 可以设置自动配置、管理和加载机密（例如，使用 Azure Key Vault）、监视应用程序、启动实时分析会话并启用零停机时间部署。

部署选项

无论是使用 VM、容器还是 PaaS 解决方案，通常都可以通过以下两种方式之一将 Java 应用程序部署到云：

  • 源代码部署：将源代码提交到 Git 存储库，云提供程序运行一个编译、生成和打包应用程序的过程。
  • JAR、WAR 或 EAR 文件部署：打包应用程序，通常是可执行 JAR（Java ARchive）文件，但 WAR（Web 应用程序 ARchive）、EAR（企业应用程序 ARchive）和其他文件格式也是可能的。 然后，云提供程序运行可执行文件。

这两个部署选项是运行 Java 应用程序的经典方法。 对于这两个选项，生成过程通常相似，主要区别在于该进程在何处运行。 让云提供商进行构建会更简单，采用这种方法，云提供商可以应用自己的安全检查和补丁。 在本地或使用 CI/CD 平台（如 GitHub Actions）生成应用程序，可以获得更大的灵活性和控制。

无服务器函数

无服务器函数（更具体地说是 Azure Functions）是我们所看到的各种解决方案的组合，并提供非常具体的功能：无服务器函数旨在短时间内运行。 通常，函数被某个事件（如 HTTP 请求）唤醒，它会保持“热”几分钟，直到返回到睡眠状态。

Functions 与前面所述的 PaaS 解决方案共享功能。 在 Azure 中，PaaS 解决方案（Azure 应用服务）和无服务器解决方案（Azure Functions）在技术上相似，共享一些常见的代码和服务。

对于部署选项，函数通常使用 JAR 文件。 其他选项（如 Docker）可用，但它们不太受欢迎，通常性能不佳。 这是因为基础平台不能以与 JAR 文件相同的方式对其进行优化。

从本质上讲，无服务器函数需要专门编码。 其功能取决于其运行时间的云提供商，其短暂寿命使得使用传统解决方案（如缓存或 HTTP 会话复制）变得很复杂。

无服务器函数可以很好地扩展，并且它们为低使用环境提供最佳价格。 同时，他们可以响应最苛刻的流量负载。