微服务消息传递
如果我有一项通用服务，例如通过其他服务的事件发送电子邮件的电子邮件服务，其中一种方法是最好的：
电子邮件服务会听到多个队列/特定事件，并在这些事件触发后发送电子邮件。例如，电子邮件服务会听到
user_queue，并在user_createdevent。有一个通用的电子邮件队列，多个服务可以发出通用
send_email事件。关于这种方法的另一个说明：如果除电子邮件服务外，其他服务想收听此服务的事件怎么办？我是否应该发出两个事件，一个是电子邮件队列，一个是针对此服务的队列，并使其他服务实施了第一种方法？
If i have a generic service, like an email service which sends emails based on events from other services, which one of these approaches would be best:
Email service listens to multiple queues/specific events and sends emails once those events trigger. For example email service listens to
users_queueand sends a welcome email onuser_createdevent.Have a generic email queue to which multiple services can emit a generic
send_emailevent. Another note on this approach: what if other services, apart from the email service, want to listen to events from this service? Should i emit two events, one to the email queue and one to a queue specific for this service and have those other services implement the first approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我正确理解您的问题，您正在询问您是否应该采用基于编排或编舞的方法：
替代＃1详细详细介绍了一种基于编舞的方法，电子邮件服务对一组队列上的一组 events 类型做出了反应，在此处，一种事件类型
user_createdusers_queue替代＃2详细详细介绍了一种基于编排的方法，电子邮件服务对一个队列上的一个命令键入命令类型
send_email在队列email_queue选择方法时，请考虑以下操作：
电子邮件服务需要一组输入参数，例如收件人地址，主题行，电子邮件模板和模板数据。
因此，如果您选择基于编舞的方法， 电子邮件服务对此反应的每个事件都必须提供（信息检索）所需的参数 - 实际上，每个事件都必须提供全部（要检索的信息） 所有对事件反应的服务。
最后一个问题，您是否应该将同一事件发射到多个队列中：
考虑一次发出事件，并让Eventing Middleware负责管理订阅和/或事件路由
If I understand you question correctly, you are asking whether you should adopt an Orchestration or Choreography based approach:
Alternative #1 details a Choreography based approach, the Email service reacts to a set of Events types on a set of queues, here one event type
user_createdon the queueusers_queueAlternative #2 details an Orchestration based approach, the Email service reacts to one Command type on one queue, here the command type
send_emailon the queueemail_queueWhen choosing an approach, consider this:
Email service require a set of input arguments like recipient address, subject line, email template, and template data.
So if you choose a Choreography based approach, every event that the Email service reacts to must provide (information to retrieve) the required arguments - In fact every event must provide all (information to retrieve) the required arguments for all services that react to the event.
To your last question if you should emit the same event to multiple queues:
Consider emitting the event once and have the eventing middleware take care of managing subscriptions and/or event routing