Microservices 聚合通知微服务

问题

我们目前正在设计新的通知微服务，但在如何处理聚合电子邮件方面遇到了问题。我们需要做的是，我们将在一个小时后发送一封电子邮件，总结所有已完成的操作，而不是在执行每个操作时发送一封电子邮件（可能在几分钟内超过20封）

到目前为止我们拥有的

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

客户端服务向Messagebot发送一个通知，告知它将来需要发送某些内容

Messagebot将详细信息存储在其数据库中

Messagebot定期检查其数据库以了解需要发送的内容

Messagebot通过API从另一个服务（可能是客户端服务）获取所需的数据

Messagebot使用来自#3的数据和HTML模板发送电子邮件

辩论

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

或

其中task_id和document_id只是示例，它会根据模板进行更改。对于不同的模板，它也可以是

{product\u id:SOME\u product\u id}

为什么要辩论

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

我们只需要template_id，因为数据源将隐含在对象中（比如ENV var）。例如，任务对象将位于。否则，我们将来可能会遇到API失败或URL切换问题

我们应该使用userid而不是email和name，因为我们可以防止在多条消息中出现email/name对不匹配的问题

对于对象，我们仍然持怀疑态度，因为这意味着客户端应用程序服务需要了解Messagebot中的内部工作原理，但单个objectid可能不太具有可扩展性。我们可以很容易地想象我们的许多信息需要不止一个对象

总之

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

---

哪种结构最适合我们的情况？另外，了解我们的要求后，这类服务的正确设置是什么？（我们的其他假设正确吗？

那么您的messagebot将

存储通知

从其他服务获取数据

根据数据和数据编辑电子邮件

发送已编译的电子邮件

---

在我看来，你的messagebot被赋予了太多的任务。如果我在设计系统，我希望让messagebot更简单。服务应该封装编译电子邮件的知识，例如管理自己的模板等。这些服务将把编译好的电子邮件推送到一个队列中，以便messagebot能够接收和发送。messagebot中唯一的逻辑是从队列中拾取电子邮件并发送。通过这种方式，无论您将来将拥有多少服务，messagebot都将保持良好和简单

在不了解更多信息的情况下，很难解决您的查询：什么是模板id、任务id和文档id？此外，你没有考虑发送Messagebot的任何数据和它所需要的所有数据来做每件事的工作吗？完全同意，除非数据会在邮件发送周期到来的时候过时。这将是我们关注的问题。你可以考虑存储电子邮件（由所有其他服务发布）。在messagebot后面的数据库中，并在时机成熟时将其发送出去。显然，你需要在邮件发送后清空积压的邮件。

{
    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 }
}