3

最近，我们尝试通过使用 SQL 背板更改几个 Web 应用程序上的 SignalR 以在 Web 场情况下工作。

当我探索它是如何工作的（朝着最大可扩展性、最少故障点的目标）时，我们可以调整它的不同方式的数量正在成倍增加。

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

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

  1. 具有一个公共背板的所有集线器和集线器实例（所有类型）仅存在于一条消息总线上。

  2. 所有集线器实例本质上都“合并”了它们的客户端池。集线器实例实际上无法知道他们有多少客户端。

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

问题/疑虑/未知数：

  1. 不同的集线器（不同的集线器类型，可能是不同的组件）玩得很好吗？即一个消息和电话会干扰另一个吗？在什么情况下？
  2. 这一切都基于命名吗？即，如果 AppAHub 和 AppBHub 想要玩得很好，他们需要确保他们的方法和回调名称不同吗？还是只要集线器名称不同，它们就已经不同了？
  3. 假设它“足够安全”，它是否可以很好地“扩展”以让每个应用程序筛选彼此应用程序的消息。在一定程度上拥有一个单独的背板是否值得。在小范围内值得吗？例如：2 种集线器，每种 2 个实例。
  4. 或者，AppAHub 和 AppBHub 有可能实际上只是进入同一个集线器的两个接口，因此 AppA 可以随时了解 AppB，反之亦然。我想知道如果我们知道它们都会被喂饱，那么它们作为独立的中心是否有任何意义。或者这是否会为 AppA 激活一些不可避免的额外成本，因为它更明确地“关心”了 AppB 消息？
4

1 回答 1

0

集线器是独立的，因此不同的集线器可以很好地发挥作用，但是如果您将它们放置在不同的组件中并希望相互访问，请参见 此处

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

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

如果你想使用接口方法 IAppAHub 和 IAppBHub 你的 java 脚本客户端可以调用 IAppAHub 和 IAppBHub 方法，如果你想限制你可以通过角色来限制它，你应该查看 SignalR 安全

于 2016-02-11T17:39:54.643 回答