手册

需要一个 App Service 计划，用于生产环境 Web 应用，并支持自定义域名/SSL、自动缩放和部署槽位。

→使用 Standard (S1) 或更高级别的 App Service 计划。

原因: Standard 是支持所有关键生产功能（自定义域名带 SSL、自动缩放和部署槽位）的最低层级。Basic 层级缺少自动缩放和部署槽位。

参考↗

为 App Service 执行零停机部署，并将生产设置（如连接字符串）保留在生产槽位中。

→使用部署槽位。将生产特定的设置标记为“部署槽位设置”（粘性）。执行交换操作进行部署。

原因: 交换操作会在重定向流量之前预热暂存槽位。粘性设置在交换过程中不会随代码移动，从而防止暂存设置上线。

参考↗

App Service 需要在没有 VPN 或 ExpressRoute 的情况下连接到本地资源（例如 SQL Server）。

→使用 App Service 混合连接。在本地安装混合连接管理器 (HCM)。

原因: 混合连接提供到本地资源的安全 TCP 隧道，无需入站防火墙端口、VPN 或 VNet 集成。HCM 启动出站连接。

消耗计划上的 Azure Function 遇到长时间冷启动，导致延迟。

→迁移到 Functions Premium 计划并配置至少一个预热实例。

原因: Premium 计划通过保持指定数量的实例始终就绪来消除冷启动。为此目的，它比完整的专用计划更具成本效益。

参考↗

消耗计划上的 Azure Function 因执行时间超过 10 分钟而超时。

→将 Function 迁移到 Premium 或专用 (App Service) 计划。

原因: 消耗计划的最大超时时间为 10 分钟。Premium 和专用计划支持更长的执行时间（最长 60 分钟或无限）。

并行处理大量独立项，并在所有项完成后再继续。

→实施 Durable Functions 扇出/扇入模式。业务流程协调程序并发调用多个活动函数，并使用 `Task.WhenAll`（或等效项）等待完成。

原因: 此模式专为并行执行设计，对于独立任务，其效率远高于顺序处理（函数链）。

参考↗

一个长时间运行的工作流必须等待外部事件（如人工审批），并带有超时设置。

→使用 Durable Functions 人机交互模式。将 `waitForExternalEvent` 与 `createTimer` 结合使用。当事件到达或计时器过期时，使用 `Task.WhenAny` 继续。

原因: 此模式允许业务流程无限期暂停而不消耗计算资源，等待外部触发器，同时优雅地处理超时。

容器化应用程序在没有流量时需要缩放至零个实例以最大程度地降低成本。

→使用 Azure Container Apps 和基于 KEDA 的缩放规则（例如，HTTP 请求或队列长度）。

原因: Container Apps 与 KEDA 缩放器在空闲时可以缩减到零个副本，并根据需求进行扩展，这非常适合事件驱动或间歇性工作负载。CPU/内存缩放无法缩减到零。

Azure Container Apps 中的后端微服务必须只能由同一环境中的其他容器应用访问，不能从公共互联网访问。

→在后端容器应用上启用入口，并将流量可见性设置为 `internal`。

原因: 内部入口将访问限制在 Container Apps 环境中。环境中的其他应用可以使用其内部 FQDN 发现并调用该服务。

需要运行单个容器以执行简单任务、测试或批处理作业，无需业务流程编排。

→使用 Azure 容器实例 (ACI)。

原因: ACI 是运行单个容器的最快、最简单方法，无需管理任何底层基础设施。对于多容器应用程序的业务流程编排，请使用 Container Apps 或 AKS。

需要从本地 Dockerfile 构建 Docker 镜像并将其推送到 Azure 容器注册表 (ACR)，但本地未安装 Docker。

→使用 `az acr build` 命令。

原因: `az acr build` 将构建过程卸载到云中的 ACR Tasks。它将构建上下文发送到 Azure，构建镜像，并直接将其存储在注册表中。

设计一个 Cosmos DB 容器，该容器频繁查询特定属性（例如 `region`）上的筛选。

→选择最常查询的、高基数属性作为分区键（例如 `/region`）。

原因: WHERE 子句中包含分区键的查询会定位到单个逻辑分区，从而避免昂贵的跨分区扇出查询并最大程度地减少 RU 消耗。

参考↗

一个全球分布式应用程序要求读取操作始终返回最新提交的写入。

→将 Cosmos DB 帐户一致性级别配置为 Strong。

原因: Strong 一致性提供线性一致性保证，确保读取始终是最新的。其他级别（Session、Bounded Staleness、Eventual）以牺牲一致性换取更低的延迟和更高的可用性。

需要实时处理 Cosmos DB 容器中所有新增或更新的文档，以更新物化视图。

→使用带有 Cosmos DB 触发器的 Azure Function，该触发器利用更改源处理器。

原因: 更改源提供一个持久的更改日志。带有更改源处理器的 Cosmos DB 触发器可自动化多个函数实例的状态管理和负载均衡。

需要对同一逻辑分区中的多个文档执行原子操作（例如，创建两个并更新一个）。

→在 Cosmos DB SDK 中使用 `TransactionalBatch` API。所有操作都必须针对同一分区键。

原因: TransactionalBatch 确保批处理中的所有操作作为一个原子单元成功或失败，从而防止部分更新。对于客户端批处理操作，它比存储过程更高效。

Cosmos DB 工作负载不可预测，流量具有显著的峰谷。

→在数据库或容器上配置自动缩放预配吞吐量。

原因: 自动缩放根据使用情况自动调整 RU/秒，确保高峰期的性能并在低谷期节省成本。它在最大配置 RU/秒的 10% 到 100% 之间缩放。

数据首先频繁访问，然后不频繁访问，最后存档以进行长期保留。

→结合使用热、冷和存档访问层。使用生命周期管理策略自动化转换。

原因: 使访问层与访问模式保持一致可以优化成本。热层用于频繁访问，冷层用于不频繁访问，存档层用于长期、低成本存储。生命周期策略自动化此过程。

参考↗

防止多个进程同时修改同一个 Blob。

→实施 Blob 租约。进程在修改 Blob 之前获取对 Blob 的独占写入锁（租约）。

原因: 租约提供悲观并发控制。一旦租约被获取，在租约释放或过期之前，其他客户端无法写入 Blob。

将审核日志存储在 Blob Storage 中，并确保它们在固定的保留期（例如 7 年）内不能被修改或删除。

→在 Blob 容器上配置基于时间的保留策略。对于无限期保留，请使用法律保留。

原因: 不可变存储策略强制执行 WORM（一次写入，多次读取）状态，这对于合规性至关重要。一旦锁定，基于时间的策略不能缩短。

需要使用键值属性对 Blob 进行分类，并在整个存储帐户中查询它们，而无需列出所有 Blob。

→使用 Blob 索引标签。

原因: 索引标签由存储服务索引，可用于服务器端筛选查询 (`Find Blobs by Tags`)。元数据未被索引，只能在列出后在客户端进行筛选。

在单页应用程序 (SPA) 中安全地验证用户身份，并获取后端 API 的令牌。

→使用带有 PKCE（用于代码交换的证明密钥）的授权码流。

原因: 这是公共客户端当前的最佳安全实践。它避免了在 URL 中暴露令牌（与已弃用的隐式流不同），并且不需要客户端机密。

参考↗

后台服务或守护程序需要在没有登录用户的情况下调用受保护的 API（如 Microsoft Graph）。

→使用带有应用程序权限的客户端凭据流。

原因: 此流使用客户端机密或证书对应用程序本身进行身份验证。应用程序权限授予对整个组织的访问权限，但须经管理员同意。

中间层 Web API 需要调用下游 API，同时保留原始登录用户的身份。

→实施代表流 (OBO)。

原因: 中间层 API 将用户的访问令牌交换为作用域为下游 API 的新令牌。这安全地委托了用户的身份。

使用 MSAL 的应用程序需要高效地获取令牌，最大程度地减少用户提示。

→始终首先调用 `AcquireTokenSilent()`。如果它因 `MsalUiRequiredException` 失败，则回退到交互式方法，如 `AcquireTokenInteractive()`。

原因: `AcquireTokenSilent()` 检查缓存中是否存在有效令牌，或使用刷新令牌获取新令牌而无需用户交互。这对于良好的用户体验至关重要。

Azure 资源（例如 App Service、Function）需要访问另一个 Azure 资源（例如 Key Vault、SQL Database），而无需在代码或配置中存储凭据。

→在源资源上启用托管标识（系统分配或用户分配），并向其授予目标资源上的 RBAC 权限。

原因: 托管标识为资源提供 Microsoft Entra ID 中的身份。Azure 管理凭据生命周期，从而消除了开发人员处理机密的需要。

参考↗

多个 Azure 资源需要共享相同的身份和权限才能访问其他服务。

→创建一个用户分配的托管标识，并将其分配给所有必需的资源。

原因: 用户分配的标识具有独立于任何资源的生命周期，使其可重用。系统分配的标识与单个资源绑定，并在资源删除时一并删除。

需要使用 Azure AD 组授予对 Key Vault 机密的访问权限，并在单个机密级别上提供精细权限。

→使用 Key Vault 的 Azure RBAC 权限模型。向主体分配 `Key Vault Secrets User` 等角色。

原因: RBAC 允许在保管库或单个密钥/机密/证书范围内分配角色，提供比访问策略更高的粒度，访问策略适用于保管库中某种类型的所有对象。

应用程序需要从 Azure App Configuration 获取配置更改而无需重新启动。

→使用 App Configuration 提供程序/SDK 并将其配置为通过监视哨兵键来刷新。

原因: SDK 可以定期检查哨兵键的更改。更新应用程序设置时，您也更新哨兵键，这会触发所有客户端刷新其配置。

需要为特定用户组（例如 Beta 测试人员）和一部分普通受众启用新功能。

→使用带有定向筛选器的 Azure App Configuration 功能标志。

原因: 定向筛选器支持复杂的功能发布，允许您根据用户和组定义具有特定百分比的受众，并为其他所有人定义默认发布百分比。

需要生成一个安全、短期的令牌，以授予客户端访问特定 Blob 的权限。

→创建用户委托 SAS。

原因: 用户委托 SAS 使用 Microsoft Entra ID 凭据签名，而不是存储帐户密钥。这更安全，因为它避免了分发帐户密钥，并且可以通过 Entra ID 策略撤销访问权限。

通过可视化依赖关系并识别哪个下游服务导致高延迟来排查微服务应用程序中的性能问题。

→使用 Application Insights 中的应用程序映射功能。

原因: 应用程序映射会自动发现并显示分布式应用程序的拓扑视图，显示每个组件的运行状况和性能指标以及它们之间的调用。

参考↗

跟踪单个用户请求流经多个微服务。

→使用 Application Insights 中的端到端事务详细信息视图。所有遥测数据通过共享的 `operation_Id` 进行关联。

原因: Application Insights SDK 会自动传播 W3C Trace Context 标头，从而使单个操作的所有遥测数据都能与相同的 `operation_Id` 关联，从而实现统一视图。

诊断生产问题：间歇性性能缓慢与间歇性异常。

→对于性能缓慢，使用 Application Insights Profiler。对于异常，使用 Snapshot Debugger。

原因: Profiler 捕获慢请求（“热路径”）的方法级时间跟踪。Snapshot Debugger 在抛出异常时捕获调用堆栈和局部变量。

在保持统计有效数据的前提下，减少来自高流量应用程序的 Application Insights 数据量和成本。

→在应用程序的 SDK 配置中启用自适应采样。

原因: 自适应采样会自动调整采样率以保持在目标数据量范围内，在高流量期间更积极地采样，在低流量期间采样较少，从而保留重要的遥测数据。

持续监控 Web 应用程序端点在多个地理位置的可用性。

→在 Application Insights 中配置标准可用性测试（URL ping 测试）。

原因: 可用性测试从全球 Azure 数据中心向您的端点发送请求，提供对正常运行时间和响应能力的积极监控，并在失败时触发警报。

创建当性能指标（例如平均响应时间）在定义的时间段内超过特定阈值时触发的警报。

→创建 Azure Monitor 指标警报规则。指定资源和指标，配置静态阈值、聚合类型和评估期。链接到操作组。

原因: 指标警报提供对近实时指标数据的低延迟、有状态监控，这非常适合基于性能的警报。

通过限制调用频率（例如 100 次调用/分钟）与在较长时间内（例如 10,000 次调用/月）的总调用次数来控制 API 使用。

→对于调用频率使用 `rate-limit` 策略。对于总调用量使用 `quota` 策略。

原因: `rate-limit` 限制短期突发，并返回 HTTP 429。`quota` 在较长时间（例如计费周期）内强制执行使用上限，并在超出时返回 HTTP 403。

参考↗

在 API Management 中缓存 API 响应以减少后端负载，缓存键根据请求头而变化。

→在入站部分使用 `<cache-lookup vary-by-header="..." />` 策略，在出站部分使用 `<cache-store duration="..." />` 策略。

原因: 这种两部分策略组合可启用响应缓存。`cache-lookup` 检查缓存项，`cache-store` 保存响应。`vary-by` 属性确保不同请求变体的唯一缓存条目。

管理 API 更改。需要进行破坏性更改与需要测试非破坏性更改。

→对于破坏性更改（例如 /v1, /v2），使用版本 (Versions)。对于非破坏性更改和安全、分阶段的发布，使用修订 (Revisions)。

原因: 版本控制允许多个 API 版本同时在线。修订允许您离线修改 API，测试它，然后将其设为“当前”修订而无需停机。

当 Azure 服务中发生事件（例如 Blob 创建、资源组创建）时，通知多个独立的下游服务。

→使用 Azure Event Grid。为 Azure 资源创建系统主题，并为每个下游处理程序创建事件订阅。

原因: Event Grid 是一个完全托管的、基于推送的发布/订阅服务，它将事件发布者与订阅者解耦，从而实现响应式、事件驱动的架构。

参考↗

从许多设备摄取高容量的遥测或事件数据流（每秒数百万个事件）。

→使用 Azure Event Hubs。

原因: Event Hubs 是一个大规模可扩展的数据流平台，专为高吞吐量摄取而设计。它使用分区消费者模型进行并行处理。

确保来自同一源（例如特定 IoT 设备）的事件按顺序由同一消费者处理。

→将事件发送到 Event Hubs，并将分区键设置为源标识符（例如设备 ID）。

原因: Event Hubs 将所有具有相同分区键的消息路由到同一分区。在分区内，消息顺序得以保持。

以严格的先进先出 (FIFO) 顺序处理一系列相关消息。

→使用 Azure Service Bus 会话。发送所有具有相同 `SessionId` 的相关消息。

原因: 会话提供并发、有序的消息流。会话感知接收器锁定会话，保证消息由单个消费者按顺序处理。

单个发布者向主题发送消息，但多个订阅者只想根据消息属性获取这些消息的子集。

→使用具有多个订阅的 Service Bus 主题。对每个订阅应用 SQL 筛选器或关联筛选器。

原因: 这是带有基于内容的路由的规范发布/订阅模式。如果消息与订阅的筛选规则匹配，则每个订阅都会收到消息的副本。

消息在多次重试后仍无法成功处理，必须将其搁置以供以后检查。

→让消息处理失败，直到其最大传递计数超过。它将自动移动到死信队列 (DLQ)。

原因: DLQ 是一个内置的毒消息子队列。这可以防止失败消息阻塞主队列，并允许离线分析和重新处理。

为企业命令、响应式事件或高容量遥测选择消息传递服务。

→Service Bus 用于命令（订单、事务）。Event Grid 用于响应式事件（Blob 创建、资源更改）。Event Hubs 用于遥测（IoT 数据、点击流）。

原因: Service Bus 提供丰富的功能，如排序、事务和死信。Event Grid 用于轻量级、基于推送的事件路由。Event Hubs 用于高吞吐量数据流。