转载

关于事件溯源是否属于过度营销的银弹？ - Alexey

大多数微服务架构都需要事件溯源吗？微服务之间使用RESTful依赖是表明还是一个单体架构吗？

1. 事件溯源不是架构或体系结构模式，它是保存实体状态的方式，仅此而已。

如果你有一个仓库接口，喜欢OrderRepository用类似的方法Add和Update，你可以将其转换为使用事件溯源。如果您的存储库中有查询-会遇到麻烦。我不喜欢仅在存储库中进行查询，因为存储库表示实体的集合，而查询通常需要超出此范围。这时候需要CQRS！

CQRS仅保证：更新实体状态时您可以优化事务的操作；运行查询时您可以对其进行优化以进行报告。这就是为什么我不建议在存储库中查询的确切原因。报表模型通常对您的域模型不感兴趣，但对整个系统的状态却很感兴趣。因此，查询通常超出实体的界限，并且限制查询只能使用一种实体类型成为一种负担。

CQRS具有其双重性质。一方面，Greg Young多次表示CQRS只是迈向事件采购的垫脚石。同时，CQRS也不是事件源的一部分。构建事件源系统时，它变得非常有用。

2. 事件溯源隐藏大量复杂性。

这不是真的，事件溯源社区根据他们自己的经验，不断展示问题和克服问题的方法。DDD Europe组织了第一场专门用于事件源的活动，我荣幸地策划了这一活动，并且我们进行了很多案例研究和经验分享会议。例如，Dennis Doomen经常在许多论坛上分享他的经验，因此请查看。

验丰富的开发人员（在本文的后面引用）使用的ORM工具是否不具有大量的复杂性？

在设计和构建事件源系统时，我犯了很多错误，直到我意识到大多数复杂性是人为的并且可以避免的。

3.使用RPC交互的微服务主要有什么问题？

RPC本质上引入的高度耦合。如果仅其中一项服务停止工作，则整个服务组甚至整个系统都可能崩溃。这种方法减少了独立组件的整个想法。

微服务的松散耦合是通过使用REST模式通过https进行通信并对微服务公开的端点进行版本控制来实现的。微服务之间的这些依赖关系并不理想。其他微服务可能会关闭，基于HTTP的同步RESTful请求由于其阻塞性质而无法很好地扩展。

即使没有事件溯源，我们也可以使用事件驱动异步通信并在服务之间交换信息。

4.事件是不变的，不能修改的

有人说事件溯源为您提供了时间旅行：您可以返回以前事件日志，查看发生了什么以及出于什么原因。我想说的是，出于相同的目的，它为您提供了您的域的故事。时间旅行的悖论在于，当您回到“现在的时间”时，您会扭曲改变过去事件并遇到无法预料的后果。我声称这就是在面向状态的系统世界中发生的事情。

我们更改“现在”，希望我们将其纠正为应有的状态，而忽略之前发生的事情。可以肯定的是，我们相信大多数时候我们都会“纠正”系统状态，但是它与欺骗财务数字，试图将债务调整为利润有何不同？我们却不知道系统是如何到达这种纠正后状态的，我们认为这是不正确的，

不同于基于事实溯源的分类帐系统，但是您可以进行有针对性的纠正措施，也称为补偿措施，也可以记录下来，并可以用作纠正措施的证据。我们可能会争辩说它更复杂，但是与更改表中的数据相比呢？后者不会留下任何此类入侵的痕迹。

通常，当我选择了错误的模型并使用基于状态的持久性时，我发现自己处在这种情况下，因为它很“容易”：我不需要记录事件，而是不断更改系统状态。

5. 数据库CRUD与DDD

使用微服务构建分布式系统并保持CRUD模型？我简直不敢相信它真的可以工作。查看以下一些视频以了解更多信息：

DDD挪威聚会：没有DDD的微服务是冒险的业务！由Trond Hjorteland
GOTO 2015： DDD和微服务：最后，有些界限！埃里克·埃文斯（Eric Evans）

微服务之间讨论事件驱动通信与RPC调用的这种想象中的复杂性的全部原因可能是由于服务边界不正确导致的，而错误的服务边界又导致了过多的跨服务通信以及它们之间的循环依赖性，从而导致高度耦合的分布式没有一个组件真正具有凝聚力的系统。

实际上，DDD和事件源是正交的。确实，格雷格·杨（Greg Young）积极地倡导这两者，只是因为这很有意义。DDD与微服务无关，也与架构无关。它与了解软件的领域，业务和用户有关。这些都是任何软件质量的基本方面，除非您要构建Hello World应用程序。

熟悉领域会导致目的明确的软件。我们都处理过这样的系统，其中的动作是秘密的，一切看起来都像是RDMBS中表的表示。没有人喜欢这种软件。我们喜欢漂亮的现代应用程序：其中所有内容是结构化的且具有针对性，都能快速有效地完成我们想要的事情。我很难想象，如果没有对领域的正确理解，开发人员团队能构建出任何接近该目标的东西？

6. Apache Kafka似乎非常适合事件源

不，它没有，仅仅是因为它没有事件流的概念，而是处理主题和分区。(banq注：作者可能不了解Kafka, Kafka Stream是一种事件流)

请查看JesperHammarbäck 的 Apache Kafka不是有关事件源的文章，以了解更多信息。

诸如 EventStoreDB之类的专用构建软件可能是从一开始就做好事情并在以后解决规模问题时的选择。

原文 https://www.jdon.com/54573

正文到此结束