问汇总通知微服务

EN

问题

我们目前正在设计新的，但在如何处理聚合电子邮件方面遇到了困难。我们需要做的是不发送一封电子邮件，而不是发送每一个动作(可以是20+在几分钟内)，我们会发送一个小时后的电子邮件总结所有的行动已经完成。

我们到目前为止有什么

到目前为止，我们建议使用这种消息传递模式，其中客户机服务是集群中的任何服务，Messagebot是我们的。

1. Client Service向Messagebot发送通知，表示它将来需要发送一些东西
2. Messagebot将详细信息存储在其数据库中。
3. Messagebot定期检查其数据库中需要发送的内容。
4. Messagebot通过API从另一个服务(可能是客户端服务)获取所需的数据
5. Messagebot使用#3和HTML模板中的数据发送电子邮件

辩论

对于需要发送的数据，我们不太确定，这就是我们需要帮助的地方。到目前为止，我们认为这应该是从Client到Notification的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 )。例如，Task对象将位于http://taskservice/:id。否则，我们将来可能会遇到失败的API或切换URL的问题。
2. 我们应该使用userid而不是电子邮件和名称，因为我们防止了电子邮件/名称对在多条消息上不匹配的问题。
3. 对于对象，我们仍然持怀疑态度，因为这意味着客户端应用程序服务需要了解Messagebot的内部工作，但单个对象可能不太可扩展。我们可以很容易地想象我们的许多消息需要多个对象。

在结论中

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

在我们的情况下，哪一种辩论过的JSON结构最适合？另外，了解我们的需求，这类服务的适当设置是什么？(又名。我们的其他假设正确吗？)