微软微服务参考架构eShopOnContainers到底解决了哪些实际问题？

eShopOnContainers是微软开源的一套面向.NET开发者的微服务架构参考示例，它模拟了一个简化版的电商系统，将传统单体应用拆分为多个独立部署的服务。项目覆盖了从后端API、消息通信到前端SPA以及移动端的完整链路，目的是让开发者通过真实代码理解微服务落地细节。

整体架构与服务划分

在eShopOnContainers中，业务被切分为多个自治服务，每个服务拥有自己的数据库与技术选型自由度。例如身份服务负责认证授权，目录服务管理商品数据，购物车服务维护用户临时选购状态，订单服务处理下单与库存扣减。这种划分方式让团队可以按需伸缩特定模块，而不必整体扩容。

各服务通过HTTP REST或gRPC对外暴露接口，同时借助RabbitMQ实现的事件总线进行异步协作。比如订单创建成功后抛出OrderStarted事件，购物车服务订阅该事件以清空对应购物车。相比直接同步调用，事件驱动降低了服务间的强依赖，也提升了系统在部分节点故障时的韧性。

API网关与客户端聚合

微服务暴露大量细粒度接口，如果让前端直连各个服务，会产生繁琐的跨域与路由逻辑。eShopOnContainers采用Ocelot作为API网关，统一接收外部请求并转发到内部服务，同时集中处理鉴权与限流。

以下代码展示了Ocelot配置文件中对两个下游服务的路由映射：

{
  "ReRoutes": [
    {
      "DownstreamPathTemplate": "/api/catalog",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        { "Host": "catalog.api", "Port": 80 }
      ],
      "UpstreamPathTemplate": "/catalog",
      "UpstreamHttpMethod": [ "Get" ]
    },
    {
      "DownstreamPathTemplate": "/api/orders",
      "DownstreamScheme": "http",
      "DownstreamHostAndPorts": [
        { "Host": "ordering.api", "Port": 80 }
      ],
      "UpstreamPathTemplate": "/orders",
      "UpstreamHttpMethod": [ "Post" ]
    }
  ]
}

通过这种配置，客户端只需要知道网关地址，不必关心背后服务的具体容器名与端口。当后端服务实例数变化时，只需调整网关配置或结合服务发现即可，对前端透明。

容器化与编排实践

所有服务在eShopOnContainers中均以Docker容器形式打包，配合docker-compose可在单机完成一键启动。生产环境则推荐使用Kubernetes托管，项目提供了对应的部署清单。

下面是一个目录服务的Dockerfile片段，它基于.NET SDK镜像编译后再切入运行时镜像，保证最终镜像体积可控：

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY Catalog.API.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /out

FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build /out .
ENTRYPOINT ["dotnet", "Catalog.API.dll"]

容器化让环境差异被消除，开发者在笔记本上跑起来的镜像和生产集群中完全一致。配合健康检查探针，编排系统能自动重启异常容器，减少人工介入。

弹性与容错设计

在分布式系统中，网络抖动和瞬时故障难以避免。eShopOnContainers集成Polly库，为HTTP调用添加重试、熔断与超时策略。

示例代码中为访问目录服务客户端添加了重试与降级：

services.AddHttpClient<ICatalogService, CatalogService>()
    .AddPolicyHandler(GetRetryPolicy())
    .AddPolicyHandler(GetCircuitBreakerPolicy());

static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)));
}

当下游服务短暂不可用时，调用方不会立刻失败，而是按指数退避重试；若错误率过高则打开熔断器，避免雪崩。这种轻量模式比引入重型中间件更易理解与维护。

事件总线与最终一致性

跨服务的写操作无法用本地数据库事务保证，eShopOnContainers使用基于RabbitMQ的事件总线实现最终一致性。服务在完成本地事务后发布领域事件，其他服务消费并更新自身状态。

事件发布代码通常如下：

public class OrderStartedDomainEvent : INotification
{
    public string UserId { get; }
    public OrderStartedDomainEvent(string userId) => UserId = userId;
}

await _mediator.Publish(new OrderStartedDomainEvent(order.UserId));

订阅方通过实现INotificationHandler处理事件。若消费失败，可借助死信队列排查，而不阻塞主流程。该方案牺牲了强一致，换取了系统整体可用性与扩展能力。

适用场景与局限性

eShopOnContainers适合作为学习微服务拆分、容器编排与.NET云原生开发的起点。中小团队可参照其目录结构快速搭建原型。

但它并非万能模板：示例为了简化，部分服务仍共享数据库模式，真实业务需更严谨的边界上下文划分；另外事件总线的消息追踪与幂等处理在高压场景下需要额外投入。理解其设计取舍，才能避免盲目套用。

eShopOnContainersmicroservices.NET_Core修改时间：2026-08-09 00:21:28