通知微服务API或队列

Question

我是微服务架构的新手，希望创建一个集中式通知微服务，以向用户发送电子邮件/短信。

我的第一个选择是创建一个通知Kafka队列，所有其他微服务都可以向其中发送通知。然后，通知微服务将侦听此队列并相应地发送消息。如果重新启动或关闭了通知服务，我们将不会丢失任何消息，因为消息将存储在队列中。

我的第二个选择是在通知微服务上添加一个通知消息API。这将使所有其他微服务更容易，因为它们只需调用API即可与队列集成。然后，API将在内部将消息发送到通知Kafka队列并发送消息。这里唯一的问题是，如果API不可用或出现错误，我们将丢失消息。

对解决此问题的最佳方法有何建议？

Answer 1

都可以。一些可以帮助您做出决定的概念：

“ Kafka”前面的服务将有助于：

1. 隐藏实施。这使您可以灵活地稍后将Kafka更改为其他内容。包装器API将通知请求放入队列后，只会以200响应。我还看到给服务提供直接访问“您的”队列的权限，类似于允许服务直接与他们不拥有的数据库进行交互。如果您允许直接访问Kafka，而事实证明Kafka不足够，则对Kafka进行更改将要求所有客户更改其代码。
2. 强制执行通知请求合同（确保请求的正文格式正确）。如果您要确保放入队列中的所有项目均符合合同规定的格式，则API可以帮助强制实施。这将有助于防止以后在“通知程序”服务从队列中选择要发送的通知时出现问题。

在以下情况下，不希望添加包装器API：

1. 您不想/不能花费时间。截止日期可能会让您着急，而站起来包装纸所需的时间实在太多了。
2. 您是一个小团队，没有足够的资源/工具/时间进行服务爆炸。

您的第一个设计很简单，并且可以使用。如果您正在寻找我概述的优点，请考虑第二种设计。而且，为了确保我理解它，我会看到它像这样展开：

1. 客户1需要发出通知并致电Service A POST / notifications
2. 接受POST /通知的服务A
3. 服务A检查请求，将其放入Kafka，以200响应客户端
4. 服务B从Kafka队列中提取通知请求。

服务A应该作为多个实例运行，以确保可靠性。