微服务架构中的通知服务 [关闭]

Question

我们有一个微服务架构来支持大型应用程序。所有服务都使用 Azure 服务总线作为媒介进行通信。目前，我们正在根据需要从不同的服务发送通知（立即/预定）。这就需要一个单独的通知服务来承担格式化和发送通知（电子邮件、文本等）的负载和责任。

我的想法： 通知服务将拥有自己的数据库，其中包含与通知相关的数据（设置、模板、时间表等）以及一些主数据（从其他来源复制）。我不想将所有事务数据复制到这个数据库（出于明显的原因），但我们可能需要事务和历史数据来形成通知。我计划订阅服务总线事件（由其他服务发布），并且发送格式化通知所需的数据的责任将在于服务引发服务总线事件。通知服务将依靠该数据填充模板（存储在 ots 自己的数据库中），然后发送通知。 通知服务的工作是监听服务总线事件，然后从事件中的数据填充模板，然后发送通知。

问题：

1. 如果通知服务从服务总线事件接收的数据没有通知模板中所需的所有必要数据怎么办。如何从其他服务查询/获取丢失的数据？
2. 假设一个服务为单个操作发布了 100 个事件，我们需要发送单个通知来表明整个操作。通知服务如何管理它，因为它会分别收到 100 条不同的消息。？
3. 由于通知触发器依赖于从其他来源发送的数据（服务总线事件），当我们有一个安排好的通知时会发生什么（比如说每天早上 6 点）。我们如何获取通知所需的数据（因为通知数据库中没有数据）？

我正在寻找一些经验建议和一些可参考的材料。提前致谢。

Answer 1

在微服务和域驱动设计中，有时很难确定何时开始拆分服务。让每个服务负责构建并发送自己的通知是完全有效的。

当需要做出与“原始”服务无关的额外决定时，事情会变得更加棘手。

EG。 1

您有一个订单微服务，可在下订单时向销售团队和用户发送电子邮件。

然后，付款服务在处理付款时通过短信更新销售和用户。

---

然后您可以决定您和用户管理他们的通知偏好。他们现在可以决定是否需要短信/电子邮件/推送消息，以及他们希望接收哪些消息。

我们现在有一个问题。每个发送消息的服务都需要了解这些通知偏好。任何开始发送​​消息的新团队或服务也需要记住实现这些首选项。

您可能还希望用户查看他们发送的所有历史消息。您又遇到了一个问题，即该信息没有单一来源。

EG 2

---

我们现在有了通知服务，它正在监听订单创建、订单更新、订单完成事件和付款处理事件。

它正在列出： 已创建订单 订单更新

只是为了确保它拥有构建消息所需的信息。在使用微服务时，系统范围内的数据冗余是很常见的，并且有很多要求。您需要想象每个服务都是一个孤岛，因此虽然再次存储该信息感觉很浪费，但如果要求该服务执行的是工作，那么它是有效的。

注意：不要批量存储数据，只存储与该服务相关的数据。

然后我们可以使用：

订单完成 付款已处理

事件作为真正开始构建和发送消息的触发器。

---

问题：

1. 了解服务是否具有所有必需的数据

这由服务决定。如果 Order Complete 事件通过，但尚未收到订单创建事件，则服务应存储订单完成事件，并在未来所有信息可用时再次尝试处理。

1. 导致通知的 100 个事件

数据聚合也是一个重要的微服务概念，有很多方法可以确保完整性，具体取决于您的具体用例。

Answer 2

1. 您可能必须将通知实现为服务，这意味着，假设您将应用程序作为插件导出到 Azure 本身。这里有几点.....

   1. 只有当它是有效信息时，您的通知才会被接受，
   2. 在前端（状态管理）和后端、微服务（Redis 或任何缓存系统）都有缓存系统

2. 在每个操作上捕获 EventId，这是一个很好的做法，我们跟踪应用程序的复杂操作，这样您可以解决重复通知，注意尽可能避免向用户发送此类通知，或者尝试发送一个通知在一条消息中召集一组通知，

3.在这里放一个断路器逻辑来处理你的无效通知，把这种类型的通知放在30分钟的重试队列中可能吗？并重新发布活动

参考文献

• https://www.rabbitmq.com/dlx.html
• https://microservices.io/patterns/reliability/circuit-breaker.html
• https://redis.io/topics/introduction

编码愉快:)