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

Azure Spring Apps 基线体系结构

Azure 应用程序网关
Azure Key Vault
Azure Spring Apps
Azure Database for MySQL

此参考体系结构介绍如何在 Azure Spring Apps 上运行 Java Spring Boot 工作负载。 设计使用区域冗余来实现高可用性。 实现此设计,以防止应用程序在区域中的所有数据中心发生中断时失败。

此体系结构可帮助你:

  • 通过单区域部署显式提高应用程序的可用性。
  • 提高应用程序的总体复原能力和服务级别目标 (SLO)。

此解决方案为部署 Azure Spring Apps 提供了一个基线策略。 有关基于此体系结构构建的其他解决方案,请参阅 将 Azure Spring Apps 部署到多个区域与登陆区域集成的 Azure Spring Apps

提示

GitHub 徽标 请参阅 示例实现,其中说明了此体系结构的一些设计选择。 将此实现视为迈向生产的第一步。

体系结构

下图显示了此方法的体系结构:

显示多区域 Azure Spring Apps 参考体系结构的示意图。下载此体系结构的 Visio 文件

Workflow

此工作流与上图相对应:

  1. 用户使用应用程序的 HTTP 主机名(例如 www.contoso.com)访问应用程序。 Azure DNS 用于将此主机名的请求解析为 Azure 应用程序网关公共终结点。

  2. 应用程序网关用于检查请求。 它也用于将允许的流量转发到预配的 Azure Spring Apps 实例中负载均衡器的 IP 地址。 应用程序网关与 Azure Web 应用程序防火墙集成。

  3. 内部负载均衡器用于将流量路由到后端服务。

  4. 处理请求时,应用程序将会与虚拟网络中的其他 Azure 服务通信。 例如,应用程序可能会从 Azure Key Vault 接收机密,或者从数据库接收存储状态。

组件

此体系结构中使用了以下 Azure 服务:

  • Azure Spring Apps 的标准版本用于托管作为微服务实现的示例 Java Spring Boot 应用程序。

  • 应用程序网关的标准 v2 版本用于管理发向应用程序的流量。 它充当应用程序运行的区域中的本地反向代理。

    此 SKU 与 Web 应用程序防火墙 集成,以帮助保护 Web 应用程序免于攻击和漏洞。 应用程序网关上的 Web 应用程序防火墙可跟踪 Open Web Application Security Project (OWASP) 攻击。

  • Azure DNS 用于解析发送到应用程序的主机名的请求。 它会将这些请求解析为应用程序网关公共终结点。 Azure DNS 专用区域 用于解析对访问命名的 Azure 专用链接 资源的专用终结点的请求。

  • Azure Database for MySQL 用于在后端关系数据库中存储状态。

  • Key Vault 用于存储应用程序机密和证书。 在 Azure Spring Apps 中运行的微服务使用应用程序机密。 Azure Spring Apps 和应用程序网关使用证书来保留主机名。

备选方法

Azure Database for MySQL 不是数据库的唯一选项。 也可使用以下命令:

冗余

在工作负荷中生成冗余,以最大程度地减少单一故障点。 在此体系结构中,你将跨区域中的区域复制组件。 在体系结构中,请确保为设置中的所有组件使用可用性区域。

并非所有 Azure 区域都支持 Azure 服务,也并非所有 Azure 区域都支持区域。 在选择区域之前,请验证其 区域区域支持

区域冗余服务自动在各个区域间复制或分布资源。 始终可用的服务在所有 Azure 地区始终可用,并且对地区范围和区域范围的中断具有复原能力。

下表显示了此体系结构中服务的复原类型:

服务 复原
Azure DNS 始终可用
应用程序网关 区域冗余
Azure Spring Apps 区域冗余
Azure Database for MySQL 区域冗余
密钥保管库 区域冗余
Azure 虚拟网络 区域冗余
Azure 专用终结点 区域冗余

Azure Spring Apps 支持区域冗余。 使用区域冗余,服务的所有底层基础结构都分布在多个可用性区域中,从而可为应用程序提供更高的可用性。 应用程序在不进行任何代码更改的情况下会水平缩放。 高性能网络连接 Azure 可用性区域。 该连接的往返延迟小于 2 毫秒 (ms)。 无需依赖数据工作负荷的异步复制,它通常会带来设计难题。

为应用程序网关设置多个可用性区域,包括应用程序网关使用的公共 IP 地址。 具有标准 SKU 的公共 IP 地址支持 可用性区域

此体系结构使用具有灵活服务器部署选项的 Azure Database for MySQL,以支持具有自动故障转移的高可用性。 根据延迟要求,选择 区域冗余的高可用性同区域高可用性。 使用高可用性配置,灵活服务器选项会自动预配和管理备用副本。 如果发生中断,提交的数据不会丢失。

在提供了可用性区域的任何地区中,Key Vault 会自动实现区域冗余。 此体系结构中使用的 Key Vault 实例会部署到存储后端服务的机密。

可伸缩性

可扩展性是指工作负载能够有效满足用户需求的能力。 多区域方法比单区域部署更适合可伸缩性,因为它会将负载分散到各个可用性区域。

此体系结构具有多个可根据指标自动缩放的组件:

如果需要在区域之间同步数据,可能会产生额外的延迟,具体取决于数据库设置。

网络安全性

保护应用程序免受来自 Internet 的未经授权的访问、专用网络中的系统、其他 Azure 服务以及紧密耦合的依赖项。

虚拟网络是 Azure 中专用网络的基本构建基块。 此体系结构使用虚拟网络作为部署区域。 将组件置于子网中以创建进一步隔离。 Azure Spring Apps 需要一个用于服务运行时的专用子网和一个用于 Java Spring Boot 应用程序的单独子网。

使用 Azure DDoS 防护 来保护虚拟网络。 将分布式拒绝服务 (DDoS) 防护与应用程序设计最佳做法相结合,以提供增强的缓解措施来防御 DDoS 攻击。

体系结构设计包含多个平台即服务 (PaaS) 解决方案,可帮助处理用户请求。 对这些服务进行严格的网络控制,以确保应用程序不会受到影响。

专用连接

使用专用终结点或网络集成提供从 Azure Spring Apps 到支持服务(如 Key Vault 和 Azure Database for MySQL)的通信。

使用专用终结点来控制访问。 这些网络接口使用专用 IP 地址将服务传输到虚拟网络。 该体系结构具有可自动设置专用终结点的 Azure 服务。

通过 虚拟网络注入过程,将 Azure Spring Apps 部署到网络中。 可通过访问专用 IP 地址来访问该应用程序。

数据库遵循类似的模式。 Azure Database for MySQL 的灵活服务器部署模式支持通过专用子网进行虚拟网络集成。

其他服务(如 Key Vault)会通过 专用链接 连接到虚拟网络。 对于专用链接,需要启用专用终结点以禁用公用网络访问。 有关详细信息,请参阅 将 Key Vault 与专用链接集成

专用终结点不需要专用子网,但最好将它们置于单独的子网中。 专用终结点的专用 IP 地址是从该子网分配的。

专用终结点和网络集成连接使用 Azure DNS 专用区域

对流量流的控制

使用此体系结构时,仅允许通过应用程序网关公开的公共终结点来接收请求。 仍需要对流量进行检查,以阻止攻击和漏洞。 应用程序网关上的 Web 应用程序防火墙跟踪 OWASP 漏洞。 根据配置的规则检查传入流量,并遵循相应的操作。

Azure Spring Apps 实例具有一个内部负载均衡器,用于将流量路由和分发到后端服务。 负载均衡器配置为仅接受来自应用程序网关的流量。

应用程序可能需要通过公共 Internet 与其他终结点进行连接。 若要限制该流量,请考虑将 Azure 防火墙置于出口路径上。

反向代理设置

解决方案使用应用程序网关作为反向代理。 但是,你可在 Azure Spring Apps 前使用不同的反向代理。 可将应用程序网关与 Azure Front Door 结合使用,也可使用 Front Door 而不使用应用程序网关。

有关反向代理方案、设置方式及其安全注意事项的信息,请参阅通过反向代理公开 Azure Spring Apps

标识和访问管理

除了使用网络控制之外,还可使用标识作为外围来增强安全态势。

当应用程序与后端服务连接时,应用程序应自行进行身份验证,就像应用程序从 Key Vault 检索机密一样。 在应用程序中,建议的方法是启用 Azure 资源的 Microsoft Entra 托管标识。 此配置方法将标识分配给应用程序,以便它可以获取 Microsoft Entra ID 令牌,从而降低管理凭据的开销。

此体系结构使用系统分配的托管标识进行多次交互。

后端服务应允许访问分配给托管标识的服务主体。 服务应该为某些操作定义最低访问权限策略。 在此体系结构中,Key Vault 用于授予应用程序对机密、证书和密钥的访问权限。

机密管理

此体系结构将应用程序机密和证书存储在单个密钥保管库中。 应用程序机密和用于主机名保留的证书是不同的问题,因此可能需要将这些项存储在单独的密钥保管库中。 此替代方法为体系结构添加了另一个密钥保管库。

监视

Azure Monitor 是一种监视解决方案,可用于收集、分析和响应来自云和本地环境的监视数据。

向应用程序添加检测,以在代码级别发出日志和指标。 请考虑启用分布式跟踪,以便在 Azure Spring Apps 实例中提供服务的可观测性。 使用应用程序性能管理 (APM) 工具收集日志和指标数据。 适用于 Azure Monitor 的 Application Insights Java 代理是 APM 工具的最佳选择。

使用平台诊断从所有 Azure 服务(例如 Azure Database for MySQL)获取日志和指标。 将所有数据与 Azure Monitor 日志 集成,以便提供对应用程序和平台服务的端到端见解。

Azure Log Analytics 工作区 是从 Azure 资源和 Application Insights 收集日志和指标的监视数据接收器。 此日志记录解决方案提供可见性,这有助于自动化进程实时缩放组件。 分析日志数据还可以揭示应用程序代码中的低效率问题,你可以解决这些问题,以降低成本和提高性能。

有关 Spring App 特定的监视指南,请参阅 监视应用程序端到端使用 Dynatrace Java OneAgent 监视器

自动化部署

尽可能自动执行基础结构部署和应用程序代码部署。

自动化基础结构部署可确保基础结构配置完全相同,这有助于避免环境之间可能存在的配置偏差。 还可以使用基础结构自动化来测试故障转移操作。

可为应用程序使用蓝绿或 Canary 部署策略。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则,即一套可用于改善工作负荷质量的指导原则。 有关详细信息,请参阅 Microsoft Azure 架构良好的框架

以下注意事项提供了有关在此体系结构上下文中实现 Azure 良好架构框架的支柱的指导。

可靠性

可靠性可确保应用程序符合你对客户的承诺。 有关详细信息,请参阅可靠性支柱概述

实现以下建议以创建更可靠的应用程序:

安全性

安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息,请参阅安全性支柱概述

实现以下建议以创建更安全的应用程序:

成本优化

成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息,请参阅成本优化支柱概述

对于此体系结构,需要更高的成本,因为你在多个区域中部署组件。 它们运行 Azure Spring Apps 的两个甚至三个实例,而不是一个实例。 但是,在服务上启用区域冗余不会产生额外的费用。 有关详细信息,请参阅 Azure Spring Apps - 定价

请考虑以下实现选项来解决成本问题:

  • 可以将不同的应用程序和应用程序类型部署到 Azure Spring Apps 的单个实例。 部署多个应用程序时,底层基础结构的成本将分摊到各个应用程序中。

  • Azure Spring Apps 支持由指标或计划触发的应用程序自动缩放,这可以提高利用率和成本效益。

  • 可以使用 Azure Monitor 中的 Application Insights 降低运营成本。 持续监视有助于更快地解决问题并提高成本和性能。

  • 根据要求选择最佳定价层:

  • 对应用程序使用自动缩放 以根据需求进行纵向扩展和缩减。

有关此体系结构的估计服务成本,请参阅 Azure 定价计算器。 此估计对小型应用程序使用合理的默认值。 可以根据应用程序的预期吞吐量值更新该估计值。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息,请参阅卓越运营支柱概述

除了前面介绍的 监视指南 外,还可实施以下建议来帮助部署和监视应用程序。

性能效率

性能效率是指工作负荷能够以高效的方式扩展以满足用户对它的需求。 有关详细信息,请参阅性能效率支柱概述

实现以下建议以创建更高效的应用程序:

部署此方案

若要部署此体系结构,请按照 Azure Spring Apps 多区域参考体系结构 中的分步说明进行操作。 部署使用 Terraform 模板。

作者

本文由 Microsoft 维护, 它最初是由以下贡献者撰写的。

主要作者:

若要查看非公开的 LinkedIn 个人资料,请登录到 LinkedIn。

后续步骤