microservices - 聚合通知微服务

Question

问题

我们目前正在构建新的通知微服务，但在如何处理聚合电子邮件方面遇到了困难。我们需要做的是，我们不是在每次执行操作时都发送一封电子邮件(几分钟内可能会发送 20 多个操作)，而是在一小时后发送一封电子邮件，总结所有已完成的操作。

到目前为止我们所拥有的

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

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 变量)。例如，任务对象将位于 http://taskservice/:id 。否则，我们将来可能会遇到 API 失败或 URL 切换的问题。
2. 我们应该使用用户 ID 而不是电子邮件和姓名，因为这样可以防止出现电子邮件/姓名对在多条消息中不匹配的问题
3. 对于对象，我们仍然持怀疑态度，因为这意味着客户端应用服务需要了解 Messagebot 的内部工作原理，但单个 objectid 可能不太可扩展。我们可以很容易地想象我们的许多消息需要多个对象。

结论

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

哪种有争议的 JSON 结构最适合我们的情况？另外，了解我们的要求后，此类服务的正确设置是什么？ (又名。我们的其他假设是否正确？)

Answer 1

所以你的消息机器人会

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

在我看来，您的消息机器人被赋予了太多任务。如果我设计这个系统，我想让消息机器人更简单。服务应该封装编译电子邮件的知识，例如管理它自己的模板等等。这些服务会将编译后的电子邮件推送到队列中，以便消息机器人可以接收并发送。消息机器人中的唯一逻辑是从队列中获取电子邮件并发送。这样，无论您将来要拥有多少服务，消息机器人都将保持良好和简单。