微服务架构中的服务应该有“事件”吗？

Question

我正在寻找某种关于某事的最佳实践： 在我们的应用程序中，我们有很多服务，它们之间有很多交互。

某些服务需要能够通知其端发生了变化。 我们直观的开发人员方法是只在其中注册一个事件并在其上注册。但我觉得这有点“肮脏”。

对我来说，服务是“提供”给请求它的人的东西，而且是，但我们不应该知道服务的生命周期（也不应该阻止服务的服务垃圾收集，因为有人是仍然注册。

我的选择是：

• 向服务请求一个对象，我将在该对象上注册事件--> 我觉得没有这么干净
• 向服务提供实现 CallBack 接口的对象，让服务调用回调而不是通知事件。
• ???

您认为这方面的最佳做法是什么？什么是最干净的方法？

Answer 1

有一个已知的模式，CQRS（命令查询责任分离），你会发现很多关于如何通过事件来实现它的例子，称为 EventSourcing。您不需要使用 EventSourcing，您只需发布到队列并订阅回以处理请求，您也可以轻松扩展您的架构

在 C# 中，有一个事件溯源框架，https://github.com/gautema/CQRSlite，以及来自 Sacha 的关于如何使用的很好的解释，https://www.codeproject.com/articles/991648/cqrs-a-cross-examination-of-how-it-works 你也可以在这里找到更多细节，https://www.youtube.com/watch?v=t2AI9hODJ2E&t=1247s

事件溯源有点复杂，除非您真的需要它，否则 Martin Fowler 很少有关于事件溯源优缺点的好文章，https://martinfowler.com/eaaDev/EventSourcing.html

Answer 2

我们在Careem 的微服务系统架构中做了什么，我们有一个名为Event 的专用服务，它位于 Amazon SQS 之上。任何服务都可以是该服务的发布者或订阅者。当任何服务使用我们的事件发布者 SDK API 发布事件时，该事件将被放入 Amazon SQS。然后事件处理器 SDK 检查订阅者列表中存储在 dynamoDB 中的这种特定类型的事件。对于每个订阅者，都有一个单独的队列 (SQS)，事件处理器从 SQS 中取出事件并将其放入每个订阅者的队列中。然后事件消费者 SDK 从队列中对该事件进行峰值处理并推送到关联服务。而且整个过程是异步的，这意味着发布者和订阅者服务不必等待任何响应或确认。

无论您是否想将其视为专用服务，您都需要事件来处理异步任务。