引言
Catalog microservice（目錄微服務）維護着所有產品信息，包括庫存、價格。所以該微服務的核心業務為：
- 產品信息的維護
- 庫存的更新
- 價格的維護
架構模式
如上圖所示，本微服務采用簡單的數據驅動的CRUD微服務架構，來執行產品信息的創建、讀取、更新和刪除（CRUD）操作。
這種類型的服務在單個 ASP.NET Core Web API 項目中即可實現所有功能，該項目包括數據模型類、業務邏輯類及其數據訪問類。其項目結構如下：
核心技術選型：
- ASP.NET Core Web API
- Entity Framework Core
- SQL Server
- Swashbuckle（可選）
- Autofac
- Eventbus
- Polly
實體建模
該微服務的核心領域實體是商品，其類圖如下：
對於實體這一塊，有兩個小知識點需要說明一下：
- 進行數據庫字段映射時，主鍵都使用了
ForSqlServerUseSequenceHiLo指定使用HI-LO高低位序列進行主鍵生成。 - 使用NoTracking提升查詢速度
在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是如何通過事件機制完成最終一致性的。