2

我想创建一个 web 角色的 wcf 来服务智能手机客户端。

此外，我需要创建迭代每个成员的无限后台任务，并在需要时向成员发送推送通知（决定是基于每个成员的一些 facebook 查询做出的）。

目前，该应用程序是新的，我没有客户端，所以我不想要超过一个 VM（为了节省成本..），但我将来可能需要扩展，所以我想支持它。我唯一的要求是对所有成员的迭代将在不到 30 分钟的时间间隔内完成。

我在考虑2个解决方案：

1. 运行仅在一个 VM 中运行的经典 Windows 服务（如果我横向扩展，此 Windows 服务的一个实例仍将仅在其中一个上运行）。此外，我将在 wcf 服务中添加一个“void Handle(Member member) 方法。Windows 服务将有无限循环向该方法发送 wcf 请求。这样，如果我扩展我的实例，负载平衡将分配工作。

问题：windows 服务不知道他可以向 wcf 服务发送多少并发请求。我真的需要对成员进行并发处理（当然，服务器可以并行处理它们的限制）因为当我等待一个 facebook 查询完成时，我可以为其他成员发送更多 facebook 请求（这需要几秒钟每个 facebook 查询都要响应，因为我使用 facebook 批处理请求）。

2.每个webrole实例将负责处理不同的成员（我说的只是后台工作）。例如，如果我有 2 个实例（因为我曾经横向扩展过），第一个实例将负责 id % 2 == 0 的成员，第二个实例负责 id % 2 == 1 的成员。为了实现它，我是认为在每个实例启动时，我在某个 sql 表中注册当前实例。

此外，每个 Web 角色实例都会有后台线程：

  1. 检查 sql 表以了解哪些成员是他的责任
  2. 处理那些成员
  3. 设置 LastHandleTime 日期
  4. 检查是否有一个实例的记录在 5 分钟内没有更新其 LastHandleTime，删除它的记录（这样其他人下次会带走它的成员）

编辑：这个解决方案也有问题。我无法在我的 wcf 服务的整个生命周期中保持后台线程运行 - 如果我的服务中没有任何活动，IIS 可能会杀死它 [更多详细信息：http://forums.asp.net/t/1830688.aspx/ 1]

Edit2：为了解决它，我会将后台线程作为单独的 Windows 服务运行。将来，如果需要，我可以轻松地将其转换为工人角色。由于 Web 角色和 Windows 服务使用相同的处理逻辑，除了从第一个开始有响应，从第二个开始有推送通知（如果需要），我将使用一个共享 dll 和它们的处理逻辑.

哪种解决方案更好？我如何解决我提出的问题？

4

1 回答 1

1

我不会在云中使用 Windows 服务，并且也会避免使用您的 #2 设计，因为它不能很好地扩展。这是我处理您的场景的方式：

我想建立一个分发服务（DS）和一个处理服务（SP）。DS 的作用是在 Azure Queue 中发布需要接收通知的用户/成员列表。DS 可以按照您的建议从数据库中读取。使用 Azure 队列可以更轻松地跨辅助角色分布工作负载，并使用内置冗余，如果队列中的项目未在特定时间范围内处理，它们会重新出现。DS 可能是您的 WCF 服务中的后台线程，尽管我可能会为此目的创建一个专用的工作角色。如果需要 1 个以上的 DS 来实现冗余，请使用共享锁定机制（例如租用公共 Blob 或使用 Azure Table），以便只有 1 个 DS 发布要在队列中通知的成员列表。每个需要接收通知的成员都由 Azure 队列中的一条消息表示。例如，您可以将用户 ID 存储在队列中：2019932 - 因此，如果您有 10,000 条消息要发送，那么 Azure 队列中将有 10,000 条消息。

SP 是另一个工作角色，它从队列中读取并处理队列中的每个项目。SP 可以一次从队列中取出 N 个项目（例如 10 个）并处理它们。SP 也可以有多个线程（假设是 T 个线程），因此每个 SP 一次可以并行处理大约 N * P 个请求。让我们进一步假设您的代码需要 S 秒来处理每条消息（检查 Facebook、发送通知、更新数据库）。要扩展，您需要做的就是部署更多的 SP。部署 X 个 SP 将为您提供平均每秒 X * N * P / (N * S ) 条消息的吞吐量。

从技术上讲，您可以让 DS 和 SP 处于相同的工作角色；只要您处理共享锁定机制，当您在多台机器上部署角色时，您就不必担心重复消息。

As usual, when you deal with large number of requests, you enter the world of sharding. See this link for the current scalability targets of Azure. For example a single queue can process up to 2,000 messages per second. It's a target... not a guarantee... :) If you think you will need more than this, you can always use multiple queues.

于 2012-12-27T19:06:18.727 回答