AWS Kinesis微服務編程

Question

我正在嘗試開發使用CQRS，DDD和Event sourcing概念的在線商店的微服務。我將AWS Kinesis視爲事件流。我認爲這對於編排微服務是很好的。我有2個服務，客戶數據服務和訂購系統服務。我希望看到每個客戶的未付訂單總數和訂單總量。因此，我應該向客戶數據服務發送orderCreated事件和orderPaid事件，並重新計算相關客戶的總未付訂單和總訂單數。

我可以將訂購系統事件放到AWS Kinesis上，並在客戶的命令面服務中進行監聽嗎？我應該將AWS Kinesis中的事件（orderCreated和orderPaid事件）保存到客戶命令端服務中的數據庫中嗎？或者僅僅更新客戶查詢方服務可以嗎？我應該使用AWS Lambda作爲事件處理器嗎？你能否給我一些關於這個模型的最佳實踐？

在此先感謝。

Answer 1

我將AWS Kinesis視爲事件流。我認爲這對於編排微服務是很好的。

我不認爲這是Kinesis設計的用例;請參閱overview by Aditya Krishnan。或此前的question on stack overflow。

是否應該將客戶端命令端服務中的事件（orderCreated和orderPaid事件）從AWS Kinesis持久化到數據庫？

從我的角度來看，這個問題是這樣的：你真的不想事件泄露出來的用戶再沒有出現在書中記錄的。因此，通常的排序是將事件放入持久存儲中，並且只有在您確認寫入（這是「確認已達到我們的最低耐用性保證」的代理）後，纔開始共享事件出。

所以大多數設計都是顛倒你建議的順序 - 耐用存儲（數據庫）第一，發佈第二。但你正在失去潛伏期;訂閱者在商店結束之前不能看到該事件。根據您的設計，您可能可以通過批量讀取來彌補其中的一些問題。

我們嘗試過SQS和SNS。但是，表現還不夠好。大約需要5秒才能發佈和使用這些事件。

嗯，根據我在Kinesis的建議中看到的，看起來你不會超過order of magnitude;他們似乎在推薦全套管道而不是快速管道。