事件源和微服务、消息传递系统

Question

我们正在设计我们的新系统，它很可能是从头开始编写的，因为旧系统非常非常旧。对我们的系统来说，保留系统中发生的所有事情的审计跟踪日志非常重要。

由于审计跟踪的重要性，我们决定遵循事件源架构以获得它的所有好处。另一个关键因素是我们有多个团队在不同的“域”上工作。也就是说，我们想将每个域拆分为自己的服务（微服务架构），这样每个团队都可以独立工作。

我们面临的最大问题是谁将负责微服务之间的事件共享。例如，在其中一个服务中发生的事件也应触发其他两个服务中的另一个事件。我们可以看到两种选择：

• 中央流媒体服务（最有可能是AWS），所有服务都注册发布者和订阅者。每个服务都将在那里发布其所有事件，消费者将决定他们是否“关心”特定事件，然后做些什么

我们已经花了很多时间试图找出什么是对我们来说最好的选择，或者我们应该问自己什么问题才能做出正确的决定。我更倾向于第一种选择，尽管我确实对消费者的性能和瓶颈有一些担忧，因为每个服务都会听取所有事件，然后他们会决定是否必须采取行动。

你认为第一个选项或第二个选项有什么不可行的地方吗？我们是朝着正确的方向看，还是应该后退一步？

Answer 1

你做过简单的练习吗

注意，“解决方案优先级”指的是系统质量属性，如性能、可维护性、可测试性等，但也要考虑到您可能拥有的架构原则、产品所有者的功能优先级、商业驱动因素等。

为了更直接地回答OP，我将从一个单一的事件流开始：你把所有东西都放在一个地方，这更简单：更容易设置和管理、调试、监控等。拆分东西只会增加复杂性。当然，可以随意拆分——但前提是有明确的理由这样做。

Answer 2

我倾向于每个发布服务都有一系列事件。然后，您可以进行某种程度的分类，当您希望按排放顺序处理事件时，不必（或至少不必）处理多个流的同步消耗。

事件通常会有一个自然键，并且您通常只需要在按该键分组后进行严格排序；因此，您可以对事件进行分区/切分。

没有什么本质上阻止您同时拥有发布服务发出的所有事件的Firehose流和事件的分类流，以便消费者可以决定不订阅他们不感兴趣的流。