使用SignalR和Azure的实时通知系统

Question

我正在尝试在ASP.NET MVC网站上制作类似facebook的通知系统

在某种情况下，通知系统的工作方式如下

1. User1通过单击MVC站点中的跟随按钮
来关注User2
2. MVC网站通过API请求向NotificationItem发送NotificationManager。

  

POST api / notifications / send

1. NotificationManager然后处理此notificationItem，然后将其保存到Azure Table Storage

   class NotificationManager { 
               void SaveNotification(NotificationItem item) { 
                 // save it to azure table storage
                } 
   }

1. 保存项目后，客户端（User2）通过NotificationHub（SignalR hub）

订阅notificationEvent

2. NotificationHub然后通知User2以及已处理的通知数据。

 class NotificationHub: Hub {
       async Task NotifyUser(string recipientId) {

         // query data from storage and then process it
         var notificationData= await _repo.GetProcessedNotificationDataAsync(recipientId);

         Clients.Group(recipientId).notifyUser(notificationData);

      }
}

我试图在这张图片上说明CURRENT流程和架构

现在，困扰我的是第5步中的这行代码

 var notificationData= await _repo.GetProcessedNotificationDataAsync(recipientId);

它背后的作用是从存储中查询notificationItem，将其处理为用户可读通知（例如“User1现在关注你”），然后更新notificationItem的状态（IsSent， DateSent）背后。

毋庸置疑，它以某种方式执行“重”操作。每次有新的NotificationItem交付或广播给每个订阅者时，将实时触发。

显然，我在这里讨论性能和可伸缩性问题。所以我研究了一些可以解决这个问题的技术或方法。并且似乎使用Azure Service Bus背板方法是一个可行的选择

SignalR Scaleout with Azure Service Bus

Introduction to Scaleout in SignalR

一个特定的段落解释了这种方法的一些限制

  

服务器广播（例如，股票代码）：背板适用于此   方案，因为服务器控制消息的速率   发送。

     

客户端到客户端（例如，聊天）：在这种情况下，背板可能会   如果消息数量与数量一致，则成为瓶颈   客户;也就是说，如果消息的速率成比例增长   客户加入

     

高频实时（例如，实时游戏）：背板不是   推荐用于此场景。

现在 - 这个让我思考，就像我的情况一样。服务器广播和客户端到客户端（以及介于两者之间的东西）适用于我想要实现的目标。

这些是我目前正在处理的通知事件方案（及其验收标准）

1. 通知用户新粉丝（实时或接近实时通知）
2. 聊天消息（实时，将查看聊天内容当前是否正在输入）
3. 发布状态（实时或接近实时）
4. 在帖子中发表评论（实时，会查看聊天内容当前是否正在输入）

经过几个小时的思考 - 现在我的想法（由于我缺乏经验）是一个 通知系统是这样的

正如您将注意到的，这与我们当前的设计截然不同。目前的设计仅使用1个Azure webrole。

在此，网站的webrole，集线器的webrole以及处理通知数据的辅助角色。因此 - 将“负载”分配给3个不同的角色，并为scaling-out.

打开可能性

现在 - 这是我现在的问题。

1. 这个架构是否适合我想要实现的目标？
2. 由于通知在队列中 - 我们能否实现“实时”通知更新？
3. 由于我们将SignalR中心与另一个网络角色分开 - 我们将如何处理授权？
4. 服务总线队列或Azure队列？

任何帮助将不胜感激。

注意：我打算只使用Azure技术，因为这个项目实际上是面向Azure和.NET的。

Answer 1

1. 是的，对于负载平衡的场景，您的架构看起来应该可以完成工作。
2. 如果你应该使用ServiceBus Queue，你可以很容易地集成（使用nuget包SignalRChat Microsoft.AspNet.SignalR.ServiceBus）
3. Auth也可以，假设您的应用程序是无状态的，并且auth cookie对两个角色仍然有效，假设它们落后于负载平衡场景。
4. 服务总线。以下是有关其完成方式的更多信息。 http://www.asp.net/signalr/overview/performance/scaleout-with-windows-azure-service-bus