多个服务之间状态更新的架构

Question

我有一个前端与主后端通信，该后端依次使用服务 A 和 B，使用 gRPC 调用-响应调用。 A 和 B 各自负责与它们交互的硬件组件以完成某些工作。两个硬件组件都会定期更改状态，这些状态需要转发到前端。

为了解决这个问题，我们团队正在讨论两种方法：

1. 在主后端和服务 A、主后端和服务 B 之间建立 gRPC 流。每当其中任何一个有新状态可用时，每个服务都会通过流向后端发送响应，后端又将其推送到前端。缺点是服务之间的耦合性更强，我们需要手动实现连接重新建立，因为 gRPC 流无法开箱即用，并且当 3rd 方客户也需要这些状态更新时，这将使实现进一步复杂化。
2. 让服务 A 和 B 将其状态更新推送到消息队列上。然后后端将拾取它们并将它们推送到前端。这不会引入额外的耦合，当其中一项服务出现故障时，消息不会丢失，并且如果更多方对这些状态更新感兴趣，他们所需要的只是订阅相关主题。

我对第二种方法有明显的偏好，但似乎很难让同事相信这种方法。也许我遗漏了一些东西，所以为了客观起见，我想知道您对这两种方法的看法。

Answer 1

我建议首先创建一份要求和注意事项列表。您不需要发布它们。就我个人而言，即使我从未发布过这些练习，我也总是会进行此练习，以确保我牢记所有问题。

您提到了对第三方身份复杂性的担忧，但没有提及解决方案 #2 的担忧。我认为这是该解决方案非常有利于解决方案 #2 的部分。

RabbitMQ 可以轻松实现以下功能：

group chats
message delivery check
receiving a message from the user while offline
receiving a message on all client applications at the same time (iOS, Android)
preventing unnecessary messages sending
message delivery optimization in case of disconnection from RabbitMQ, e.g. during Internet cut-off

PS。您是否正在考虑在解决方案一中为后端创建一个 API 以将状态发布到前端？