架构 - zilor-net/eShopOnContainers-CN-Wiki GitHub Wiki

概览

这是一个支持服务端和客户端都跨平台的 .NET Core 应用，它能够运行在 Linux 或 Windows 的 Docker 容器上，它还有一个支持Android、IOS 和 UWP 的 Xamarin 移动应用程序，以及 ASP.NET Core Web MVC 和 SPA 应用。

该应用采用了面向微服务的架构，整个架构中包含了多个独立自治的微服务，每个微服务都拥有自己的数据库。这些微服务展示了从简单的 CRUD，到更复杂的 DDD/CQRS 模式的不同实现。

HTTP 是客户端应用和微服务之间的通信协议，同时也是微服务之间基于异步消息的通信协议。

消息队列则通过 RabbitMQ 或者 Azure Service Bus 来处理，可以用来传递集成事件。

在订购微服务（ordering microservice）中，领域事件通过使用 MediatR 来处理，MediatR 是中介者模式的一个简单的进程内实现。

事件总线

eShopOnContainers 包含了一个简化的事件总线(EventBus)组件来处理集成事件，这个组件有两个实现，一个基于 RabbitMQ，另一个基于 Azure Service Bus。

对于生产级别的解决方案，你应该使用更加健壮的实现，比如 NServiceBus，这是一个健壮的产品。

gRPC

微服务之间的大多数通信都是通过使用事件总线和“发布/订阅”模式进行解耦的。

然而，自定义聚合器和内部微服务之间的通信，目前是用 gRPC 实现的，替代了 HTTP/JSON。

gRPC 是一种基于 RPC 的协议，它具有良好的性能和低带宽利用率，使其成为内部微服务通信协议的最佳选择。

关于 gRPC 和 eShopOnContainers 的更多信息，可以在本 wiki 的 gRPC 文章中找到：

https://github.com/dotnet-architecture/eShopOnContainers/wiki/gRPC.md。

API 网关

该架构还包含了 API 网关，以及 BFF 模式的实现，用于发布简化的 API。

并且包含了额外的安全措施，用于隐藏/保护内部的微服务，不让客户端应用程序或外部消费者看到。

这些 API 网关是使用 Envoy 实现的。Envoy 是一个开源的面向生产级别的高性能的服务代理和 API 网关，专为云原生应用设计。

目前，API 网关只执行将请求转发给内部微服务和自定义聚合器的操作，让客户端能够使用一个单一的 Base URL。

未来可能实现的功能有：

自动转换 gRPC 到 HTTP/REST，反之亦然
认证和授权管理
提供缓存支持

如果你需要更多适合商业的 API 功能和更丰富的特性，你也可以在这些 API 网关上添加一个完整的 API 网关产品，比如 Azure API 管理。

API 网关还提供了一组“定制聚合器”。这些聚合器为客户端提供了一些操作的简单 API。

目前有两个聚合器：

Mobile Shopping: 被 Xamarin 应用程序购物操作调用的聚合器
Web Shopping: 被 Web 客户端(MVC & SPA)购物操作调用的聚合器

注意：上一个版本的 eShopOnContainers 使用 Ocelot 替代 Envoy。Ocelot 是一个很不错的用来创建 API 网关的 .Net Core 开源项目。Ocelot 支持的特性很广泛，它应该是所有基于 .NET Core 项目的重要选择。然而，它缺乏对gRPC的支持，这是在 eShopOnContainers 中将 Ocelot 换成的 Envoy 的主要原因。

内部架构模式

取决于不同的目的，这些微服务的类型并不相同，它们的内部有不同的架构模式，如下图所示：

数据库服务器

该架构有四个 SQL Server 数据库，为了保持尽可能低的内存需求，它们都被部署在一个容器中。对于生产部署，不推荐使用这种方法，在生产部署中应该使用高可用性解决方案。

还有一个 Redis 和一个 MongoDb 实例，分别位于不同的容器中，它们作为两个广泛使用的 NO-SQL 数据库的示例。