推荐订阅源

自从离开docfx组，一晃就好几年没写blog了。加上几乎所有的空闲时间都被两个娃占了，今天好不容易有点时间写写文章。最近几年一直在Azure SignalR组里混日子，就来说说Azure SignalR的各种事情。

不知道大家是否了解SignalR，简单的说就是.net上的一个websocket的应用框架，当然也支持使用long polling来处理无法建立websocket的场景。所以绝大多数情况下，大家会用SignalR来做一些准实时的信息更新，例如：股票价格、游戏、聊天等。

从dotnet core开始，新推出了Aspnet Core SignalR，重新定义了协议，与老版本的Aspnet SignalR并不通用。增加了message pack的协议，改进了对二进制的支持。

但是单机对Websocket的处理量终究是有限的，因此SignalR提供了Sql、Redis等Backplane，然后就有了Azure SignalR Service。Azure SignalR Service并不是一个Backplane，而是一个类似代理的东西，位于客户端和服务器之间。那么代理与Backplane相比，优势是什么哪？

1. 服务器的压力不同。使用backplane，服务器需要处理客户端链接，处理客户端的消息，需要分发广播消息，需要发送到Backplane，需要处理Backplane里的消息；而使用service，服务器需要处理客户端的消息，分发组消息时，就可以委托给service处理，并且只使用非常有限的物理链接。
2. 简化架构。使用backplane需要配置server sticky，需要配置sql或redis。而使用service时，则不需要server sticky，service会接管客户端链接。
3. Serverless。使用service的最大优势是在某些情况话可以做到serverless。使用serverless后，service可以配置upstream，也就是客户端发的消息转换为rest api调用upstream。并且可以直接用service的rest api来发消息，或者管理客户端。这里的某些情况，其实是指流量满足下列情况：
   • 服务器广播为主（hub级或group级）。
   • 客户端只需要发少量消息或者不发消息。

今天就说这么多了，下周我再介绍一下Azure SignalR Service的使用。