为 Java 应用程序选择正确的 Azure 服务
本文指导你使用 Azure 服务进行 Java 应用程序部署，强调 Azure 对各种 Java 技术和体系结构的支持。 它概述了部署方法，如“直接迁移”、容器化和平台即服务（PaaS），专为各种控制和简单级别定制。
本文倡导 A+B 思维模式，建议根据应用程序需求选择服务，选择固定 A 或 B 选项。 它建议考虑灵活方法的用例、业务目标、安全性和预算。 本文重点介绍了 Microsoft 与 Java 生态系统领导者的合作关系，以增强开发人员体验，并建议使用 Azure 服务来部署 Java 应用程序，无论是源、二进制文件还是容器。 这种细微差别的方法可帮助你专注于创新，Microsoft 承诺为部署策略提供最合适的 Azure 服务，最大限度地提高效率、可伸缩性和成本效益。
放心部署任何 Java 应用程序
Java 生态系统包括各种技术，如 Java 标准版、Jakarta 企业版（Java 企业版 和 J2企业版 的继任者）、Spring、许多应用程序服务器和其他框架。 无论使用 Java 执行什么操作（例如使用框架生成应用、使用框架和运行应用程序服务器），Azure 支持工作负荷具有丰富的选择。 同样，Azure 支持任何应用程序体系结构-从在 VM 上运行的单体应用程序或容器中运行到在完全托管服务上运行的基于微服务的云原生应用程序。
Azure 提供以下三种主要方法，用于在云中运行 Java 应用程序，专为不同级别的控制和简单性定制：
使用“直接迁移”方法可将现有应用程序直接迁移到 Azure 虚拟机。
容器化提供了灵活性，Azure Kubernetes 服务（AKS）和 Azure Red Hat OpenShift 是协调容器化应用的主要平台。
平台即服务（PaaS）代表了轻松高效的顶峰，提供最佳的开发人员生产力和可操作可管理性，通常加上最经济的总拥有成本。
无论 Java 应用程序开发阶段如何，Azure 都提供兼容的云解决方案来满足你的要求。 可以放心轻松地在部署 Java 应用程序中阅读有关这些产品/服务的详细信息。
Java 应用程序的完整可移植性：在任意位置无缝部署
无论为 Java 应用程序选择哪种 Azure 服务，都保证应用程序的灵活性。 由于 Java 代码及其已编译的输出，因此你可以自由地在任何所需位置部署应用程序-无论是在本地开发计算机上、生成服务器、本地环境还是所选的任何云平台。 应用程序的可移植性掌握在手。
当然，当有很多选择时，你面临着两难境地。
困境 - 将服务 A 或 B 用于 Java 应用程序
如果导航 Azure 的产品/服务，可能会遇到选择最适合用于运行 Java 应用程序的 Azure 服务的两难境地。 此选项至关重要，因为它会影响资源规划、预算、项目时间线，并最终影响应用程序上市的时间。 该决定不仅影响初始部署成本，还影响正在进行的维护费用。
过去，组织通常觉得不得不在两个平台、技术或竞争解决方案之间进行选择，以便将其软件应用程序。 例如，组织必须决定用于 Java Enterprise 应用程序的 WebLogic 或 WebSphere、用于容器管理的 Docker Swarm 或 Kubernetes，或者容器与用于部署的虚拟机（VM）之间做出决定。 此决策过程称为“A 或 B 思维模式”，它与 A/B 测试有很大不同，后者是比较两个版本的网页或应用的方法，以确定哪个版本性能更好。 相反，此上下文中的 A 或 B 思维模式是选择一个平台或技术而不是另一种用于应用程序部署。 它来自传统的本地做法，其中决策通常受打包软件交付模型、对基础结构和软件许可进行大量前期投资等因素的约束，以及生成和部署任何应用程序平台所需的较长潜在客户时间。
将这种心态引入 Azure 可能会导致在创建一个平台时花费过多的时间，这些平台会尝试容纳所有应用程序，从而可能引入延迟和效率低下。 但是，Azure 提供了一种更有利的方法，鼓励从这种限制型思维模式转变为拥抱两个世界最好的模式，最终获得更好的投资回报（ROI）。
在过渡到 Azure 时，云环境提供了一种灵活的范例，你可以根据需要预配和取消预配资源，而无需在一个服务之间选择。 这种灵活性将迎来 A+B 方法，这种策略通过鼓励更广泛的、更具包容性的思维方式，从传统的 A 或 B 思维模式中分离。 Azure 通过简化和经济高效来混合多个服务的优势，并采用 A+B 思维模式，从而促进这种转变。 此方法强调了选择最符合应用程序特定需求的服务的原则，本质上主张为手头作业选择合适的工具。
向 A+B 思维模式的过渡使组织能够扩大其决策流程和技术策略，并采用这种思维模式提供的新可能性和机会。 本文介绍了 A+B 思维模式的原则，使你能够明智地选择最符合应用程序要求的 Azure 服务。 无论是 Azure Spring Apps、Azure App 服务、Azure 容器应用（ACA）、Azure Kubernetes 服务还是虚拟机，A+B 思维模式都授予你用于评估和选择用于托管应用程序的 Azure 服务的数组。 这种理念普遍适用，超越语言和框架边界。 尽管 Java 应用程序是此处的重点，但 A+B 思维模式同样相关，并且对于任何编程语言中开发的应用程序都很有用。
通过采用 A+B 思维模式，你并不局限于一项预先确定的服务。 相反，你有权将服务组合在最适合应用程序的独特需求的方式。 此方法不仅提高了灵活性和可伸缩性，而且优化了成本和运营效率。 此方法可确保你的技术策略与你正在操作的云环境一样动态和适应性。
为什么不需要考虑服务 A 或 B
为应用程序选择合适的云服务不必是服务 A 或服务 B 之间的二进制决策，这要归功于云产品/服务选项的灵活性和广度，尤其是在 Azure 中。 以下部分细分了为什么不必要坚持传统的“一种或另一种”选择，以及采用更流畅的方法如何有利于操作。
从旧习惯到新的灵活性
传统上，部署 IT 系统涉及对硬件和软件的重大前期投资，以及长时间的设置时间。 此环境使它符合逻辑，仔细选择一个平台并优化其周围的一切，以节省成本和资源。 但是，云环境（包括 Azure）引入了一种模式转变，其按需性和弹性性。 只需为使用的内容付费，并调整资源以满足需求就变得简单明了，无需承担初始资本支出的负担。
迁移到云
特别是迁移到云和 Azure，对基础结构和平台责任的管理方式发生了重大变化。 以前由组织承担的大部分繁重工作现在转移到 Microsoft，如下图所示。 此更改简化了操作，减少了管理应用程序所需的工作量。 你不受管理多个平台的约束的约束，无需担心额外的成本和复杂性，即可为每个作业选择最佳工具。
下图显示了客户与云提供商之间的共同责任模型：
选择最适合每种需求
在这个以云为中心的新世界中，决策过程变得更加需要为正确的工作选择适当的工具，而不是尝试将所有需求都纳入一个预先确定的服务。 无论是在 Azure Kubernetes 服务 和 Azure Spring Apps for Spring Boot 应用程序还是任何其他服务之间进行选择，焦点都会转向最符合每个特定应用程序的要求。
微服务的兴起
微服务的采用进一步支持这种灵活的方法。 根据设计， 微服务 鼓励为每个服务使用最适合的技术，促进与 A+B 思维模式自然一致的技术多样性。 此方法是使用不同服务的优势来构建更可靠、更高效且可缩放的应用程序体系结构。
采用 A+B 的好处
采用 A+B 思维模式提供了几个关键优势。 它可实现更大的灵活性和灵活性，使你可以为操作的每个方面选择最合适的工具和服务。 这种方法不仅能提高资源和成本效益，而且缩短了产品上市时间。 归根结底，此方法通过更紧密地符合业务需求和目标，从而促进运营卓越。
总之，云和 Azure 特别提供了部署和管理应用程序的新方法。 通过摆脱严格的 A 或 B 选择并采用 A+B 思维模式，可以做出更符合应用程序特定需求的决策，从而提高效率、敏捷性和成本节省。
过渡到 A+B 思维模式的实践指南
以下列表列举了一些关键原则，这些原则可以用作过渡到 A+B 思维模式并继续学习的准则：
从用例到解决方案，而不是另一种方式。 通常，许多软件团队首先决定技术，然后尝试强制调整用例和设计。 在许多情况下，此方法在成本、开发时间、资源和运营费用方面会产生重大开销。 在跳转到解决方案之前，请明确用例和要求（无论是功能还是非功能）。
了解业务目标、业务的性质和竞争，以及向生产推出新功能的频率。 应始终设计解决方案以满足业务目标和目标。
了解安全性和合规性要求。 在云时代，通过 Internet 访问所有内容时，安全性至关重要且不可谈判。 此外，根据你提供服务的行业，应用程序可能需要满足某些合规性要求。 必须设计解决方案来应对高级安全攻击，并满足合规性要求。
了解预算和时间线。 清楚地了解初始开发、持续运营和未来版本的预算。 此外，请了解时间线。 延迟项目的成本，无论是额外的开支和负面的业务影响，往往被低估。 设计解决方案以满足预算和时间线。
考虑云原生（如果适用）。 云原生体系结构和技术是一种方法，用于设计、构造和操作在云中构建并充分利用云计算模型的工作负载。 使用云原生，可以更快地生成应用程序并将其部署到生产环境。 云还提供在本地可能无法实现的功能，例如弹性、全球规模、高级分析、AI 和机器学习（ML）功能。 尽可能多地基于云原生技术设计解决方案。
思考 DevOps 文化。 DevOps 不仅仅是工具或流程，它是一种软件开发实践，可促进开发和操作之间的协作，从而更快、更可靠的软件交付。 DevOps 通常称为区域性，它连接人员、流程和技术以提供持续价值。
选择满足业务和非功能要求的解决方案，即：
- 实现速度最快。
- 在技能、构建、部署和运营所涉及的成本方面，经济高效。
- 易于操作。
- 与自动化完全兼容。
- 按设计支持 DevOps。
这些原则可帮助你专注于构建满足业务目标的解决方案，而不是强制将解决方案拟合到预先确定的平台。
异常
与任何其他情况一样，A+B 也有例外情况。 以下列表并不详尽，但它提供了有关可能遇到的某些异常的定向指南：
企业策略。 例如，一些企业使用企业范围的容器来生成和部署应用程序，因为它们可能具有多种编程语言，他们希望以统一的方式生成和部署所有应用程序。
与执行一行相去甚远。 在完成 A+B 分析之前，可能已选择解决方案。 如果已深入执行解决方案，请继续执行该解决方案，但对于下一个应用程序，请使用 A+B 思维模式的原则为用例选择正确的解决方案。
大规模数据中心迁移。 为了加速云之旅，企业通常使用一种称为“直接迁移”的策略，该策略涉及使用 Azure Migrate 等工具批量将服务器（托管其应用程序）迁移到 Azure。 有些人使用此方法将数据中心迁移到 Azure，并以高效且经济高效的方式将其关闭。 在此方案中，我们建议在迁移到 Azure 后使用 A+B 思维模式实现应用程序的现代化。
重要注意事项
我们为你提供了用于思考的框架和可用于为应用程序选择 Azure 中正确目标的原则。 它不是一个适合所有的大小。 它不是 A 或 B，而是 A + B。
下图总结了为任何应用程序选择 Azure 服务的关键注意事项：
如何为 Java 应用程序选择正确的 Azure 服务
为了简化 Azure 上 Java 应用程序的众多技术选项中的选择过程，我们创建了一个简单的决策树，帮助开发人员、客户和系统集成商实现其最佳 Azure 服务。
除了从技术角度考虑非功能性要求的实际指导之外，需要考虑的初始问题是是否需要对基础结构的控制。 如果没有，托管服务是最佳、最建议的路由。 应用程序的性质（无论是基于 Spring 还是基于应用服务器）进一步指导决策：Spring 应用程序与 Azure Spring Apps 保持一致，而Azure App 服务适合 Tomcat 或 JBoss EAP 应用程序。
对于需要基础结构控制的人来说，选择取决于多云技术偏好：Azure 虚拟机提供简单的过渡，对于与 Tanzu 集成的用户，IaaS 市场产品/服务的 Tanzu 是理想的选择。 投资 Kubernetes 的客户可以选择Azure Kubernetes 服务和 Azure Red Hat OpenShift。 此决策框架旨在通过将客户需求与 Azure 最适合的解决方案配对来简化选择。
Microsoft 与众多合作伙伴协作，包括以下领域的合作伙伴：
- 领先的 Java 生态系统合作伙伴，如 Oracle、Broadcom、Red Hat、IBM 和 OpenAI。
- 关键数据库和工具组织，如 MySQL、PostgreSQL、MongoDB 实验室、DataStax、Redis 实验室、Confluent 和 Elastic。
- 可观测性专家，如 New Relic、Dynatrace、AppDynamics、Grafana Labs 和 Datadog。
- 开发工具，如 IntelliJ、Maven 和 Gradle。
我们的综合投资用于打造更流畅的开发人员体验，确保与数据库、缓存、消息传递和目录等基本服务无缝集成，并提供全面的可观测性工具。 通过自动化、负载均衡和自动缩放，我们的目标是减轻基础结构管理负担。 借助此支持，你可以专注于通过代码创造业务价值，并确信基础系统是可靠且可缩放的。 出于这些原因，我们建议使用特定的 Azure 服务来托管和运行 Java 应用程序类型。
将 Java 应用程序部署为源或二进制文件
对于 Azure 上的 Java 应用程序，无论是直接从源代码部署还是作为已编译的二进制文件（JAR、WAR 或 EAR 文件）进行部署，都简化了部署，这要归功于专为这些目的设计的 Azure 综合服务产品。 Java 应用程序的固有可移植性意味着 Azure 可以提供广泛的服务，以满足独特的部署策略和运营需求。 这种灵活性可确保无论 Java 应用程序的具体细节如何，都有一个完全符合要求的 Azure 服务。
请考虑以下三个示例，其中展示了 Azure 如何适应不同的 Java 应用程序部署方案：
Spring Applications。 对于使用 Spring 应用程序的开发人员，Microsoft Azure 与 Spring 开源项目领导者 Tanzu 合作，提供名为 Azure Spring Apps 的顶级云服务。 此协作通过将常用的开发工具（如 IntelliJ、VS Code、Maven 和 Gradle）与 Azure DevOps、GitHub Actions 和 Jenkins 等自动化工具集成，从而增强开发人员体验。 还支持 Application Insights、New Relic、Dynatrace、App Dynamics、Grafana、Log Analytics、Elastic 和 Splunk 等可观测性工具。 安全性是重中之重，与处理机密和 TLS/SSL 证书的 密钥库集成、通过托管标识通过支持服务的“无密码”身份验证以及 Azure 基于角色的访问控制（RBAC），确保云中 Spring 应用的安全简化部署过程。
JBoss EAP 上的 Java 应用程序。 同样，对于使用 JBoss EAP 的 Java 应用程序，由于 Microsoft Azure 团队与 Red Hat JBoss EAP 团队之间的协作，提供了定制体验。 这种合作关系增强了对Azure App 服务的支持，为 JBoss EAP 应用程序提供了一组丰富的功能。 借助此支持，可以使用 Microsoft 和 Red Hat 的组合专业知识，确保 Java 应用程序在 Azure 上顺利、安全高效地运行。
WebLogic 上的企业 Java 应用程序。 在 Oracle WebLogic 上运行的传统企业 Java 应用程序也有 Azure 的专用路径。 Microsoft Azure 与 Oracle WebLogic 团队之间的协作为 Azure 虚拟机 上的优化部署铺平了道路。 这种合作关系扩展到与基本的 IaaS 功能（例如虚拟机、存储、网络和负载均衡器）集成，为 Azure 上的企业 Java 应用程序提供了坚实的基础。 这种协调努力可确保应用程序受益于 WebLogic 的可靠性和 Azure 基础结构的可伸缩性和灵活性。
这些方案突出了 Azure 致力于为 Java 应用程序提供灵活、安全且高效的部署环境，满足各种框架和体系结构的需求。 Azure 还为其他 Java 应用程序（例如 Tomcat 或 WebSphere 上运行的应用程序）提供专用服务，确保有一个适合每种 Java 应用程序的 Azure 服务。
开发人员和操作员通过使用这些定制的 Azure 服务，轻松自动化和保护其 Java 应用程序，从而获得流畅高效的云部署体验。 但是，选择替代部署选项可能需要你自行处理这些基本开发人员和操作员体验的生成和维护。
下图显示了作为源或二进制文件部署的每个 Java 应用程序类型的推荐 Azure 服务：
若要详细了解此图中引用的服务，请使用下表中的链接：
将 Java 应用程序部署为容器
在部署 Java 应用程序方面，容器化表示一种尖端方法，可增强跨企业的容器创建、管理和治理的自动化。 挑战在于安全可靠地构建容器，这是快速交付高质量容器化软件应用程序的关键步骤。 此过程可以从头开始或使用现有的容器系统，集成编译和存储代码和二进制文件的工具，以简化容器更新和管理。 这种集成对于适应持续集成/持续部署（CI/CD）管道至关重要，以容器形式为 Java 应用程序提供灵活的部署方法。
Azure 服务不仅缓解了容器化应用程序的交付，而且还提供了从源或二进制文件部署的明确路径。 这种双重方法最大限度地减少了对开发人员的影响，并减轻了基础结构或平台操作员的负载。 鉴于 Java 固有的可移植性，Azure 广泛选择的容器服务可确保找到与部署策略和需求的完美匹配项。
请考虑以下两个示例，其中展示了 Azure 如何满足容器化 Java 应用程序部署方案的需求：
Spring Applications。 Azure Spring Apps 是容器化 Spring 应用程序的极佳选择。 它支持多种部署类型，包括源、二进制文件或容器映像。 这种灵活性使你可以轻松地在部署方法之间进行切换。 可以从容器开始，但后来决定部署为源或二进制文件。 此选项是有利的，因为它避开了持续构建和维护容器的需求，这可能会很繁琐、重复性和时间密集型。
Tomcat 上的 Java 应用程序。 Azure App 服务适用于容器化旨在在 Tomcat 上运行的 Java 应用程序。 它容纳各种部署类型，例如二进制文件或容器映像。 与 Azure Spring Apps 一样，此服务提供在部署策略之间切换的灵活性。 可以从容器部署开始，并保留以后切换到部署二进制文件（WAR 和 JAR）的选项。 这种多功能性可确保为特定方案选择最有效的部署方法，简化开发和部署过程。
这些示例突显了 Azure 承诺，无论是通过传统方法还是新式容器化，都致力于为部署 Java 应用程序提供通用、高效和开发人员友好的环境。
下图显示了部署为容器的每个 Java 应用程序类型的推荐 Azure 服务：
若要详细了解此图中引用的服务，请使用下表中的链接：
总结
在部署 Java 应用程序时，Azure 支持一种细微差别的 A+B 方法，提供一系列专为满足每个应用程序需求而定制的服务。 Microsoft 与 Java 生态系统领导者的协作导致一套 Azure 服务，每个服务都建议用于特定的 Java 应用程序类型（部署为源、二进制文件或容器），从而简化部署过程并确保最佳性能。 这侧重于将部署策略与最合适的 Azure 服务匹配，这突显了 Microsoft 致力于提供为作业选择合适的工具的灵活性。 Java 应用程序的固有可移植性是一个关键优势，可实现跨本地系统和不同云提供商的无缝过渡，以提高运营效率和敏捷性。 通过倡导这一更广泛的、更具包容性的选择过程，Microsoft 不仅简化了 Java 应用程序的云旅程，而且最大限度地提高了可伸缩性、安全性、可观测性和成本效益。 最终，Microsoft 的指导使开发人员和企业能够使用 Azure 的生态系统，确保每个 Java 应用程序在最适合其需求的云环境中茁壮成长。
下一步
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈