gpt4 book ai didi

azure - 使用 Azure Service Fabric 手动控制和生成作业处理代理

转载 作者:行者123 更新时间:2023-12-02 08:30:18 25 4
gpt4 key购买 nike

目前,我正在研究使用 Azure Service Fabric 及其可靠服务来实现我的问题域架构的可能性。

问题领域:我目前正在研究分布式大规模网络爬行架构,涉及数十个并行代理,这些代理应该爬行网络服务器并下载资源以进一步建立索引。

我发现了有用的学术论文,描述了基于 Azure 的分布式网络爬行架构:Link to .pdf paper我正在尝试基于此设计实现并尝试原型(prototype)。

所以基本的高级设计外观如下图所示:

High-Level Architecture

想法:中央网络抓取系统引擎(进一步 - CWCE)在无限循环中运行,直到程序中止并获取包含要抓取的页面 URL 的服务总线队列消息。然后,CWCE 组件检查此 URL 的主机名,并查询代理注册器 SQL 数据库(如果给定主机名的事件代理已存在)。如果不是,CWCE 将执行以下过程之一:

  1. 如果事件代理数量 (A_alive) 等于最大值(代理上限,由应用程序管理员提供),CWCE 将等待,直到 A_alive < 最大值

  2. 如果 A_alive < Max,CWCE 会尝试创建新代理并为其分配主机名。 (代理随后在 SQL Registrar 数据库中注册)。

每个代理都在自己的分区(URL 主机名,例如:example.com)上运行,并仅递归地爬网该主机名的页面,同时发现外部主机名 URL 并将其添加到服务总线队列以进行其他代理处理。

这种架构的好处是代理的水平扩展和爬行效率的近线性工作负载增加。

但是,我对 Azure Service Fabric 非常陌生,因此想问一下这个 PaaS 层是否能够解决这个问题?主要问题:

  1. 是否可以通过可编程代码手动创建新的网络爬网代理实例,并使用 Azure Service Fabric 向它们传递主机名参数? (也许使用 FabricClient 类来操作集群和创建服务实例?)

  2. 哪种 ASF 编程模型最适合这种并行长时间运行的代理场景? 无状态服务有状态服务还是参与者模型?每个代理可能作为长时间运行的任务运行,因为它递归地抓取特定的主机名 URL 并监听队列。

  3. 是否可以在应用程序运行时控制和更改最大事件代理数的上限?

  4. 是否可以使用无限循环无状态服务 CWCE 组件来连续监听队列消息以生成新代理?

我不确定所选的 ASF PaaS 层是否是此分布式网络爬行系统用例的最佳解决方案,因此您的见解对我来说非常有值(value)。任何有用的资源链接也会非常有益。

最佳答案

Service Fabric 将允许您实现您想要的架构。

  1. Would it be possible to manually create new web crawling agent instances through the programmable code and pass them hostname parameter using Azure Service Fabric? (Maybe using FabricClient class for manipulating cluster and creating service instances?)

是的。您将开发并部署到 Service Fabric 的服务将是 ServiceType。服务类型实际上并不运行,相反,您可以从 ServiceType 创建实际的服务,并对其进行命名。单个服务(例如服务A)将具有多个实例,以允许扩展和可用性。您可以以编程方式创建和删除给定类型的服务并向它们传递参数,以便每个服务都知道要抓取哪些 URL。查看示例here .

  1. Which ASF programming model fits this parallel long-running agents scenario the best? Stateless services, stateful services or Actor Model? Each agent might run as long-running task, since it recursively crawls specific hostname URLs and listens for the queue.

我会选择无状态服务,因为它们在资源利用方面是最高效的,并且最容易管理(不需要存储状态和管理状态、分区和副本)。您唯一需要考虑的是,每个服务最终都会崩溃并重新启动,因此您需要将当前爬行位置存储在永久存储中,而不是存储在内存中。

  1. Would it be possible to control and change this upper bound limit of Max alive agents during runtime of application?

是的。 Service Fabric 服务在节点(虚拟机)和 Azure 中运行,它们由虚拟机规模集管理。您可以轻松地从 VMSS 添加和删除节点,这将允许您调整所需的总计算和内存能力,并且实际服务数量已由您控制,如第 1 点中指定的那样。

  1. Would it be possible to have infinite-loop stateless service CWCE component which continuously listens for the queue messages in order to spawn up new agents?

绝对是的。消息驱动的微服务非常常见。从技术上讲,它不是无限循环,而是具有总线通信监听器的服务。我找到了一个here作为引用,但我不知道它是否已准备好生产

关于azure - 使用 Azure Service Fabric 手动控制和生成作业处理代理,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/61463806/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com