应用程序部署类型
可以通过多种方式将 Java 应用程序部署到云。 本单元探讨各种选项，以便在下一个单元中，你可以更好地了解 Azure 提供的服务。
虚拟机、容器或平台即服务？
主要问题是，你是否想要或需要在虚拟机 (VM) 上、在容器内或作为平台即服务 (PaaS) 解决方案部署应用程序。
使用虚拟机，你所处的环境类似于本地或经典数据中心环境。 Azure 提供一组预配置的 VM，这些 VM 运行主操作系统（Windows 和 Linux），并且你需要配置和维护这些虚拟机。
我们建议你首先采用此解决方案，因为它最接近大多数企业在迁移到云之前已经在使用的解决方案。 他们通常会安装自己的配置管理软件，安装他们最喜欢的 Java 版本，然后能够以与过去类似的方式运行 Java 工作负载。
如果你有一支经验丰富的运营团队来配置和维护 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 存档）文件，但也能够以 WAR（Web 应用程序存档）、EAR（企业应用程序存档）和其他文件格式进行打包。 然后，云提供商运行可执行文件。
这两个部署选项是运行 Java 应用程序的经典方法。 对于这两个选项，生成过程通常都是相似的，主要区别在于运行进程的位置。 让云提供商执行生成会更简单，并且通过这种方法，云提供商将应用自己的安全检查和修补程序。 通过在本地生成应用程序或通过使用 GitHub Actions 等 CI/CD 平台，你可获得更大的灵活性和控制力。
无服务器函数
无服务器函数（更具体地说是 Azure Functions）是我们所见到的不同解决方案的混合，提供一项非常特殊的特性：无服务器函数旨在运行一小段时间。 通常情况下，某个函数通过事件（如 HTTP 请求）唤醒，只在几分钟内保持“热”状态，之后它重新进入休眠状态。
Functions 与我们前面介绍的 PaaS 解决方案共享功能。 在 Azure 中，我们的 PaaS 解决方案（Azure 应用服务）和我们的无服务器解决方案 (Azure Functions) 在技术上很接近，它们共享一些常见的代码和服务。
对于部署选项，Functions 通常使用 JAR 文件。 可以使用其他选项（如 Docker），但这些选项不太常用，通常效果也不佳。 这是因为基础平台无法像优化 JAR 文件那样对它们进行优化。
从本质上讲，无服务器函数需要专门进行编码。 它们的功能取决于运行它们的云提供商，并且它们较短的生命周期使得使用传统解决方案（如高速缓存或 HTTP 会话复制）变得复杂。
无服务器函数可以很好地进行缩放，并为低使用量环境提供最优价格。 同时，它们能够应对要求最高的流量负载。