使用 Azure 容器应用和 Dapr 部署微服务

本文介绍在 Azure 容器应用上运行具有 10 个微服务的订单管理系统的解决方案。 该解决方案还通过 Dapr 和 KEDA 的事件驱动缩放来使用微服务最佳做法。

Dapr 和 Traefik 是各自公司的商标。 使用这些标志并不意味着认可。

体系结构

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

数据流

此解决方案使用 Bicep 模板来执行 Reddog 订单管理系统及其支持 Azure 基础结构的部署。 该体系结构由托管 10 个 .NET Core 微服务应用程序的单个 Azure 容器应用环境组成。 使用 .NET Core Dapr SDK 通过发布-订阅 (pub/sub) 以及状态和绑定构建基块与 Azure 资源集成。 尽管 Dapr 通常在你实现组件时提供灵活性，但此解决方案以观点为基础。 服务还利用 KEDA 缩放规则，允许基于事件触发器进行缩放，并缩放到零场景。

以下列表描述了它部署时使用的每个微服务和 Azure 容器应用配置。 请参阅 GitHub上的 reddog-code 存储库以查看代码。

1. Traefik：用于将用户请求从 UI 路由到交互式仪表板的会计和 Makeline 服务的基本代理。

2. UI：显示 Reddog 订单管理系统的实时订单和聚合销售数据的仪表板。

3. 虚拟客户：一个客户模拟程序，用于模拟客户通过订单服务下订单。

4. 订购服务：用于下订单和管理订单的 CRUD API。

5. 会计服务：处理、存储和聚合订单数据的服务。 它将客户订单转换为 UI 展示的有意义的销售指标。

6. 收据服务：一个存档程序，用于生成和存储订单收据，以供审核和历史记录之用。

7. 会员服务：一项通过根据订单支出跟踪客户奖励积分来管理会员计划的服务。

8. Makeline 服务：一种负责管理等待履行的当前订单队列的服务。 它跟踪虚拟辅助角色服务对订单的处理和完成。

9. 虚拟辅助角色：一种模拟客户订单完成情况的辅助角色模拟程序。

10. 引导程序（未显示）：一种使用 Entity Framework Core 来初始化 Azure SQL 数据库中的表以便与会计服务一起使用的服务。

组件

此解决方案使用以下组件：

• Azure 资源组是 Azure 资源的逻辑容器。 在 Azure 门户中使用单个资源组来构建与此解决方案相关的所有内容。
• Azure 容器应用是一种完全托管的无服务器容器服务，用于大规模生成和部署新式应用。 在此解决方案中，你将在 Azure 容器应用上托管所有 10 个微服务，并将其部署到单个容器应用环境中。 此环境充当系统周围的安全边界。
• Azure 服务总线是一个完全托管的企业消息代理，其中包含队列和发布-订阅主题。 在此解决方案中，将其用于 Dapr pub/sub 组件实现。 多个服务使用此组件。 订单服务在总线上发布消息，而 Makeline、会计、会员和收据服务订阅这些消息。
• Azure Cosmos DB 是一种 NoSQL 多模型托管数据库服务。 将其用作会员服务的 Dapr 状态存储组件，用于存储客户的会员数据。
• Azure Cache for Redis 是一种分布式内存中可缩放的 Redis 缓存。 它用作 Makeline 服务的 Dapr 状态存储组件，用于存储正在处理的订单的数据。
• Azure SQL 数据库是面向云生成的一项可缩放的智能关系数据库服务。 为会计服务创建它，该服务使用 Entity Framework Core 与数据库进行交互。 引导程序服务负责在数据库中设置 SQL 表，然后在建立与会计服务的连接之前运行一次。
• Azure Blob 存储可存储大量非结构化数据，例如文本或二进制文件。 收据服务通过 Dapr 输出绑定使用 Blob 存储来存储订单收据。
• Traefik 是一种领先的新式反向代理和负载均衡器，使部署微服务变得很容易。 在此解决方案中，使用 Traefik 的动态配置功能从 UI（这是一个 Vue.js 单页应用程序，SPA）执行基于路径的路由。 此配置还支持对后端服务进行直接 API 调用以进行测试。
• Azure Monitor 支持从 Azure 基础结构环境收集、分析和处理客户内容数据。 将它与 Application Insights 一起使用，以查看容器日志并从微服务收集指标。

备选方法

在此体系结构中，部署一个 Traefik 代理，为 Vue.js API 启用基于路径的路由。 有许多可用于此目的的备选开放源代码代理。 另外两个常用项目是 NGINX 和 HAProxy。

除 Azure SQL 数据库之外，所有 Azure 基础结构都使用 Dapr 组件实现互操作性。 Dapr 的一个好处是，可通过更改容器应用部署配置来交换所有这些组件。 在这种情况下，选择 Azure 服务总线、Azure Cosmos DB、Cache for Redis 和 Blob 存储来展示 70 多个可用的 Dapr 组件中的部分组件。 Dapr 文档中列出了备选的 pub/sub 代理、状态存储和输出绑定。

方案详细信息

微服务是一种越来越受欢迎的体系结构风格，可以带来很多好处，包括高可伸缩性、更短的开发周期和更高的简化性。 可以用容器作为部署微服务应用程序的机制，然后使用 Kubernetes 等容器业务流程协调程序来简化操作。 对于大规模微服务体系结构，需要考虑许多因素。 通常，基础结构平台要求对容器业务流程协调程序等复杂技术有深入的了解。

Azure 容器应用是一种完全托管的无服务器容器服务，用于大规模运行新式应用程序。 它使你能够通过基础平台的抽象部署容器化应用。 这样，你就不需要管理复杂的基础结构。 Azure 容器应用由开放源代码技术提供支持。

此体系结构使用 Azure 容器应用与分布式应用程序运行时 (Dapr) 的托管版本集成。 Dapr 是一个开放源代码项目，可帮助开发人员应对分布式应用程序中固有的挑战，例如状态管理和服务调用。

Azure 容器应用还提供 Kubernetes Event-driven Autoscaling (KEDA) 的托管版本。 KEDA 允许容器根据来自外部服务（如 Azure 服务总线和 Azure Cache for Redis）的传入事件自动缩放。

你也可在 Azure 容器应用中启用 HTTPS 入口，而无需创建更多 Azure 网络资源。 可使用 Envoy 代理，该代理还支持流量拆分场景。

要了解 Azure 容器应用与 Azure 中其他容器托管平台的比较，请参阅将容器应用与其他 Azure 容器选项进行比较。

本文介绍在 Azure 容器应用上运行具有 10 个微服务的订单管理系统的解决方案。 该解决方案还通过 Dapr 和 KEDA 的事件驱动缩放来使用微服务最佳做法。

可能的用例

此解决方案适用于任何将无状态和有状态微服务用于分布式系统的组织。 该解决方案最适合消费性包装品和具有订购和履行系统的制造业。

这些其他解决方案具有类似的设计：

• Azure Kubernetes 服务 (AKS) 中的微服务体系结构
• Azure Functions 上的微服务体系结构
• 事件驱动的体系结构

注意事项

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

可靠性

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

Azure 容器应用在后台于 Kubernetes 上运行。 复原机制内置于 Kubernetes 中，可在出现问题时监视和重启容器或 Pod。 复原机制与内置负载均衡器相结合，以运行每个容器应用的多个副本。 借助此冗余，解决方案可容许实例不可用。

可使用 Azure Monitor 和 Application Insights 来监视 Azure 容器应用。 可通过在门户中导航到每个容器应用程序的“日志”窗格来查看容器日志，然后运行以下 Kusto 查询。 此示例显示 Makeline 服务应用的日志。

ContainerAppConsoleLogs_CL |
    where ContainerAppName_s contains "make-line-service" |
    project TimeGenerated, _timestamp_d, ContainerGroupName_s, Log_s |
    order by _timestamp_d asc

Application Insights 中的应用程序映射还显示服务如何实时通信。 然后，可将它们用于调试场景。 导航到 Application Insights 资源下的应用程序映射，查看如下内容。

有关监视 Azure 容器应用的详细信息，请参阅在 Azure 容器应用中监视应用。

成本优化

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

使用 Azure 定价计算器估算此体系结构中的服务成本。

性能效率

性能效率是指工作负载以高效的方式扩展以满足你对它的要求的能力。 有关详细信息，请参阅性能效率要素概述。

此解决方案在很大程度上依赖于 Azure 容器应用中的 KEDA 实现来进行事件驱动的缩放。 在你部署虚拟客户服务时，它将持续下单，这会导致订单服务通过 HTTP KEDA 缩放程序纵向扩展。 当订单服务在服务总线上发布订单时，服务总线 KEDA 缩放程序会导致会计、收据、Makeline 和会员服务纵向扩展。 UI 和 Traefik 容器应用还会配置 HTTP KEDA 缩放程序，使应用随着更多用户访问仪表板而缩放。

如果虚拟客户未运行，此解决方案中的所有微服务将缩放为零，但虚拟辅助角色和 Makeline 服务除外。 虚拟辅助角色不会纵向缩减，因为它不断检查订单履行情况。 有关在容器应用中缩放的详细信息，请参阅在 Azure 容器应用中设置缩放规则。 有关 KEDA 缩放程序的详细信息，请阅读有关缩放程序的 KEDA 文档。

部署此方案

有关部署说明，请参阅 GitHub上的 Red Dog 演示：Azure 容器应用部署。

Red Dog 演示：微服务集成是一个打包的应用模板，它基于上述代码资产构建，用于演示 Azure 容器应用、应用服务、Functions 和 API 管理的集成，并使用 GitHub Actions 预配基础结构、部署代码。

作者

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

首席作者：

• Alice Gibbons | 云原生全球黑带

其他参与者：

• Kendall Roden | 高级计划经理
• Lynn Orrell | 首席解决方案专家 (GBB)

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

后续步骤

• Azure 容器应用文档
• 比较 Azure 中的容器产品/服务
• 其他 Reddog 订单管理系统实现：
  • Azure Arc 混合部署
  • AKS 部署
  • 本地开发

相关资源

• Azure Kubernetes 服务上的微服务体系结构
• 高级 Azure Kubernetes 服务 (AKS) 微服务体系结构
• 使用 Azure Pipelines 实现 AKS 应用的 CI/CD