一个背板上的多个 SignalR 集线器类型 - 优点/缺点/可伸缩性

本文关键字：类型 集线器 优点 缺点 SignalR 可伸缩性 一个 | 更新日期: 2023-09-27 18:33:11

最近，我们尝试通过使用SQL背板将几个Web应用程序上的SignalR更改为在Web场环境中工作。

当我

探索它是如何工作的(朝着大多数可扩展性，最少的故障点的目标(时，我们可以调整它的不同方法的数量在我的脑海中成倍增加。

目前，每个应用都使用 SignalR 来支持对数据库中记录的更改进行轮询驱动的广播。

有关对所有应用上的所有 SignalR 实例使用一个背板的基本假设/观察结果：

  1. 具有一个公共背板的所有集线器和集线器实例(所有类型的(仅位于一个消息总线上。

  2. 所有中心实例实质上都"合并"其客户端池。中心实例实际上无法知道它们有多少个客户端。

  3. 来自某些AppB_Hub的消息流量可以在 AppA 的跟踪输出中看到。我假设如果AppA有一个同名的中心，他们就会发生冲突 - 或者只要他们意识到他们会共享客户端，他们就不会发生冲突。

问题/疑虑/未知数：

    不同的集线器(不同的集线器
  1. 类型，可能不同的程序集(是否很好地发挥作用？即一个集线器上的消息和呼叫会干扰另一个集线器吗？在什么情况下？
  2. 这完全是基于命名吗？也就是说，如果AppAHub和AppBHub想要玩得好，他们是否需要确保他们的方法和Calback名称不同？还是只要中心名称不同，它们就已经不同了？
    3. 假设它">
  3. 足够安全"，它是否"横向扩展"得很好，让每个应用程序筛选彼此应用程序的消息。拥有一定规模的单独背板是否值得。小规模值得吗？例如：2 种类型的集线器，每种 2 个实例。
  4. 或者，AppAHub和AppBHub可能真的只是同一集线器的两个接口，因此AppA可能会随时了解AppB，反之亦然。我想知道如果我们知道它们都会得到一切，那么它们成为单独的枢纽是否有任何意义。或者，这是否为 AppA 激活了一些不可避免的额外成本，因为它更明确地"关心"了 AppB 消息？

一个背板上的多个 SignalR 集线器类型 - 优点/缺点/可伸缩性

集线器是独立的，所以不同的集线器玩得很好，如果你把它们放在不同的程序集中并想互相访问，看这里

名称和回调基于客户端连接到哪个集线器，如果客户端连接到一个或多个不同的集线器，则每个客户端仅连接到一个集线器，则它们对于调试目的应该是唯一的

有关性能计数器，请参阅此处，Microsoft在其Azure Web服务中使用signlR背板，因此它可以扩展，但是没有发布有关基准数据的白皮书

如果你想使用接口方法IAppAHub和IAppBHub，

你的java脚本客户端可以调用IAppAHub和IAppBHub方法，如果你想限制你可以按角色，你应该研究SignalR安全。

相关文章：