聚合通知微服务

Question

问题

我们目前正在构建新的Notification Microservice，但在如何处理汇总的电子邮件方面存在问题。我们需要做的是不是每次执行一次电子邮件都会发送一封电子邮件（几分钟内可能会超过20次），我们会在一小时后发送一封电子邮件，总结所有已完成的操作。

我们到目前为止

到目前为止，我们建议使用这种类型的消息传递模式，其中Client Service是我们集群中的任何服务，Messagebot是我们的Notification Microservice。

1. 客户端服务向Messagebot发送通知，告知将来需要发送内容
2. Messagebot将详细信息存储在其数据库中
3. Messagebot会定期检查其数据库中需要发送的内容
4. Messagebot通过API
从其他服务（可能是客户端服务）获取所需数据
5. Messagebot使用＃3中的数据和HTML模板
发送电子邮件

辩论

对于需要发送的数据，我们不太确定，这是我们需要帮助的。到目前为止，我们认为这应该是从客户服务到通知服务的JSON结构（步骤1）：

{
    template_id: SOME_TEMPLATE_ID,
    user_id: SOME_USER_ID,
    objectid: SOME_OBJECT_ID
}

或

{
    template_id: SOME_TEMPLATE_ID,
    user_id: SOME_USER_ID,
    required_objects: { task_id: SOME_TASK_ID, document_id: SOME_DOCUMENT_ID }
}

其中task_id和document_id只是示例，它会根据模板进行更改。对于不同的模板，它可以很容易{product_id: SOME_PRODUCT_ID}。

辩论的原因

到目前为止，我们的想法是：

1. 我们只需要template_id，因为数据源将隐含在对象中（如ENV var）。例如，Task对象位于http://taskservice/:id。否则，我们可能会遇到API失败或将来切换URL的问题。
2. 我们应该使用userid而不是电子邮件和名称，因为我们可以防止电子邮件/名称对的问题与多条消息不匹配
3. 对于这些对象，我们仍然持怀疑态度，因为这意味着客户端应用服务需要了解Messagebot中的内部工作原理，但是单个objectid可能不是非常可扩展的。我们很容易想象我们的许多消息需要多个对象。

结论

感谢您的阅读。这项服务的设计很重要，因为它将成为我们整个组织的核心。

哪种辩论JSON结构最适合我们的情况？另外，了解我们的要求，这种服务的正确设置是什么？ （又名。我们在其他假设中是否正确？）

Answer 1

所以你的信息机器人

1. 商店通知
2. 从其他服务获取数据
3. 从数据中编译电子邮件和
4. 发送已编译的电子邮件

在我看来，你的messagebot被赋予了太多的任务。如果我正在设计系统，我想保持messagebot更简单。服务应该封装知识以编译电子邮件，例如管理它自己的模板等等。这些服务会将已编译的电子邮件推送到队列中，以便邮件服务器可以接收和发送。 messagebot中唯一的逻辑是从队列中获取电子邮件并发送。通过这种方式，将来您将拥有多少服务并不重要，messagebot将保持简洁。