從壹開始微服務 [ DDD ] 之終篇 ║當事件溯源 遇上 粉絲活動

2、事件溯源的執行過程

這個時候你仔細想一想，我們在和領域專家 （預設他們不懂技術）討論使用者下單 流程的時候，專家一定會說：客戶首先選擇一個商品，然後新增到購物車，確認無誤下單，接著使用者支付，支付成功後，就給使用者發貨。而我們呢，我們作為一個開發人員，和領域專家討論的時候，自然而然的也是這麼思考的，對不對！（你肯定在討論需求的時候用的不是資料庫的思維！），只不過我們後期開發的時候，拘泥於技術和資料優先 的思維，不得不轉向CURD 的道路了，當然這個沒有什麼錯誤，我只是說明一點，事件儲存真的離我們不遠。

那我們平時是怎麼做的呢，這裡說一個特別簡單的：

從這個特別簡單的流程中我們可以看到，平時我們都是直接操作的 Order 這個領域聚合根，一直在修改模型狀態，這個看似正常的操作下，有一些問題，是我們建立在每一步都正常執行的情況下，不過一般總會出現一些問題，特別是分散式的環境中。

然而，事件溯源與上述的情況恰好相反，它並不關心當前狀態，而是關注持續不斷的變化事件。

舉個例子，假設我們有一個“購物車”，我們可以建立購物車，往裡面新增商品或移除商品，然後結賬。

購物車的生命週期可以包含如下一系列事件：

建立購物車

往購物車裡新增商品

再次往購物車裡新增商品

從購物車裡移除商品

結賬

這些就是一個購物車的生命週期，包含了一系列事件。這就是事件溯源，非常簡單吧？

幾乎所有的流程都可以被看成一系列事件。在與領域專家交談時，他們不會提及“表”和“連線”，他們會將流程描述成一系列事件以及可以應用在這些事件上的規則。

3、事件溯源是如何更新實時狀態的

那麼，事件到底如何影響一個領域物件的狀態的呢？很簡單，當我們在觸發某個領域物件的某個行為時，該領域物件會先產生一個事件，然後該物件自己響應該事件並更新其自己的狀態，同時我們還會持久化在該物件上所發生的每一個事件；這樣當我們要重新得到該物件的最新狀態時，只要先建立一個空的物件，然後將和該物件相關的所有事件按照事件發生先後順序從先到後再全部應用一遍即可還原得到該物件的最新狀態，這個過程就是所謂的事件溯源。

二、事件溯源的存在意義與問題

事件溯源不是萬能的，不過它可以在某一些領域發揮很大的作用，這個在以後的微服務設計中，會更能體現出來，那我們就簡單說兩點：

1、傳統應用中出現的某些問題

從業務的角度

傳統的應用中，資料庫裡存的是Domain Model的例項的當前狀態，比如某個儲戶銀行賬戶的存款數 ，通常是一個數字.如果考慮到如下的三個情形,我們可能付出的代價比較大：

１) 老規則：問題跟蹤

如果某個儲戶的賬戶出現問題，那麼我們只有從大到PB的日誌中去分析使用者的賬戶資料是如何出錯的，而且我們在做日誌的時候，不可能所有的都考慮到，就算是把全部資料都儲存，時間都記下來，操作者都備份，那ATM機資訊呢？（可能不恰當，只是說明我們總有想不到的地方），但如果一旦日誌不夠詳細，找出問題根源基本只能靠猜了。

２) 新需求：趨勢分析

歷史資料的作用在於分析未來的趨勢，如果僅僅從浩如煙海的日誌中尋找規律，我們還得單獨寫邏輯，對日誌進行建模，清洗，其實我們已經能接受，日誌就是用來記錄異常資訊的，這個時候我們就很崩潰了。

３) 更奇葩：事務回滾

在介紹事務修正模式中，我們講到某個步驟發生錯誤，之前的各個節點可以自己獨立地完成回滾，回滾的依據就是記錄的操作步驟及相關引數，根據這些有用資訊就可以每個節點自行回滾到原始狀態，並且在失敗的時候可以retry

可見儲存對於Domain Model 的各個事件還是非常有用的,尤其是對於複雜的系統，這也就是我們今天要討論的事件溯源模式.

這是一個大問題。在以表作為驅動的系統裡，你只儲存了系統的當前狀態，你根本就無法知道系統是如何達到當前狀態的。如果我問你“這個使用者修改了幾次郵件地址”，你有辦法回答嗎？或者我再問“有多少人把一件商品新增到購物車裡，然後又移除掉，直到一個月之後才買了那件商品”，你就更沒法回答了。你儲存資料的方式丟掉了很多有用的業務資訊！

4、什麼時候使用這種模式

這種模式在以下幾種場景中是最理想的解決方案：

• 當你想獲得資料的“意圖”，“目的”或者“原因”的時候。 例如，一個客戶的實體改變可能用一系列的類似於”搬家“，”登出賬戶“或者”死亡“等事件型別。
• 併發更新資料時候非常需要減少或者完全避免衝突的時候。
• 當你需要儲存已經發生的事件，並且能夠重播他們來還原到某個狀態、使用這些事件去回滾系統的某些變化或者僅僅是歷史或者審查記錄的時候。例如 ，當一個任務包括幾個步驟，你可能需要執行一個撤銷更新的操作然後重播過去的每個步驟來回到穩定的狀態。
• 當使用事件是一些應用程式的某些操作的天然屬性，並且需要很少的額外擴充套件或者實施的時候。
• 當你需要把插入，更新資料和需要執行這些操作的應用程式解耦開的時候。用這種模式可以提高UI的效能，或者把這些事件分發給其他的監聽者，比如有些應用程式或系統，它們在一些事件發生的時候必須做出一些反應。例如，將一個工資系統和一個報銷系統結合起來，這樣的話當報銷系統更新一個事件給事件資料庫，資料庫對此做出的相應事件就可以被報銷系統和工資系統共享。
• 當要求變更或者——當和CQRS配合使用的時候——你需要適配一個讀的模型或者檢視來顯示資料，而你想要更靈活地改變物化檢視的格式和實體資料的時候。
• 當和CQRS配合使用的時候，並且當一個讀模型被更新時能接受資料的最終一致性問題，或者說從一系列的事件序列中生成實體對效能的影響可以被接受。

這種模式在以下幾種場景中可能並不適用：

• 小而簡單的，業務邏輯簡單或者根本沒有業務邏輯，或者領域概念的，一般傳統的增刪改查（CURD）就能實現功能的業務領域，或者系統。
• 需要實時一致和實時更新資料的系統。
• 不需要審查，歷史和回滾的系統。
• 併發更新資料可能性非常小的系統。例如，只增加資料不更新資料的系統。

5、ES 和 CQRS 的關係

CQRS與事件溯源有著相輔相成的關係。CQRS允許事件溯源作為領域的資料儲存機制。然而，使用事件溯源的一個最大的缺點是，你無法向你的系統提出類似“請告訴我所有名字為Greg的使用者”這樣的問題，這是由於事件溯源無法提供物件的當前狀態而引起的。CQRS唯一支援的查詢就是：GetById - 通過ID來獲得某個聚合。下圖為基於CQRS/ES的應用系統結構：

CQRS經常和事件溯源模式結合使用

基於CQRS的系統使用分離的讀和寫模型，每一個都對應相應的任務並且一般儲存在不同的資料庫中。當和事件溯源模式一起使用的時候，一系列的事件儲存相當於“寫”模型，是所有資訊的可信賴來源（authoritative source ）。基於CQRS的系統的讀模型提供了資料的物化檢視，經常是一種高度格式化的檢視形式。這些檢視對應相應的介面並且展示了應用程式的需求，幫助最大化展示和查詢效率。

使用一系列的事件當作“寫”而不是某一個時間點的資料，避免了更新的衝突並且最大化效能和系統的伸縮性，這些事件可以被非同步地產生被用來展示資料的物化檢視。

因為事件資料庫是所有資訊的可信賴來源，當系統改進的時候，有可能刪除物化檢視並且展示所有過去的時間來產生一個新的資料，或者當讀模型必須改變的時候。物化檢視是一個長久的資料快取。

當將CQRS和事件溯源模式結合起來的時候，考慮以下幾點：

• 對於任何的讀寫分離儲存的系統，這些系統基於事件溯源模式都是“最終一致”的。因此在事件產生和資料儲存之間會有一些延遲。
• 這種模式會造成一些額外的複雜度，因為程式碼必須要能夠初始化和處理事件，然後組合或者更新相應的讀寫模型需要檢視或者物件。這種複雜度會對讓系統的實現變得有些困難，需要重新學習一些概念和一個不同的設計系統的方式。然而事件溯源可以讓為領域建模，讓重建檢視或者物件更加容易。
• 生成物化檢視

CQRS最核心的概念是Command、Event，“將資料(Data)看做是事實(Fact)。每個事實都是過去的痕跡，雖然這種過去可以遺忘，但卻無法改變。” 這一思想直接發展了Event Source，即將這些事件的發生過程記錄下來，使得我們可以追溯業務流程。CQRS對設計者的影響，是將領域邏輯，尤其是業務流程，皆看做是一種領域物件狀態遷移的過程。這一點與REST將HTTP應用協議看做是應用狀態遷移的引擎，有著異曲同工之妙。

在核心應用層 Christ3D.Domain.Core 的 Events資料夾下，新建 Message.cs 用來獲取我們事件請求的型別：

namespace Christ3D.Domain.Core.Events
{
/// <summary>
/// 抽象類Message，用來獲取我們事件執行過程中的類名
/// 然後並且新增聚合根
/// </summary>
public abstract class Message : IRequest
{
public string MessageType { get; protected set; }
public Guid AggregateId { get; protected set; }

protected Message()
{
MessageType = GetType().Name;
}
}
}

同時在該資料夾下，新建 儲存事件 模型StoredEvent.cs

public class StoredEvent : Event
{
/// <summary>
/// 構造方式例項化
/// </summary>
/// <param name="theEvent"></param>
/// <param name="data"></param>
/// <param name="user"></param>
public StoredEvent(Event theEvent, string data, string user)
{
Id = Guid.NewGuid();
AggregateId = theEvent.AggregateId;
MessageType = theEvent.MessageType;
Data = data;
User = user;
}

// 為了EFCore能正確CodeFirst
protected StoredEvent() { }
// 事件儲存Id
public Guid Id { get; private set; }
// 儲存的資料
public string Data { get; private set; }
// 使用者資訊
public string User { get; private set; }
}

namespace Christ3D.Infra.Data.Mappings
{
/// <summary>
/// 事件儲存模型Map
/// </summary>
public class StoredEventMap : IEntityTypeConfiguration<StoredEvent>
{
public void Configure(EntityTypeBuilder<StoredEvent> builder)
{
builder.Property(c => c.Timestamp)
.HasColumnName("CreationDate");

builder.Property(c => c.MessageType)
.HasColumnName("Action")
.HasColumnType("varchar(100)");
}
}
}

2、然後再上下文資料夾 Context 下，新建事件儲存Sql上下文 EventStoreSQLContext.cs

namespace Christ3D.Infra.Data.Context
{
/// <summary>
/// 事件儲存資料庫上下文，繼承 DbContext
/// 
/// </summary>
public class EventStoreSQLContext : DbContext
{
// 事件儲存模型
public DbSet<StoredEvent> StoredEvent { get; set; }

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.ApplyConfiguration(new StoredEventMap());

base.OnModelCreating(modelBuilder);
}

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
// 獲取連結字串
var config = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json")
.Build();

// 使用預設的sql資料庫連線
optionsBuilder.UseSqlServer(config.GetConnectionString("DefaultConnection"));
}
}
}

namespace Christ3D.Infra.Data.Repository.EventSourcing
{
/// <summary>
/// 事件儲存倉儲介面
/// 繼承IDisposable ，可手動回收
/// </summary>
public interface IEventStoreRepository : IDisposable
{
void Store(StoredEvent theEvent);
IList<StoredEvent> All(Guid aggregateId);
}
}

2、然後對上邊的介面進行實現

namespace Christ3D.Infra.Data.Repository.EventSourcing
{
/// <summary>
/// 事件倉儲資料庫倉儲實現類
/// </summary>
public class EventStoreSQLRepository : IEventStoreRepository
{
// 注入事件儲存資料庫上下文
private readonly EventStoreSQLContext _context;

public EventStoreSQLRepository(EventStoreSQLContext context)
{
_context = context;
}

/// <summary>
/// 根據聚合id 獲取全部的事件
/// 這個聚合是指領域模型的聚合根模型
/// </summary>
/// <param name="aggregateId"> 聚合根id 比如：訂單模型id</param>
/// <returns></returns>
public IList<StoredEvent> All(Guid aggregateId)
{
return (from e in _context.StoredEvent where e.AggregateId == aggregateId select e).ToList();
}

/// <summary>
/// 將命令事件持久化
/// </summary>
/// <param name="theEvent"></param>
public void Store(StoredEvent theEvent)
{
_context.StoredEvent.Add(theEvent);
_context.SaveChanges();
}

/// <summary>
/// 手動回收
/// </summary>
public void Dispose()
{
_context.Dispose();
}
}
}

這個時候，我們的事件儲存模型、上下文和倉儲層已經建立好了，也就是說我們可以對我們的事件模型進行持久化了，接下來就是在建立服務了，用來呼叫倉儲的服務，就好像我們的應用服務層的概念。