我正在寻找某种最佳实践： 在我们的应用程序中，我们有很多服务，并且它们之间有很多交互。
某些服务将需要能够通知其端部已发生更改。 我们直观的开发人员方法是仅在其中注册一个事件。但是我觉得这有点“肮脏”。
对我来说，服务是向请求它的人“提供”的，并且确实是，但是我们不应该知道该服务的生命周期（也不应防止该服务的服务垃圾回收，因为有人仍在注册。
我的替代方法是：
您认为对此的最佳做法是什么？什么是最干净的方法？
答案 0 :(得分：0)
在Careem的微服务系统体系结构中所做的事情，我们在Amazon SQS之上有一个名为 Event 的专用服务。任何服务都可以是该服务的发布者或订阅者。当任何服务使用我们的事件发布者SDK API发布事件时，该事件将被放入Amazon SQS。然后，事件处理器SDK会检查订户列表以查找存储在dynamoDB中的这种特定类型的事件。对于每个订户，都有一个单独的队列（SQS），事件处理器将事件从SQS移开，并将其放入每个订户的队列中。然后，事件使用者SDK从队列中使该事件达到峰值，并推送到关联服务。而且，整个过程是异步的，这意味着发布者和订阅者服务不必等待任何响应或确认。
是否要将其视为专用服务，您将需要事件来处理异步任务。
答案 1 :(得分：0)
有一个已知的模式CQRS（命令查询责任隔离），您将找到许多示例，该示例涉及如何通过事件实现该事件，称为EventSourcing。您不需要使用EventSourcing，只需将其发布到Queue并订阅即可处理请求，就可以轻松扩展您的体系结构
在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
中找到更多详细信息Event Sourcing几乎没有什么复杂的，除非您真的有需要，否则Martin Fowler很少有关于事件来源的优缺点的好文章，https://martinfowler.com/eaaDev/EventSourcing.html