ASP.NET SignalR高可用设计是什么

这篇文章主要介绍“ASP.NET SignalR高可用设计是什么”，在日常操作中，相信很多人在ASP.NET SignalR高可用设计是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”ASP.NET SignalR高可用设计是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

在 One ASP.NET 的架构图中，微软将 WebAPI 和 SignalR 归类到 Services 类型与 MVC、Web Forms 同列为一等公民，未来的 ASP.NET 5 尽管还在beta阶段，由它的架构图中可以发现原来就非常相似的 MVC 与 WebAPI 统一合并到 MVC 的大框架中了，而 SignalR 在未来依然在 Services 扮演着重要的角色。

SignalR 是一个集成了多种 HTTP 通讯方式并且优先使用 HTML5 Web Sockets 作为实时通讯管道的技术，而且其设计架构相当清晰易懂，在 ASP.NET 中作为提供即时消息通讯服务层的重要地位由此可见。

环境

开发 SignalR 应用程序前，应该认识 SignalR 技术对运行环境有一些基本要求，运行现行的SignalR 2.0 需要有 .NET Framework 4.5，服务器端需要 Windows Server 2008 R2 以上的操作系统以及 IIS7，如果使用 Web Sockets 来使 SignalR 技术得到最好的发挥，则应该运行于 Windows Server 2012 和 IIS 8 (开发环境需要 Windows 8 和 IIS 8 Express)，因为 IIS 8 以上才可选择安装 Web Sockets 扩展组件。

联机管理

在 SignalR 中有一项十分重要的能力，就是「自动化的联机管理」，自动化的联机管理是在运行期间当客户端意外脱机时，SignalR Client Library 会在固定时间内自动地尝试重新建立联机以恢复与 Server 的对话状态，这个特性在现在的环境下显得十分重要，以下就举两个十分容易理解的场景：

移动联机

手机的网络联机状态向来没有桌面环境稳定，可能随时因为手机移动到不同的地方而发生时间不一的断线情况（地铁经常会发生这种情况），自动化的联机管理能够在这样的场景下得到不错的使用体验。

更新部署

另外一方面来看，造成断线的情况也不一定只有客户端会发生，当应用程序重启或者服务器端软件更新、停机维护状态，也会造成断线，后者更有可能产生长时间的网站脱机状态。经常发生的情况是在 IP （提供服务的VIP）位置不改变的情况下更换了服务器来提供服务，不知道您意识到了吗？SignalR Client Library 在这样的情况下会经历断线重连的阶段而且依旧运行得非常良好。

不过值得注意的是虽然 SignalR Client Library自动地处理了断线重连，但由于 Web服务器实例已经被完全置换，在架构上如果没有做相对应的设计，可能会造成原来运行中SignalR 部分消息的丢失，在下一段将说明 SignalR 中的 Backplane 机制来避免这种情况下消息可能丢失的情况。

SignalR Backplane

Backplane 是 SignalR 基于 publish/subscribe (以下简称 pub/sub) pattern 设计下的系统可扩展性架构设计，Backplane 将「信息」自「实例内部」移出到「外部存储服务器」中，让状态不再局限于 instance 个体上，以提供 SignalR Server scaleout 的能力，达到支持 Web Farm 架构。

上图说明了SignalR 是如何的使用 Backplane 架构实现 pub/sub pattern。首先由接受到信息请求的SignalR Server 将信息储存到 Backplane 上，再由多台 SignalR Server 处理信息的接收与发送，最后送抵 SignalR Client 端ƒ。

由于Backplane 架构的第一项特征便是将消息外移（动作），对于 Web Farm架构是必须有的设计，然而在单一instance 时也能从其中得到好处，可以不必担心应用程序部署 VIP SWAP 时可能发生的信息丢失问题，对于处理信息敏感的应用程序来说，这点来说相当地重要。

有多种支持 Backplane 信息向外储存的方式，包含了 SQL Server、Azure Service Bus 以及 Redis Cache，也可以自行实现其他的外存储方式，以下针对这三种扩充方式进一步的说明。

SQL Server

通过简单的设置，开发人员所熟悉的 SQL Database (或 SQL Server) 就能够用来存储 SignalR 信息到表中，接着由 Service Broker 来有效的转发信息到系统中所有的 SignalR Server 处理（注：Server Broker 是为了增加效率，没有 Service Broker 也能够正常运行）。

开发人员获得以 SQL Server 扩展 SignalR 服务的方式是通过 nuget 在项目中获取 Microsoft.AspNet.SignalR.SqlServer 组件，给予可提供储存数据的 SQL Database 储存个体的联机字符串即可，SQL Database 实例上不需预先建立表格，所需要的 table schema 会由 SQL Server 组件自动建立完成。

详细的实现信息，可由 ASP.NET 官网所提供的 SignalR Scaleout with SQL Server文章中获得。值得注意的是当使用 SQL Server 作为信息存储器，目前在信息转发的效率上较其他方案低上一些。

Service Bus

service Bus 是一项在 Azure 中重要的基础结构，提供了 Queue、Topic、Relay 以及 Notification Hub 等功能。其中 Topics 正是一个与 SignalR Backplane pub/sub pattern相同设计的典型服务。

详细的实现信息，可由 ASP.NET 官网所提供的 SignalR Scaleout with Azure Service Bus 文章中获得。

Redis Cache

Redis 是在内存内以键值 (key-value) 对方式储存的数据的服务，Redis 也支持 pub/sub pattern 来提供信息服务。详细的实现信息，可由 ASP.NET 官网所提供的 SignalR Scaleout with Redis 文章中获得。

Redis 利用内存的运行方式使得它是一个低延迟、高传输量的 Backplane 架构。

到此，关于“ASP.NET SignalR高可用设计是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注亿速云网站，小编会继续努力为大家带来更多实用的文章！