Azure 很适合支持 eShopOnContainers（虽然并不是必需的），因为该项目是为了成为一个云原生应用程序而构建的。 应用程序是用 .NET 构建的，因此它可以在 Linux 或 Windows 容器上运行，具体根据 Docker 主机而定。 该应用程序由多个自主微服务组成，每个都有其自己的数据。 不同的微服务展示了不同的方法，从简单的 CRUD 操作到更复杂的 DDD 和 CQRS 模式。 微服务通过 HTTP 与客户端通信，并通过基于消息的通信彼此之间进行通信。 应用程序也支持客户端的多个平台，因为它采用 HTTP 作为标准通信协议，并包括在 Android、iOS 和 Windows 平台上运行的 ASP.NET Core 和 Xamarin 移动应用。
应用程序的体系结构如图 2-5 所示。 左侧是客户端应用，分为移动、传统 Web 和 Web 单页应用程序 (SPA) 三种类型。 右侧是构成系统的服务器端组件，每个组件都可以托管在 Docker 容器和 Kubernetes 群集中。 传统 Web 应用由显示为黄色的 ASP.NET Core MVC 应用程序提供支持。 此应用和移动及 Web SPA 应用程序通过一个或多个 API 网关与各个微服务进行通信。 API 网关遵循“服务于前端的后端”(BFF) 模式，这意味着每个网关都设计为支持给定的前端客户端。 各个微服务在 API 网关的右侧列出，同时包含业务逻辑和某种类型的持久性存储区。 不同的服务利用了 SQL Server 数据库、Redis 缓存实例和 MongoDB/CosmosDB 存储。 最右侧是系统的事件总线，用于微服务之间的通信。
图 2-5. eShopOnContainers 体系结构。
此体系结构的服务器端组件都可以轻松映射到 Azure 服务。
容器业务流程和群集
可以在 Azure Kubernetes 服务 (AKS) 中托管和管理应用程序的容器托管服务，从 ASP.NET Core MVC 应用到单独的目录和订单微服务都适用。 应用程序可以在 Docker 和 Kubernetes 上本地运行，你也可以将相同的容器部署到 AKS 中托管的暂存环境和生产环境。 可以自动执行此过程，我们将在下一节中看到。
AKS 为容器的各个群集提供管理服务。 应用程序将为 AKS 群集中的每个微服务部署单独的容器，如上面的体系结构关系图中所示。 使用此方法可以让每个单独的服务根据其资源需求进行独立缩放。 每个微服务也可以单独部署，理想情况下，此类部署应会产生零系统停机时间。
API Gateway
eShopOnContainers 应用程序具有多个前端客户端和多个不同的后端服务。 客户端应用程序与支持它们的微服务之间不存在一对一的对应关系。 在这种情况下，将客户端软件编写为以安全方式与各种后端服务进行交互时，可能会有很大的复杂性。 每个客户端都需要自行解决这个复杂的问题，从而导致重复工作，并且随着服务的改变或新策略的实施，需要在很多地方进行更新。
Azure API 管理 (APIM) 帮助组织以一致且可管理的方式发布 API。 APIM 包含以下三个组件：API 网关、管理门户（Azure 门户）和开发人员门户。
API 网关接受 API 调用，并将其路由到相应的后端 API。 它还可以提供额外的服务，如验证 API 密钥或 JWT 令牌，以及在不修改代码的情况下进行 API 转换（例如，为了满足客户对旧界面的期望）。
在 Azure 门户中，可以定义 API 架构并将不同的 API 打包到产品中。 你还可以配置用户访问权限、查看报表以及为配额或转换配置策略。
开发人员门户是开发人员的主要资源。 它为开发人员提供 API 文档、交互式测试控制台，以及关于他们自己使用情况的报告。 开发人员还使用门户来创建和管理自己的帐户，包括订阅和 API 密钥支持。
使用 APIM，应用程序可以公开几个不同的服务组，每个组都为特定的前端客户端提供后端。 对于复杂的应用场景，建议使用 APIM。 为了简化需求，可以使用轻量级 API 网关 Ocelot。 eShopOnContainers 应用使用 Ocelot 是因为它的简易性，也因为它可以和应用程序本身部署在同一个应用程序环境中。 详细了解 eShopOnContainers、APIM 和 Ocelot。
如果你的应用程序正在使用 AKS，另一个选项是将 Azure 网关入口控制器部署为 AKS 群集中的 Pod。 这种方法可以让群集与 Azure 应用程序网关集成，使网关能够将流量负载均衡到 AKS Pod。 详细了解适用于 AKS 的 Azure 网关入口控制器。
数据
eShopOnContainers 使用的各种后端服务具有不同的存储要求。 有几个微服务使用 SQL Server 数据库。 购物篮微服务利用 Redis 缓存来实现持久性。 位置微服务需要将一个 MongoDB API 用于其数据。 Azure 支持这些数据格式。
对于 SQL Server 数据库支持，Azure 拥有从单个数据库到高度可扩展的 SQL 数据库弹性池的所有产品。 可以配置单个微服务，使其能够与它们自己单独的 SQL Server 数据库快速而方便地进行通信。 这些数据库可以根据需要进行扩展，以根据每个独立的微服务的需求提供支持。
eShopOnContainers 应用程序在请求之间存储用户的当前购物篮。 这一方面由购物篮微服务管理，将数据存储在 Redis 缓存中。 在开发过程中，可以将此缓存部署在容器中，而在生产环境中，它可以利用 Azure Cache for Redis。 Azure Cache for Redis 是一种完全托管的服务，提供高性能和可靠性，让你无需自行部署和管理 Redis 实例或容器。
位置微服务将 MongoDB NoSQL 数据库用于实现持久性。 在开发过程中，可以将数据库部署在其自己的容器中，而在生产环境中，服务可以利用 Azure Cosmos DB 的适用于 MongoDB 的 API。 Azure Cosmos DB 的一个优点是它能够利用多种不同的通信协议，其中包括 SQL API 和常见 NoSQL API，包括 MongoDB、Cassandra、Gremlin 和 Azure 表存储。 Azure Cosmos DB 提供了一种完全托管的全球分布式数据库即服务，可进行扩展以满足使用它的服务的需求。
第 5 章中更详细地介绍了云原生应用程序中的分布式数据。
事件总线
应用程序使用事件在不同服务之间传递更改。 此功能可通过各种实现来实现，eShopOnContainers 应用程序在本地使用 RabbitMQ。 托管在 Azure 中时，应用程序将使用 Azure 服务总线进行消息传送。 Azure 服务总线是一种完全托管的集成消息代理，它允许应用程序和服务以分离、可靠、异步的方式相互通信。 Azure 服务总线支持各个队列以及单独的主题，以支持发布服务器-订阅服务器的方案。 eShopOnContainers 应用程序将利用与 Azure 服务总线相关的主题，支持将消息从一个微服务分发到任何其他需要响应给定消息的微服务。
复原
在部署到生产环境后，eShopOnContainers 应用程序将能够利用几项 Azure 服务来改善其复原能力。 应用程序发布运行状况检查，这些检查可以与 Application Insights 集成，以根据应用的可用性提供报告和警报。 Azure 资源还提供了可用于识别和更正 bug 和性能问题的诊断日志。 资源日志提供了关于应用程序何时以及如何使用不同 Azure 资源的详细信息。 第 6 章详细介绍了有关云原生复原能力的各项功能的详细信息。
