同一 ASP.NET Core 服务上的 grpc 客户端\服务器

Question

我有两个服务 A 和 B，它们使用 gRPC 进行通信。在 99% 的情况下，服务 A 充当客户端并调用服务 B，服务 B 充当 gRPC 服务器。但是，偶尔会有服务 B 需要向服务 A 发送一条小消息的情况。

问题是，在同一个服务中同时实现 gRPC 客户端和 gRPC 服务器通常被认为是一种好的做法吗？ 这样，服务 B 也可以在需要时向服务 A 发送消息。

有关我的项目的其他信息：服务 A 是一个为 Angular 应用程序提供服务的 .NET Core 后端。

它包括：

• Angular 前端，由后端提供服务。
• 带有 API 控制器的 ASP.NET Core Web API 后端，用于与 Angular 进行通信
• gRPC 客户端调用服务 B。 简化的架构如下：

目标：当服务 B 中发生事件时，需要通知服务 A。服务 A 收到此通知后，应使用 SignalR 或 WebSocket 来触发 Angular 应用程序中的特定 UI 行为，类似于推送通知。

关心

我不确定在同一服务中同时拥有 gRPC 客户端和 gRPC 服务器的做法。这是一个合理的方法，还是会导致潜在的问题？

还要考虑到在生产中我需要部署为 2 个具有水平缩放功能的独立容器。

我已经在 A 和 B 的 grpc 服务器和客户端中实现了。它有效，但我正在考虑不同的解决方案。可以从 B 直接调用 A 公开的 API 控制器吗？

Answer 1

考虑

双向流式 RPC，双方使用读写流发送一系列消息。这两个流独立运行，因此客户端和服务器可以按照它们喜欢的任何顺序读取和写入：例如，服务器可以在写入响应之前等待接收所有客户端消息，或者可以交替读取消息然后写入消息，或其他一些读和写的组合。每个流中消息的顺序都会被保留。

根据文档，这是 gRPC 的用例之一，而且这并不罕见。 另一种适用于您的架构的方法是消息总线。但如果您已经购买了 gRPC，那为什么不也将其用于此目的呢？所以是的，这当然是一个可行的解决方案。