Azure云服务项目-体系结构

我已经环顾了很多地方来了解这些概念，现在我需要介绍一下我的计划，以便进行一些回顾

我将创建一个云服务，它接收来自另一家公司的通知，并使用另一家公司的web API的REST服务

这些数据是代表在我的网站上注册的用户处理的。所以他们做了一些设置并离开了网站。云服务现在开始处理检索到的数据，并根据web API进行操作——一些数据将被存储起来以呈现给用户

我每天都会收到几千到几十万份通知。以后可能会更多。几百个用户，以后可能会上升到1000+甚至更多

所以，我是这样想的：

网络角色：

• 构成前端，负责用户管理其设置 以及显示数据
• 在SQL数据库中存储用户凭据和设置
• 还提供用于管理所有用户的管理UI
• 从web API接收通知（包含数据DTO，最多20-30个数据类型字符串属性），并将其转发给 工人的角色
• 将有关通知的数据存储在一个（或两个）Azure表（表1和表2）中
• 查询这些表（和表4）以提供“鼠标悬停”数据，即在web UI中显示给用户的数据

工人角色A：

• 从webrole接收中继通知，计算类型 通知和：
• 请求REST API获取更多数据，或者：
• 异步将通知DTO放入Azure表（表3）中，供工作角色B使用
• 经常为工作人员角色B创建的作业弹出Azure队列，并发布到REST API
• 将有关帖子的数据存储在另一个Azure表中（表4）

工人角色B：

• 经常阅读表3中的DTO通知
• 根据通知的类型，使用DTO中的数据构造查询，查询SQL数据库并检索匹配的用户 设置、进行评估和构造要放在 队列，用于弹出和发布工作角色
• 在第五个表格（表5）中，将剩余的（未完成的）工作继续进行下一轮

这几乎就是全部

我想让通知由XSockets.NET管理，因为我认为SignalR需要Windows 8，还是我错了

我的问题是:

我应该使用服务总线队列在Web角色和工作者角色a之间进行通信吗？或者是一个内部端点？还是排队？我认为不断地轮询队列是不必要的负载，但是每秒ping一次可能并不是很多工作

服务总线队列会保持所发送通知的实时性，还是会减慢速度

工作角色A是否可以与web角色合并而不冒IIS丢弃线程的风险

整个工作过程非常类似，他们显然认为有必要使用2个工作者角色和一个web角色来完成这项简单的任务

---

提前感谢，任何提示和澄清指示都将不胜感激

1-如果您在worker角色中托管WCF，则内部端点将非常有用，因此，使用队列在角色之间进行通信是我本人多次使用的方法

2-不，这不会减慢速度

---

3-毫无疑问存在风险，但值得一试。

虽然这是一个基于意见的问题，可能会被关闭，但我建议您花一点时间研究web/工作者角色。它们只是虚拟机。任何可以在辅助角色中运行的代码都可以在web角色中运行。而且。。。因为每个定义的角色至少需要一个实例，所以您的体系结构将使用至少3个VM实例。这很好，如果你同意的话。您需要决定这是否合理，或者您是否应该将功能合并为两个角色，甚至是一个角色。谢谢您的回答。试图删除基于意见的问题，希望我能得到指示。如果需要的话，三个角色是罚款的。这两个工作者角色所做的事情与本教程中描述的差不多，甚至更多。那么，让web角色接管工作者角色A或B的职责，或许可以减少角色数量？