我正在尝试使用CQRS，DDD和事件采购概念开发在线商店的微服务。我将AWS Kinesis视为事件流。我认为这对精心设计的微服务有好处。我有2项服务，客户数据服务和订购系统服务。我想查看未付订单的总数以及每个客户的订单总数。因此，我应该将orderCreated事件和orderPaid事件发送给服务以获取客户数据，并重新计算相关客户的未付订单总数和订单总数。
我可以将订购系统事件放入AWS Kinesis并在客户的命令端服务中监听吗？我应该将事件（orderCreated和orderPaid事件）从AWS Kinesis持久保存到客户命令端服务中的数据库吗？或者仅仅更新客户查询端服务是否可以？我应该使用AWS Lambda作为事件处理器吗？你能给我一些这个模型的最佳实践吗？
提前致谢。
答案 0 :(得分：0)
我将AWS Kinesis视为事件流。我认为这对精心设计的微服务有好处。
我认为这不是Kinesis设计的用例;见overview by Aditya Krishnan。或者之前的question on stack overflow。
我应该将事件（orderCreated和orderPaid事件）从AWS Kinesis持久存储到客户端命令端服务中的数据库吗？
从我的角度来看，问题是这样的：你真的不希望事件泄漏给订阅者然后没有出现在记录簿中。因此，通常的顺序是将事件放入持久存储中，并且只有在您获得写入确认（这是“我们已达到最低持久性保证的确认”的代理）之后，您才开始共享事件进行。
因此，大多数设计都会颠倒您建议的顺序 - 耐用存储（数据库）优先，发布第二。但是你正在失去潜伏期;订阅者在商店完成之前无法看到该事件。根据您的设计，您可以通过批量读取来弥补其中的一部分。
嗯，鉴于我在Kinesis的建议中所看到的，看起来你不会超过order of magnitude而超过它;他们似乎建议使用全管而不是快管。我们尝试过SQS和SNS。但是，表现还不够好。发布和使用事件大约需要5秒钟。