SignalR通过Azure EventHub向外扩展

我不能说SignalR的具体细节;然而，原则上您可以使用EventHubs作为背板，但您需要了解其局限性。

SignalR的背板横向扩展模式假设所有服务器都可以访问所有消息并假定处理所有消息。这对单个背板在商用硬件或云中所能做的事情提供了相当明确的限制。在一个典型的云中，你可能能够维持100MB/s的数据吞吐量(对于一个1gb/s的网卡来说是个不错的整数)，高端的商用硬件(和Azure的HPC机器)1000MB/s (10gb/s的网卡)。

那么问题来了，Azure EventHubs能否解决吞吐量的架构限制?

答案是肯定的。100或1000个分区将为2台服务器提供足够的写吞吐量和足够的读容量。

下一个问题是，如果你只需要每台服务器的背板读取100MB/秒，有多少服务器可以读取数据(即如果你广播100MB/秒的股票滴答声，数据大小不随着服务器数量的增加而增加)。

这里的答案是，你想要多少就有多少，但有一些技巧。

EventHubs通过划分数据流来扩展。每个分区的最大读取吞吐量为2MB/s，由所有读取器共享。但是，您可以将分区的数量相乘来弥补分割(如果增加超过32个，则需要与Microsoft协商)。EventHubs(像Kafka和Kinesis)的设计假设是，消费将在机器之间分配，从而避免前面讨论的背板限制。一起读取流的消费者是一个消费者组(Azure似乎需要一个命名的CG，即使是直接阅读器)，在这个背板模型中没有逻辑上的消费者组，所以问题是如何读取数据。

最简单的解决方案可能是使用高级自动平衡事件处理器主机，每个服务器都是自己的消费者组，具有固定的名称。如果每个消费者组中只有一台服务器，则每个服务器将接收所有分区(10台服务器达到100MB/秒，即$11k/月+ $0.028/百万事件)。

这种方法有一个关键的限制:每个事件中心只能有20个消费者组。因此，您可以将Event Hubs链接在一起或使用此方法制作树来获得任意数字。

另一个选择是使用连接到特定分区的直接客户端。消费者组中的单个分区可以有5个读取器，从而将链接集线器的需求减少了5倍，从而将每个事件的成本降低了5倍(不降低吞吐量单位需求)。

总之，在任何背板成为瓶颈之前，它不应该成为瓶颈。但是，如果你希望它的流量超过100MB/秒，就不要在背板上构建东西。

我没有提到延迟，你需要自己测试，但很有可能你不是在云中进行高频交易，这是实时游戏典型的原因。