标签:架构 sequence 生成 container 复杂 environ private control 自己
Catalog microservice(目录微服务)维护着所有产品信息,包括库存、价格。所以该微服务的核心业务为:
如上图所示,本微服务采用简单的数据驱动的CRUD微服务架构,来执行产品信息的创建、读取、更新和删除(CRUD)操作。
这种类型的服务在单个 ASP.NET Core Web API 项目中即可实现所有功能,该项目包括数据模型类、业务逻辑类及其数据访问类。其项目结构如下:
核心技术选型:
Polly
该微服务的核心领域实体是商品,其类图如下:
对于实体这一块,有两个小知识点需要说明一下:
ForSqlServerUseSequenceHiLo
指定使用HI-LO
高低位序列进行主键生成。CatalogController
的构造方法中,明确指定以下代码来进行查询优化,这一点也是我们值得学习的地方。((DbContext)context).ChangeTracker.QueryTrackingBehavior = QueryTrackingBehavior.NoTracking;
Polly
开启了Retry机制。private Policy CreatePolicy( ILogger<CatalogContextSeed> logger, string prefix,int retries = 3)
{
return Policy.Handle<SqlException>().
WaitAndRetryAsync(
retryCount: retries,
sleepDurationProvider: retry => TimeSpan.FromSeconds(5),
onRetry: (exception, timeSpan, retry, ctx) =>
{
logger.LogTrace($"[{prefix}] Exception {exception.GetType().Name} with message ${exception.Message} detected on attempt {retry} of {retries}");
}
);
}
public async Task SeedAsync(CatalogContext context,IHostingEnvironment env,IOptions<CatalogSettings> settings,ILogger<CatalogContextSeed> logger)
{
var policy = CreatePolicy(logger, nameof(CatalogContextSeed));
await policy.ExecuteAsync(async () =>
{
//...
});
}
你肯定会好奇为什么会多了一张IntegrationEventLog
表,这里先按住不表。
如果eShopOnContainers采用的是单体式应用架构而非微服务架构,那么以上业务逻辑的实现并不复杂,使用简单的CRUD再辅以ACID事务就能很好的完成业务需求。本文的介绍也就可以到此为止了。
然而将其抽取出来成为独立的基础微服务,那么我们要考虑的问题就多了。比如:
而这一切我们都不能再享受单体应用中直接使用ACID事务的便利了。因为在微服务应用里,产品表和购物篮表被各自的微服务所占有。任何微服务不应该在自己的事务中包含其他微服务的表或存储,即使是直接查询也是不可以的。目录微服务不能直接更新购物篮表,因为购物篮表被购物篮微服务占有。要更新购物篮微服务,产品微服务应该使用基于异步通信,如集成事件(消息和基于事件的通信)来实现最终一致性。
那下一节我们就来详细阐述eShopOnContainers是如何通过事件机制完成最终一致性的。
eShopOnContainers 知多少[4]:Catalog microservice
标签:架构 sequence 生成 container 复杂 environ private control 自己
原文地址:https://www.cnblogs.com/sheng-jie/p/10035771.html