11

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

在一个场景中，通知系统是这样工作的

  1. User1 通过单击 MVC 站点中的关注按钮关注 User2
  2. MVC 站点通过 API 请求发送NotificationItem一个NotificationManager。

POST api/通知/发送

  1. NotificationManager然后处理此 notificationItem 然后将其保存到 Azure 表存储
   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);

      }
}

我试图在这张图片上说明当前流程和架构 在此处输入图像描述

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

 var notificationData= await _repo.GetProcessedNotificationDataAsync(recipientId);

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

不用说，它以某种方式执行“繁重”操作。并且每次有新的 NotificationItem 发送或广播给每个订阅者时都会实时触发。

显然，我在这里谈论性能和可扩展性问题。所以我研究了一些可以解决这个问题的可能的技术或方法。似乎使用 Azure 服务总线背板方法是一个可行的选择

使用 Azure 服务总线的 SignalR 横向扩展

SignalR 中的横向扩展简介

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

服务器广播（例如股票行情）：背板在这种情况下工作得很好，因为服务器控制发送消息的速率。

客户端到客户端（例如，聊天）：在这种情况下，如果消息数量随客户端数量增加，那么背板可能会成为瓶颈；也就是说，如果消息的速率随着更多客户端的加入而按比例增长

高频实时（例如实时游戏）：不建议在这种情况下使用背板。

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

这些是我目前正在处理的通知事件场景（及其接受标准）

  1. 通知用户有新的关注者（实时或近实时通知）
  2. 聊天消息（实时，将查看聊天者当前是否正在输入）
  3. 发布状态（实时或接近实时）
  4. 在帖子中评论（实时，将查看聊天者当前是否正在输入）

经过数小时的思考 - 我现在（由于我缺乏经验）的想法是一个类似这样的通知系统 在此处输入图像描述

您会注意到，这与我们当前的设计非常不同。当前设计仅使用 1 个 Azure webrole。

其中，有一个webrole用于网站，webrole 用于中心，以及一个工人角色来处理通知数据。因此 - 将“负载”分配给 3 个不同的角色，并为scaling-out.

现在 - 这是我现在脑海中的问题。

  1. 这种架构是否适合我想要实现的目标？
  2. 由于通知在队列中 - 我们可以实现“实时”通知更新吗？
  3. 由于我们将 SignalR 集线器分离到另一个 Web 角色中 - 我们将如何处理授权？
  4. 服务总线队列还是 Azure 队列？

任何帮助将不胜感激。

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

4

1 回答 1

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