通过电子邮件微服务和其他人之间进行通信的最佳方法
我想知道什么是与电子邮件微服务进行交流的最佳模式。
让我们假设第一个微服务（启动器）负责管理用户，因此，除其他外，还执行以下任务：
- 注册用户
- 更新用户的电子邮件
- 重置用户的密码
所有上述所有内容都需要发送电子邮件确认/密码重置电子邮件，以发送到提供的服务电子邮件地址，包括一些可以确认电子邮件/设置新密码的回调URL。
我看到以下可能性在通知电子邮件服务时：
- 发布/订阅模式 - 启动器将诸如
userregisteredevent之类的事件发布到某些消息总线（例如rabbitmq）和回调URL，电子邮件服务会消耗该事件并发送电子邮件。这似乎是耦合方式最少，最灵活的方式，因为任何其他服务都可以在需要时订阅这些事件。但是，在发送电子邮件失败时，我们失去了通知用户的可能性（一种火灾）。 - 请求/响应模式 - 启动器将请求像
sendemailConfirmationRequest发送到某些总线（例如RabbitMQ）或远程在电子邮件服务（例如GRPC）上进行操作，并基本上等待在这种情况下，可能是简单的响应。如果某事失败，它为用户提供了更多的控制和立即信息。 - 命令模式 - 基本上与第一个相同，但命令将被称为
sendemailConfirnation并直接发送到电子邮件服务。
您会选择哪一个？在这种特殊情况下，您发现从电子邮件服务中获得响应有多重要？
I'm wondering what would be the best pattern for communicating with the Emailing microservice.
Let's assume that the first microservice (initiator) is responsible for managing users and therefore, among others, performs the following tasks:
- Registering user
- Updating user's email
- Resetting user's password
All of above require an email confirmation/password reset email to be sent to the provided email address, including some callback URL that would allow to confirm email/set a new password.
I see the following possibilities when it comes to notifying the Emailing service:
- Publish/Subscribe pattern - initiator publishes events like
UserRegisteredEventto some messaging bus (eg. RabbitMQ) with an email and callback URL, Emailing service consumes that event and sends email. It seems like the least coupling way and most flexible as any other service could subscribe to these events if needed. But we lose a possibility to inform user when sending emails fails (kind of fire-and-forget). - Request/Response pattern - initiator sends request like
SendEmailConfirmationRequestto some bus (eg. RabbitMQ) or remotely runs an action on the Emailing service (eg. gRPC) and basically waits for a response that could be a simple bool in this case. It gives more control and immediate information to the user if something fails. - Command pattern - basically same as the first, but commands would be called like
SendEmailConfirmationand sent directly to the Emailing service.
Which one would you choose? How critical do you find getting a response out of the Emailing service in this particular case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当您告诉电子邮件服务（确实是技术组件（TC），而不是域服务）时，我会选择命令模式。
然后，电子邮件服务（TC）可以发布一个事件，该事件已成功发送了电子邮件，并且发起人可以订阅该事件并将操作标记为完成。
有意义吗？
I would choose the command pattern as you are telling the email service (really a technical component (TC) and not a domain service) to do something.
The email service (TC) can then publish an event that the email was sent successfully and the originator can subscribe to that event and mark the action as complete.
Make sense?