你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

适用于 Java 的可靠 Web 应用模式

本文提供了实现 Reliable Web App 模式的指导。此模式描述如何重新创建用于云迁移的 Web 应用。它提供符合 Azure Well-Architected 框架原则的规范性体系结构、代码和配置指南。

为什么使用适用于 Java 的 Reliable Web 应用模式？

Reliable Web App 模式是一组原则和实现技术，用于定义在将 Web 应用迁移到云时如何重新构建 Web 应用。它强调最少的代码更新，以确保在云中取得成功。本指南在整个过程中使用参考实现作为一致的示例。它遵循虚构公司 Contoso Fiber 的重塑平台过程，从而为您自己的迁移提供业务背景。在 Contoso Fiber 实现适用于 Java 的可靠 Web 应用模式之前，它会运行使用 Spring Boot 框架构建的单体本地客户帐户管理系统（CAMS）。

小窍门

GitHub 徽标。 Reliable Web App 模式的引用实现（示例）表示已完成实现的最终状态。此生产级 Web 应用包括本文中所述的所有代码、体系结构和配置更新。部署和使用参考实现来帮助指导自己实现 Reliable Web App 模式。

如何实现可靠的 Web 应用程序模式

在本文的以下部分中查找所需的特定指南：

业务上下文：使本指南与业务上下文保持一致，并了解如何定义推动重新制定决策的即时和长期目标。
体系结构指南：选择适当的云服务并设计满足业务需求的体系结构。
代码指南：实现重试、断路器和 Cache-Aside 设计模式，以提高云中 Web 应用的可靠性和性能效率。
配置指南：配置身份验证和授权、托管标识、权限化环境、基础结构即代码（IaC）和监视。

业务上下文

重新构建 Web 应用的第一步是定义业务目标。设置即时目标，例如服务级别目标（SLO）和成本优化目标，以及 Web 应用程序的未来目标。这些目标会影响你选择的云服务和云中应用程序的体系结构。为 Web 应用定义目标 SLO，例如 99.9% 运行时间。计算影响 Web 应用可用性的所有服务的复合服务级别协议（SLA ）。

Contoso Fiber 希望扩展其本地 CAMS Web 应用以访问其他区域。为了满足对 Web 应用的需求增加，公司确定了以下目标：

应用低成本、高价值代码更改。
达到 99.9%的 SLO。
采用 DevOps 做法。
创建成本优化的环境。
提高可靠性和安全性。

Contoso Fiber 确定其本地基础结构不是用于缩放应用程序的经济高效的解决方案。该公司决定将 CAMS Web 应用程序迁移到 Azure 是实现其即时和未来目标的最经济高效的方法。

体系结构指南

Reliable Web App 模式具有一些基本的体系结构元素。需要域名系统（DNS）来管理终结点解析、用于阻止恶意 HTTP 流量的 Web 应用程序防火墙和负载均衡器来路由并帮助保护入站用户请求。应用程序平台托管 Web 应用代码，并通过虚拟网络中的专用终结点调用后端服务。应用程序性能监视工具捕获指标和日志，以帮助了解 Web 应用。

设计体系结构

设计基础结构以支持恢复指标，例如恢复时间目标（RTO）和恢复点目标（RPO）。 RTO 会影响系统的可用性，并且必须符合您的服务级别目标（SLO）。确定 RPO 并配置数据冗余以满足 RPO。

选择基础结构可靠性。 确定满足可用性要求所需的可用性区域和区域数。添加可用区和区域，直到综合 SLA 达到您的 SLO。 Reliable Web App 模式支持多个区域用于主动-主动或主动-被动配置。例如，参考实现使用主动-被动配置来满足 SLO 的 99.9%。

对于多区域 Web 应用，请将负载均衡器配置为将流量路由到第二个区域，以支持主动-主动或主动-被动配置，具体取决于业务需求。这两个区域需要相同的服务。但一个区域有一个连接区域的中心虚拟网络。采用中心辐射型网络拓扑来集中和共享资源，例如网络防火墙。如果有虚拟机（VM），请将堡垒主机添加到中心虚拟网络，以增强安全性来管理它们。

此图显示了通过中心辐射型网络拓扑扩展的 Reliable Web App 模式，以支持多区域部署。该体系结构包括两个 Azure 区域，每个区域都有自己的一组 Web 应用资源和后端服务。用户请求由 DNS 解析，并通过全局负载均衡器进行输入，该负载均衡器根据可用性将流量定向到主要区域或次要区域。每个区域都包含一个 Web 应用程序防火墙和一个负载均衡器，用于保护请求并将其分发到 Web 应用程序平台。这两个区域中的 Web 应用使用各自虚拟网络中的专用终结点连接到后端服务，例如数据库和存储。中心虚拟网络存在于一个区域中，包含共享资源，例如网络防火墙和堡垒主机，用于安全管理 VM。分支虚拟网络托管应用程序和数据服务，并连接到中心进行集中的安全和管理。该图演示了用户请求流、公共和专用网络边界的分离、安全控制的使用，以及跨多个区域部署资源提供的冗余。
选择网络拓扑。 为 Web 和网络要求选择正确的网络拓扑。如果计划使用多个虚拟网络，请使用中心辐射型网络拓扑。它为本地和虚拟网络提供成本、管理和安全等方面的优势，并提供混合连接选项。

选择正确的 Azure 服务

将 Web 应用移动到云时，请选择满足业务需求的 Azure 服务，并符合本地 Web 应用的功能。这种对齐方式有助于最大程度地减少重新调整工作。例如，使用允许保留相同数据库引擎并支持现有中间件和框架的服务。

在迁移之前，Contoso Fiber 的 CAMS Web 应用是一个本地整体 Java 应用程序。它是具有 PostgreSQL 数据库的 Spring Boot 应用。 Web 应用是员工的业务线（LOB）支持应用。他们使用它来管理客户支持案例。应用在可伸缩性和功能部署方面遇到常见挑战。这一起点以及业务目标和 SLO 会影响其服务选择。

以下列表提供了为 Web 应用选择合适的 Azure 服务的指导，并介绍了 Contoso Fiber 为何选择特定服务：

应用程序平台： 使用 Azure 应用服务作为应用程序平台。 Contoso Fiber 出于以下原因使用应用服务：
- 自然进展： Contoso Fiber 在其本地服务器上部署 Spring Boot JAR 文件，并希望最大程度地减少该部署模型的重新架构量。应用服务提供可靠的支持来运行 Spring Boot 应用，这使得它成为一个合适的选项。 Azure 容器应用也是此应用程序的合适选项。有关详细信息，请参阅容器应用概述和容器应用上的 Java 概述。
- 高 SLA： 应用服务提供满足生产要求的高 SLA。
- 减少了管理开销： 应用服务是托管解决方案。
- 容器化功能： 应用服务与专用容器映像注册表（如 Azure 容器注册表）集成。 Contoso Fiber 可以使用这些注册表在未来容器化 Web 应用。
- 自动缩放： Web 应用可以根据用户流量快速纵向扩展、纵向缩减、缩小和横向扩展。
标识管理： 使用 Microsoft Entra ID 作为标识和访问管理解决方案。 Contoso Fiber 出于以下原因使用 Microsoft Entra ID：
- 身份验证和授权： 应用程序需要对呼叫中心员工进行身份验证和授权。
- 可伸缩性： Microsoft Entra ID 缩放以支持更大的方案。
- 用户标识控件： 呼叫中心员工可以使用其现有的企业标识。
- 授权协议支持： Microsoft Entra ID 支持托管标识的 OAuth 2.0。
数据库： 使用允许保留相同数据库引擎的服务。使用数据存储决策树指导选择。 Contoso Fiber 出于以下原因使用 Azure Database for PostgreSQL 灵活服务器部署模型：
- 可靠性： 灵活服务器部署模型支持跨多个可用性区域的区域冗余高可用性。此配置维护同一 Azure 区域中不同可用性区域中的热备用服务器。配置将数据同步复制到备用服务器。
- 跨区域复制： Azure Database for PostgreSQL 提供只读副本功能，用于将数据异步复制到另一区域中的只读副本数据库。
- 性能： Azure Database for PostgreSQL 提供可预测的性能和智能优化，使用实际使用情况数据提高数据库性能。
- 减少了管理开销： 此托管的 Azure 服务减少了管理义务。
- 迁移支持： 它支持从本地单服务器 PostgreSQL 数据库进行数据库迁移。 Contoso Fiber 可以使用迁移工具简化迁移过程。
- 与本地配置的一致性： 它支持 PostgreSQL 的不同社区版本，包括 Contoso Fiber 当前使用的版本。
- 弹性： 灵活服务器部署会自动创建服务器备份，并将其存储在同一区域中的区域冗余存储（ZRS）。 Contoso Fiber 可以将数据库还原到备份保留期内的任何时间点。与本地环境相比，备份和还原功能可创建更好的 RPO。
应用程序性能监视： 使用 Application Insights 分析应用程序中的遥测数据。 Contoso Fiber 出于以下原因使用 Application Insights：
- 与 Azure Monitor 集成： 它提供与 Azure Monitor 的最佳集成。
- 异常情况检测： 它会自动检测性能异常。
- 故障排除： 它有助于诊断正在运行的应用中的问题。
- 监测： 它收集应用的使用情况数据并跟踪自定义事件。
- 可见性差距： 本地解决方案没有应用程序性能监视解决方案。 Application Insights 提供与应用程序平台和代码的轻松集成。
缓存： 选择是否将缓存添加到 Web 应用体系结构。 Azure 托管 Redis 是主要的 Azure 缓存解决方案。它是基于 Redis 软件的内存中托管数据存储系统。 Contoso Fiber 出于以下原因添加了 Azure 托管 Redis：
- 速度和音量： 它为经常访问、变化缓慢的数据提供高数据吞吐量和低延迟读取。
- 各种可支持性： 它是 Web 应用的所有实例都可以使用的统一缓存位置。
- 外部数据存储： 本地应用程序服务器使用 VM 本地缓存。此设置不会卸载经常访问的数据，并且无法使过时的数据失效。
- 非粘性会话： 缓存允许 Web 应用外部化会话状态并使用非粘性会话。大多数在本地运行的 Java Web 应用都依赖于内存中客户端缓存。此方法无法很好地缩放，并增加主机上的内存占用量。 Azure 托管 Redis 提供托管的可缩放缓存服务，以提高应用程序的可伸缩性和性能。 Contoso Fiber 使用 Spring Cache 作为其缓存抽象框架，只需进行最少的配置更改即可从 Ehcache 提供程序切换到 Redis 提供程序。
负载均衡器： 使用平台即服务（PaaS）解决方案的 Web 应用程序应使用 Azure Front Door、Azure 应用程序网关或两者，具体取决于 Web 应用体系结构和要求。使用负载均衡器决策树选择正确的负载均衡器。 Contoso Fiber 需要一个第 7 层负载均衡器，可以跨多个区域和多区域 Web 应用路由流量，以满足 SLO 的 99.9%。公司出于以下原因使用 Azure Front Door ：
- 全局负载均衡： 此第 7 层负载均衡器可以跨多个区域路由流量。
- Web 应用程序防火墙： 它与 Azure Web 应用程序防火墙进行了原生集成。
- 路由灵活性： 它允许应用程序团队配置入口需求，以支持应用程序中未来的更改。
- 流量加速： 它使用任播路由到达最近的 Azure 接入点，并找到通往 Web 应用的最快路径。
- 自定义域： 它支持具有灵活域验证的自定义域名。
- 运行状况探测： 应用程序需要智能运行状况探测监控。 Azure Front Door 使用来自探测的响应来确定路由客户端请求的最佳来源。
- 监视支持： Azure Front Door 支持内置报表，其中包含适用于 Azure Front Door 和安全模式的一个全能仪表板。它提供与 Azure Monitor 集成的警报。 Azure Front Door 允许应用程序记录每个请求和失败的健康探测。
- 分布式拒绝服务（DDoS）保护： 它在第 3 层和第 4 层具有内置的 DDoS 防护。
- 内容分发网络： 这使 Contoso Fiber 准备好使用内容分发网络。内容分发网络提供站点加速。
Web 应用程序防火墙： 使用 Azure Web 应用程序防火墙提供集中保护，防止常见的 Web 攻击和漏洞。 Contoso Fiber 出于以下原因使用 Azure Web 应用程序防火墙：
- 全局保护： 它提供了改进的全局 Web 应用保护，同时保持性能。
- 僵尸网络保护： 团队可以监视和配置设置，以解决与僵尸网络相关的安全问题。
- 与本地部署保持一致： 本地部署解决方案在由 IT 管理的 Web 应用防火墙后运行。
- 易于使用： Azure Web 应用程序防火墙与 Azure Front Door 集成。
机密管理器： 如果有机密可在 Azure 中管理，请使用 Azure Key Vault 。 Contoso Fiber 出于以下原因使用 Key Vault：
- 加密： 它支持静态加密和传输中加密。
- 托管标识支持： 应用程序服务可以使用托管标识访问机密存储。
- 监视和日志记录： Key Vault 有助于审核访问，并在存储的机密更改时生成警报。
- 集成： Key Vault 提供与 Azure 配置存储（Azure 应用配置）和 Web 托管服务（应用服务）的本机集成。
终结点安全性： 使用 Azure 专用链接通过虚拟网络中的专用终结点访问 PaaS 解决方案。虚拟网络与服务之间的流量通过Microsoft主干网络传输。 Contoso Fiber 出于以下原因使用专用链接：
- 增强的安全性通信： 它允许应用程序在 Azure 平台上私下访问服务，并减少数据存储的网络占用，以帮助防止数据泄露。
- 最少工作量： 专用终结点支持 Web 应用平台和 Web 应用使用的数据库平台。这两个平台都镜像了现有的本地配置，因此需要最少的更改。
网络安全： 使用 Azure 防火墙控制网络级别的入站和出站流量。使用 Azure Bastion 连接到具有增强安全性的 VM，而无需公开远程桌面协议/安全外壳（RDP/SSH）端口。 Contoso Fiber 采用中心辐射型网络拓扑，并将共享网络安全服务置于中心。 Azure 防火墙检查分支的出站流量，以增强网络安全。该公司使用 Azure Bastion 从 DevOps 子网中的跳转主机进行增强安全性部署。

代码指南

若要成功将 Web 应用移动到云，需要使用重试、断路器和 Cache-Aside 模式更新 Web 应用代码。

这些设计模式提供与 Well-Architected 框架中的一个或多个支柱相对应的工作负载效益：

重试模式通过对可能间歇性失败的操作重试来处理暂时性故障。在所有对其他 Azure 服务的出站调用上实现此模式。
断路器模式 可防止应用程序重试那些不是暂时性失败的操作。在所有对其他 Azure 服务的出站调用中实现此模式。
Cache-Aside 模式 按需将数据从数据存储加载到缓存中。针对对数据库的请求实现此模式。

设计模式	可靠性（RE）	性能效率（PE）	支持 WAF 原则
重试模式	✔		RE：07
断路器模式	✔	✔	RE：03 RE：07 PE：07 PE：11
旁路缓存模式	✔	✔	RE：05 体育：08 PE：12

实现重试模式

将重试模式添加到应用程序代码，以解决临时服务中断问题。这些中断称为 暂时性故障。暂时性故障通常在几秒钟内自行解决。可以使用重试模式重新发送失败的请求。它还允许您配置重试之间的延迟以及在放弃失败之前的尝试次数。

使用 Resilience4j（轻型容错库）在 Java 中实现重试模式。若要添加重试模式，参考实现使用重试注解来修饰服务计划控制器 listServicePlans 的方法。如果初始调用失败，该代码将重试对数据库中的服务计划列表的调用。引用实现的重试策略包括重试的最大尝试次数、等待持续时间和异常。在 application.properties 文件中配置重试策略。

    @GetMapping("/list")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    @CircuitBreaker(name = SERVICE_PLAN)
    @Retry(name = SERVICE_PLAN)
    public String listServicePlans(Model model) {
        List<serviceplandto> servicePlans = planService.getServicePlans();
        model.addAttribute("servicePlans", servicePlans);
        return "pages/plans/list";
    }

实现断路器设计模式

使用断路器模式来处理那些不是暂时性故障的服务中断。断路器模式可防止应用程序持续尝试访问非响应服务。它释放应用程序资源，并帮助防止浪费中央处理单元（CPU）周期，从而使应用程序保持其性能的完整性，为用户提供良好的使用体验。

使用 Spring Cloud Circuit Breaker 和 Resilience4j 实现断路器模式。参考实现通过将方法与断路器特性结合来应用断路器模式。

实现 Cache-Aside 模式

将 Cache-Aside 模式添加到 Web 应用以提高内存中数据管理。该模式为应用程序分配了处理数据请求的责任，并确保缓存和持久性存储（例如数据库）之间的一致性。它缩短响应时间，提高吞吐量，减少对更多缩放的需求。它还减少了主数据存储上的负载，从而提高可靠性和成本优化。若要实现 Cache-Aside 模式，请遵循以下建议：

将应用程序配置为使用缓存。 若要启用缓存，请将 spring-boot-starter-cache 包添加为文件中的依赖项 pom.xml 。此包为 Redis 缓存提供默认配置。
缓存高需求数据。 对高需求数据应用 Cache-Aside 模式以提高其有效性。使用 Azure Monitor 跟踪数据库的 CPU、内存和存储。这些指标有助于确定应用 Cache-Aside 模式后是否可以使用较小的数据库 SKU。若要在代码中缓存特定数据，请添加 @Cacheable 批注。此批注指定 Spring 中应缓存其结果的方法。
保持缓存数据新鲜。 计划定期缓存更新，以便与最新的数据库更改同步。根据数据的波动性和用户需求确定最佳刷新率。这种做法可确保应用程序使用 Cache-Aside 模式提供快速访问和当前信息。默认缓存设置可能不适合 Web 应用程序。可以在 application.properties 文件或环境变量中自定义这些设置。例如，可以修改 spring.cache.redis.time-to-live 值（以毫秒为单位），以控制数据在删除之前应保留在缓存中的时长。
确保数据一致性。 实现在数据库写入作后立即更新缓存的机制。使用事件驱动的更新或专用数据管理类来确保缓存一致性。将缓存与数据库修改一致同步是 Cache-Aside 模式的核心。

配置指南

以下部分提供有关如何实现配置更新的指导。每个部分都与 Well-Architected 框架中的一个或多个支柱相对应。

配置	可靠性（RE）	安全性（SE）	成本优化（CO）	卓越运营（OE）	性能效率（PE）	支持 WAF 原则
配置用户身份验证和授权		✔		✔		SE:05 OE:10
实现托管标识		✔		✔		SE:05 OE:10
优化环境			✔			CO：05 CO：06
实现自动扩展	✔		✔		✔	RE：06 CO：12 体育：05
自动化资源部署				✔		OE:05
实现监视			✔	✔	✔	OE:07 体育：04

配置用户身份验证和授权

将 Web 应用程序迁移到 Azure 时，请配置用户身份验证和授权机制。遵循以下建议：

使用标识平台。 使用开发人员Microsoft标识平台设置 Web 应用身份验证。此平台支持使用单个 Microsoft Entra 目录、来自不同组织的多个 Microsoft Entra 目录以及Microsoft标识或社交帐户的应用程序。

[适用于 Microsoft Entra ID 的 Spring Boot Starter]（/azure/developer/java/spring-framework/spring-boot-starter-for-entra-developer-guide 使用 Spring Security 和 Spring Boot 来确保轻松配置和集成。它提供各种身份验证流、自动令牌管理、可自定义的授权策略以及 Spring Cloud 组件的集成功能。此工具支持直接Microsoft Entra ID 和 OAuth 2.0 集成到 Spring Boot 应用程序中，而无需手动库或设置配置。

引用实现使用 Microsoft 标识平台（Microsoft Entra ID）作为 Web 应用的标识提供者。它使用 OAuth 2.0 授权代码授予登录具有 Microsoft Entra 帐户的用户。以下 XML 代码片段定义了 OAuth 2.0 授权代码授予流的两个必需依赖项。该依赖项 com.azure.spring: spring-cloud-azure-starter-active-directory 在 Spring Boot 应用程序中启用Microsoft Entra 身份验证和授权。 org.springframework.boot: spring-boot-starter-oauth2-client依赖项在 Spring Boot 应用程序中启用 OAuth 2.0 身份验证和授权。
```
<dependency>
    <groupid>com.azure.spring</groupid>
    <artifactid>spring-cloud-azure-starter-active-directory</artifactid>
</dependency>
<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-oauth2-client</artifactid>
</dependency>
```

创建应用程序注册。 Microsoft Entra ID 要求在主租户中注册应用程序。应用程序注册有助于确保有权访问 Web 应用的用户在主租户中具有标识。参考实现使用 Terraform 创建 Microsoft Entra ID 应用程序注册和应用程序特定的账户管理角色。

resource "azuread_application" "app_registration" {
  display_name     = "${azurecaf_name.app_service.result}-app"
  owners           = [data.azuread_client_config.current.object_id]
  sign_in_audience = "AzureADMyOrg"  # single tenant

  app_role {
    allowed_member_types = ["User"]
    description          = "Account Managers"
    display_name         = "Account Manager"
    enabled              = true
    id                   = random_uuid.account_manager_role_id.result
    value                = "AccountManager"
  }
}

在应用程序中强制实施授权。 使用基于角色的访问控制（RBAC）将最小特权分配给应用程序角色。为不同用户定义特定角色，以避免角色重叠并确保职责清晰。将用户映射到相应的角色，并确保他们仅有权访问必要的资源和操作。将 Spring Security 配置为将 Spring Boot Starter 用于 Microsoft Entra ID。此库支持与 Microsoft Entra ID 的集成，并帮助确保用户安全进行身份验证。配置并启用Microsoft身份验证库（MSAL），以访问更多安全功能。这些功能包括令牌缓存和自动令牌刷新。

参考实现创建了应用角色，这些角色反映了 Contoso Fiber 帐户管理系统中用户角色类型。角色在授权期间转换为权限。 CAMS 中特定于应用的角色的示例包括客户经理、一级（L1）支持代表和现场服务代表。帐户管理员角色有权添加新的应用用户和客户。现场服务代表可以创建支持票证。该 PreAuthorize 属性限制对特定角色的访问。

    @GetMapping("/new")
    @PreAuthorize("hasAnyAuthority('APPROLE_AccountManager')")
    public String newAccount(Model model) {
        if (model.getAttribute("account") == null) {
            List<ServicePlan> servicePlans = accountService.findAllServicePlans();
            ServicePlan defaultServicePlan = servicePlans.stream().filter(sp -> sp.getIsDefault() == true).findFirst().orElse(null);
            NewAccountRequest accountFormData = new NewAccountRequest();
            accountFormData.setSelectedServicePlanId(defaultServicePlan.getId());
            model.addAttribute("account", accountFormData);
            model.addAttribute("servicePlans", servicePlans);
        }
        model.addAttribute("servicePlans", accountService.findAllServicePlans());
        return "pages/account/new";
    }
    ...

若要与 Microsoft Entra ID 集成，引用实现使用 OAuth 2.0 授权码授权码许可流程。此流允许用户使用 Microsoft 帐户登录。以下代码片段演示如何配置 SecurityFilterChain 以使用 Microsoft Entra ID 进行身份验证和授权。

@Configuration(proxyBeanMethods = false)
@EnableWebSecurity
@EnableMethodSecurity
public class AadOAuth2LoginSecurityConfig {
    @Bean
    SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.apply(AadWebApplicationHttpSecurityConfigurer.aadWebApplication())
            .and()
                .authorizeHttpRequests()
            .requestMatchers(EndpointRequest.to("health")).permitAll()
            .anyRequest().authenticated()
            .and()
                .logout(logout -> logout
                            .deleteCookies("JSESSIONID", "XSRF-TOKEN")
                            .clearAuthentication(true)
                            .invalidateHttpSession(true));
        return http.build();
    }
}
...

优先选择临时访问存储。 使用临时权限来防范未经授权的访问和违规。例如，可以使用共享访问签名（SAS）来限制对一段时间的访问。在授予临时访问权限时，使用用户委派的共享访问签名 (SAS) 来最大化提高安全性。这是唯一使用 Microsoft Entra ID 凭据且不需要永久存储帐户密钥的 SAS。
在 Azure 中强制实施授权。 使用 Azure RBAC 将最小特权分配给用户身份。 Azure RBAC 定义了身份可以访问的 Azure 资源、身份可以对这些资源执行的操作，以及身份有权访问的区域。
避免永久提升的权限。 使用 Microsoft Entra Privileged Identity Management (PIM) 授予对特权操作的及时（JIT）访问权限。例如，开发人员通常需要管理员级访问权限来创建和删除数据库、修改表架构和更改用户权限。使用 JIT 访问时，用户标识会收到执行特权任务的临时权限。

实现托管标识

建议对所有支持托管标识的 Azure 服务使用托管标识。托管标识允许 Azure 资源（特别是工作负荷标识）向其他 Azure 服务进行身份验证并与之交互，而无需管理凭据。为了简化迁移，可以继续使用混合和旧系统的本地身份验证解决方案，但应尽快将其转换为托管标识。若要实现托管标识，请遵循以下建议：

选择正确的托管标识类型。当你有两个或多个需要相同权限集的 Azure 资源时，首选用户分配的托管标识。这种方法比为每个资源创建系统分配的托管标识并向其分配相同的权限更有效。否则，请使用系统分配的托管标识。
配置最小特权。 使用 Azure RBAC 仅授予操作所需的关键权限，例如在数据库中创建、读取、更新和删除（CRUD）操作或访问机密。工作负荷标识权限是永久性的，因此无法向工作负荷标识提供 JIT 或短期权限。如果 Azure RBAC 未涵盖特定方案，请使用 Azure 服务级别访问策略补充 Azure RBAC。
为剩余机密提供安全性。 将任何剩余机密存储在 Key Vault 中。在应用程序启动时从 Key Vault 加载机密，而不是在每个 HTTP 请求期间加载机密。 HTTP 请求中的高频率访问可能超过 Key Vault 事务限制。在应用配置中存储应用程序配置。

优化环境

使用满足每个环境需求的 Azure 服务的性能层（SKU），而无需超过它们。若要优化调整您的环境，请执行以下操作：

估算成本。 使用 Azure 定价计算器估算每个环境的成本。
优化生产环境。 生产环境需要满足 SLA、功能和规模要求的 SKU。持续监视资源使用情况并调整 SKU，以满足实际性能需求。
优化预生产环境。预生产环境应使用低成本资源，并利用 Azure 开发/测试定价计划等折扣。在这些环境中，禁用不需要的服务。此外，请确保预生产环境与生产环境足够相似，以避免引入风险。保持这种平衡，以确保测试保持有效，而不会产生不必要的成本。
使用 IaC 定义 SKU。 实现 IaC 以基于环境动态选择和部署正确的 SKU。此方法可增强一致性并简化管理。

例如，引用实现具有指定要部署的 SKU 的可选参数。环境参数指定 Terraform 模板应部署开发 SKU：

azd env set APP_ENVIRONMENT prod

实现自动扩展

自动缩放有助于确保 Web 应用保持弹性、响应能力，并且能够高效处理动态工作负荷。若要实现自动缩放，请遵循以下建议：

自动化横向扩展。 使用 Azure 自动缩放在生产环境中自动化横向扩展。配置自动缩放规则，以便根据关键性能指标横向扩展，以便应用程序可以处理不同的负载。
优化缩放触发器。 如果不熟悉应用程序的缩放要求，请使用 CPU 利用率作为初始缩放触发器。优化缩放触发器以包含其他指标，例如 RAM、网络吞吐量和磁盘输入/输出（I/O）。目标是匹配 Web 应用程序的行为以提高性能。
提供横向扩展缓冲区。 设置缩放阈值以在达到最大容量之前启动缩放。例如，将伸缩配置为在 85% CPU 使用率时发生，而不是等待直到达到 100%。这种主动方法有助于维护性能并避免潜在的瓶颈。

自动化资源部署

使用自动化在所有环境中部署和更新 Azure 资源和代码。遵循以下建议：

使用 IaC。 使用持续集成和持续交付（CI/CD）管道部署 IaC 。 Azure 为每个 Azure 资源提供预生成的 Bicep 模板、Azure 资源管理器模板（ARM 模板）JSON 和 Terraform 模板。
使用 CI/CD 管道。 使用 CI/CD 管道将源代码管理中的代码部署到各种环境，例如测试、过渡和生产环境。如果使用 Azure DevOps，请使用 Azure Pipelines。将 GitHub Actions 用于 GitHub 项目。
集成单元测试。 在部署到应用服务之前，优先运行和验证管道中的所有单元测试。整合代码质量和覆盖率工具（如 SonarQube）以实现全面的测试覆盖率。
采用模拟框架。 对于涉及外部终结点的测试，请使用模拟框架。通过这些框架，可以创建模拟终结点。它们无需配置真正的外部终结点，并确保跨环境进行统一的测试条件。
执行安全扫描。 使用静态应用程序安全测试（SAST）在源代码中查找安全漏洞和编码错误。执行软件组合分析（SCA），检查非Microsoft库和组件的安全风险。将这些分析的工具集成到 GitHub 和 Azure DevOps 中。

配置监控

实施应用程序和平台监视，以提高 Web 应用的卓越运营和性能效率。若要实现监视，请遵循以下建议：

收集应用程序遥测数据 使用 Application Insights 中的自动检测收集应用程序遥测数据，例如请求吞吐量、平均请求持续时间、错误和依赖关系监视。无需更改任何代码以使用此遥测数据。 Spring Boot 在 Application Insights 中注册多个核心指标，例如 Java 虚拟机（JVM）、CPU 和 Tomcat。 Application Insights 自动会从 Log4j 和 Logback 等日志记录框架收集信息。

参考实现在应用服务的 app_settings 配置中通过 Terraform 启用 Application Insights：
```
app_settings = {
    APPLICATIONINSIGHTS_CONNECTION_STRING = var.app_insights_connection_string
    ApplicationInsightsAgent_EXTENSION_VERSION = "~3"
    ...
}
```
如需了解更多信息，请参阅以下文章：
创建自定义应用程序指标。 实现基于代码的检测，通过添加 Application Insights SDK 并使用其 API 来捕获自定义应用程序遥测。

监控平台。 为所有受支持的服务启用诊断。将诊断发送到与应用程序日志相同的目标，以便关联。 Azure 服务会自动创建平台日志，但仅在启用诊断时存储它们。为每个支持诊断的服务启用诊断设置。

参考实现使用 Terraform 在受支持的服务上启用 Azure 诊断。以下 Terraform 代码配置应用服务的诊断设置：

# Configure diagnostic settings for app service
resource "azurerm_monitor_diagnostic_setting" "app_service_diagnostic" {
  name                           = "app-service-diagnostic-settings"
  target_resource_id             = azurerm_linux_web_app.application.id
  log_analytics_workspace_id     = var.log_analytics_workspace_id
  #log_analytics_destination_type = "AzureDiagnostics"

  enabled_log {
    category_group = "allLogs"

  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}

部署参考实现

参考实现将指导你完成 Contoso Fiber 模拟将本地 Java 应用程序迁移到 Azure。它还重点介绍了初始采用阶段所需的更改。

以下体系结构根据 Contoso Fiber 的目标，表示可靠 Web 应用模式实施的最终状态。

下载此体系结构的 Visio 文件。

后续步骤

参考实现

反馈

此页面是否有帮助？

Last updated on 2025-11-11