解决方案体系结构

eShopOnContainers 应用是一家网上商店，这家店销售各种产品，包括大头针、T 恤和咖啡杯。 该商店包括以下功能：

• 目录管理
• 购物车
• 用户管理
• 订单管理
• 支付
• 优惠券管理（在关系图中有显示，但尚不存在）

可以使用不同的微服务管理上述每项功能。 每个微服务都享有自主权、可独立部署，且负责其自己的数据。 此体系结构使每个微服务都能实现最适合其工作负载、存储需求以及读/写模式的数据存储。 数据存储选项包括关系、文档、键/值和基于图形的选项。

例如，目录服务将其数据存储在 Linux 上的 SQL Server 数据库中。 购物车服务使用 Redis 缓存进行存储。 不存在所有服务都与之进行交互的单个主数据存储。 取而代之的是，服务间通信根据需要进行，其可通过同步 API 调用进行，也可通过消息传递异步进行。 这种数据隔离为每个服务提供了自主权，使其可以独立应用数据架构更新，而不会中断生产环境中的其他服务。

身份验证和授权

WebSPA 客户端应用将身份验证和授权问题委托给标识服务，该标识服务还充当了安全令牌服务 (STS)。 标识服务是一个容器化 ASP.NET Core 项目，它使用的 IdentityServer 4 是一个用于 ASP.NET Core 的热门 OpenID Connect 和 OAuth 2.0 框架。 托管 STS 的替代方法是使用 Azure Active Directory (Azure AD)。 Azure AD 提供标识和访问管理即服务。

关系图中的标识服务配置为允许直接访问。 因此，会绕过 API 网关。 此示例所基于的完整 eShopOnContainers 应用会使用多个 API 网关，这些网关由业务区域进行分隔。 但对于此较小的实现，不需要另一个 API 网关。

事件总线

使用事件总线进行异步消息传递和事件驱动的通信。 前面的体系结构关系图描述了部署到 AKS 的 Docker 容器中的 RabbitMQ，但对于 Azure 服务总线等服务，它也是适用的。

上面的关系图描述了与事件总线一起使用的发布/订阅（通常缩短为“pub-sub”）模式。 任何服务都可以将事件发布到事件总线。 每个服务负责订阅与其域相关的消息。 每个服务都使用 Startup.cs 的 ConfigureServices 方法调用 AddEventBus 扩展方法。 此方法建立与事件总线的连接，并为该服务的域注册相应的事件处理程序。

API 网关

客户端可通过 API 网关访问微服务。 除其他优点外，API 网关还增强了安全性，且能够使后端服务与单个客户端分隔开来。

WebSPA 店面是一个 ASP.NET Core MVC 和 Angular 应用，可通过公共 IP 地址进行访问。 WebSPA 应用到微服务的 HTTP 请求通过 API 网关进行路由，该网关是面向前端的后端 (BFF) 模式的实现。 使用 NGINX 反向代理实现基本路由配置。 名为 Web.Shopping.HttpAggregator 的 ASP.NET Core Web API 将多个请求合并为一个请求。 这种模式称为网关聚合。

在实际方案中，请使用托管 API 网关服务，例如 Azure API 管理。

优惠券服务

微服务非常小，足以使功能团队在一天内多次独立生成、测试和部署到生产环境，而不会影响其他系统。 在本模块中，你将完成名为 Coupon.API 的 ASP.NET Core 微服务项目，并将其部署到生产中现有的 eShopOnContainers 应用中。 在进行此操作的过程中，你还将了解以下内容：

• 使用域驱动设计 (DDD) 设计微服务。
• 使用 Docker 将服务容器化。
• 将容器映像发布到容器注册表。
• 将容器部署到现有的 Kubernetes 群集。

在体系结构关系图中，蓝色虚线框括入部分为要添加的优惠券服务。

参考：https://learn.microsoft.com/zh-cn/training/modules/microservices-aspnet-core/3-solution-architecture