使用 C# 进行网络爬取（第一部分）

• 下载 HTTPClientThread.zip - 43 KB
• 下载 MVCSimpleServerApp.zip - 4.6 MB

引言

我之前写了一篇关于 使用 C# 进行网页抓取 的文章，概述了使用各种技术从网站提取数据的艺术。那篇文章讨论了从特定网页获取数据，但没有讨论从一个网站或网页移动到另一个网站或网页并积极发现那里有什么的过程。有些人混淆了网络爬取（web crawling）和网页抓取（web scraping）——它们密切相关，但不同。网络爬取是漫游和爬取网络（或网络）以发现和索引那里有什么链接和信息的过程，网页抓取是从爬虫带回的网站或网络资源中提取可用数据的过程。所以，我的上一篇文章讨论了从网站/页面获取数据，而本文将讨论爬取网络的各种方法、概念、工具和框架 #就像 宾果 一样。

这并非一篇学术论文，而是一个想法的起点，以及帮助初学者进行网络爬取的思考。本文讨论的许多概念和想法都面向健壮、大规模的架构——尽管如此，如果你只需要从一个网站爬取到几百个网站，这里仍然有很多信息会非常有用。文章确实涵盖了一些非核心 C# 技术，其中一些你可能不需要，甚至可能对你的情况来说是过度的。话虽如此，重要的是要注意它们被提及的 上下文。如果你的需求比这里描述的小，你可以 just pare back and pick and choose the bare minimum framework you require，where necessary，building out yourself。

本文是多部分系列文章的第二部分。

第一部分 - 如何使用 C# 进行网页抓取
第二部分 - 使用 C# 进行网络爬取 - 概念（本文）
第三部分 - 使用 C# 进行网页抓取 - 点点即抓！
第四部分 - 使用 .net 进行网络爬取 - 示例代码（待续）

背景

我一直对 “托”战队 和网络机器人（web-bots）的概念非常感兴趣，并进行了大量的研发，包括阅读一些有用的背景研究（*例如 这里*）。如果你不熟悉这个术语，它 指的是 “使用虚假身份来人为刺激对产品、品牌或服务的需求”。然而，托战队不仅用于商业目的，例如政府越来越多地使用它们来控制媒体并为自身目的宣传内容（例如：军队如何使用 Twitter 托来控制辩论）。我个人的兴趣在于考察这些的规模，它们的演变方式，以及网页抓取和爬取技术如何被用作创建和帮助大规模识别托的工具。我打算将本文作为一份讨论文件开始，然后稍后将其发展为演示一些我一直在该领域研究和开发的示例代码。

起点

我已经解释过，网络爬取是关于链接，而不是数据。获取数据是抓取。当你进行抓取时，你知道在哪里抓取以及抓取什么；而当你进行爬取时，有时你知道一个起点，但去往何处取决于爬虫一旦离开其原始起点后发现的东西。如果你必须索引整个网络，你会从哪里开始？...也许是从你所知的最流行的网站开始，也许是从 DNS 服务器的列表开始，也许是从某些客户端网站开始。无论你从哪里开始，你都需要从某个地方开始。当你有了起点后，你就需要决定如何进行爬取。

深度优先或广度优先

有两种主要的爬取方法可以决定如何开始你的爬取。你可以进行深度爬取，或广度爬取——在不同情况下，两者都同样有用。假设我们有一个起始点，一个网站的首页有 2 个链接，每个链接又有其他链接——我们需要做的是确定爬取这些蜘蛛网中所有链接的最佳方式……

广度优先 

这是我们从页面上找到的顶层节点开始，在深入到任何链接页面之前，*广度/宽度*地爬取每个页面上的链接。这就像按行/波浪爬取……我们从爬取第一层红色（2,3）开始，然后当这些顶层链接耗尽时，我们转到下一层（2,3）的绿色（4,5,6,7），当这些完成后，我们转到下一层蓝色（...），以此类推。

深度优先

下一个主要方法是深度爬取。这意味着我们在移动到另一个链接之前，会用尽每个顶层链接的深度链接。在深度优先中，我们先获取第一个链接（2），深入到其中（3），然后从那里更深入（4），直到（5），再到（6），**然后**耗尽深度链接后，我们缩回上一层（在4处），并爬取到（7），然后深入到（8,9），再缩回以获取（10,11），然后一直缩回到（12），看到它没有链接可以一起玩到（13），然后从那里深入到（14,15,16…）。

网络爬取还有许多其他方法，但它们通常是上述两种方法的变体——例如，80legs 使用混合方法，它根据当时确定的最优性来决定深度优先或广度优先遍历。实际上，如果你查看上面的图表，你可以想象使用单个线程遍历整个链接树是低效的。因此，通常使用一系列并发线程来执行爬取过程，每个线程沿着不同的路径进行遍历/爬取，从而更快地完成整体工作。

爬取队列

一旦你决定了要使用的爬取方法，接下来需要问的问题是如何管理爬取过程。如果你认为所有这些都可以内存中完成，请三思……对于除最简单的网站或爬取之外的所有情况，这都是一条灾难之路。原因是使用简单的递归遍历可用链接节点会比你眨眼的速度更快地耗尽你的堆栈。最好的方法是创建一个列表或队列，将链接推入其中进行爬取。当你从一个链接移动到下一个，需要获取一个新的链接进行爬取时，就从队列中取出一个。当你发现新链接时，就将它们推入队列，等待下一个爬取过程发现。虽然一个简单的 FIFO 队列可以工作，但对于网络爬取来说，它并非最优。一个更好的方法是使用优先级队列，而不是简单的队列。

优先级队列

优先级队列是一种队列系统，它背后有一些智能——它接收我们给它的链接，并将它们组织成某种有意义的、预先确定的顺序。优先级队列的想法是，推入队列的信息被赋予优先级，并根据优先级提取——就这么简单。优先级可以是任何你想要的——你自己设计……低/中/高，低/高，低，更低，最低，高，更高，最高，等等……优先级队列的目的是让你能够根据给定的重要性顺序过滤和弹出队列中的项目。我们可能会进行抓取，并决定所有 PDF 文件链接比 DOCx 文件更重要，因此获得更高的优先级。我们可能会决定顶级域名链接比二级域名链接更重要……例如
 

链接                                                优先级

Domain_1.com                              高
Domain_2.com                              高
SubDomain.Domain_2.com          低
Domain_3.com                              高
SubDomain2.Domain_1.com        低
 

队列中的一个项目当然可能包含更多信息，例如抓取日期、链接来自何处等等。这取决于我们当时需要的实现。

策略和规则

在确定我们应该爬取哪些链接、需要给链接什么优先级等时，我们通常会参考一个爬取策略和规则列表，例如

• 这是我们想去爬取的链接/网站吗？
• 我们是否已经访问过这个链接？如果访问过，多久以前？
• 链接是否属于我们想访问的类别（例如购物网站，或机票/航空预订网站）？
• 我们如何知道这是一个我们想爬取的网站？…我们是否需要先通过语义分析工具处理主页以确定内容？
• 当我们寻找链接时，是根据链接的 URL 名称、它来自的父页面，还是 标签包裹的内部文本来寻找？
• 我们是在寻找特定文件/数据类型的链接，例如 PDF、Doc、XLS…吗？
• 当我们加载网页并寻找链接时——链接在哪里？
  • 它们是容易获取的 标签吗？
  • 它们是否被事件挂钩？ $('somebutton').click(function(){....})
  • 它们是事件链式的吗？（只有当其他 JavaScript 事件被触发时才会出现）？
  • 它们是内联在页面上的，还是通过 AJAX 调用按需推送到 DOM 的？
• URL 重定向的情况下我们该怎么做？（临时或永久）
• 我们等待链接响应/超时多久？
• 如果链接根本不存在怎么办？
  • 忽略、重试还是报告？
• 在寻找要爬取的链接时，我们是否会查看链接的上下文，以及是否需要考虑语义上下文？也就是说，我们是在标准化数据吗……“航空公司价格”的内部文本是否等同于“航班价格”等同于“航班费用”等同于“机票价格”？
  • 如果我们试图根据链接（内部）文本确定要爬取的链接，我们是否应该/不应该使用正则表达式/SoundEx 等技术来映射链接文本？还是我们需要一个映射系统？
• 当我们在爬取时遇到需要登录的网站，我们该如何处理？…请记住，登录可能在 HTTP 级别，也可能在 HTML 授权级别——你应该有一个规则来识别和处理这两种情况。

User-agent: *
Disallow:

User-agent: *
Disallow: /

User-agent: *
Disallow: /photos

在此处 阅读更多关于 robots.txt 的信息，以及在此处 在此处。

作为真实世界的例子，这里有一些来自 Amazon.co.uk 网站 Robots.txt 文件的摘录

User-agent: *
Disallow: /exec/obidos/account-access-login
Disallow: /exec/obidos/change-style
Disallow: /exec/obidos/flex-sign-in
Disallow: /exec/obidos/handle-buy-box
Disallow: /exec/obidos/tg/cm/member/
Disallow: /exec/obidos/refer-a-friend-login
Disallow: /exec/obidos/subst/partners/friends/access.html
Disallow: /exec/obidos/subst/marketplace/sell-your-stuff.html
Disallow: /exec/obidos/subst/marketplace/sell-your-collection.html
Disallow: /gp/cart
Disallow: /gp/customer-media/upload
Allow: /wishlist/universal*
Allow: /wishlist/vendor-button*
Allow: /wishlist/get-button*
Disallow: /gp/wishlist/
Allow: /gp/wishlist/universal
User-agent: EtaoSpider
Disallow: /
# Sitemap files
Sitemap: http://www.amazon.co.uk/sitemap-manual-index.xml
Sitemap: http://www.amazon.co.uk/sitemaps.f3053414d236e84.SitemapIndex_0.xml.g

温柔/友好相处

虽然我们可以编写网络爬虫以光速行进，并在最新的超级双核超快处理器机器的分布式网络上部署它们，但我们必须始终意识到目标服务器可能无法承受同时受到数以亿计爬虫的轰炸。

我曾遇到过这种情况：我用一个线程爬取网站，为了对目标服务器温柔一些，我在调用之间插入了延迟，一切都很好。然而，在同一个服务器上，当我稍微放宽限制，让 2…3 个更多线程爬取服务器时，它反复崩溃……它没有因为潜在的拒绝服务攻击而阻止我，不，它崩溃了，导致我打电话给主机要求重启。这是严重的情况，并不经常发生，但信息很简单——爬取服务器时要非常小心和温柔。最好尝试实现某种智能监控指标来衡量目标服务器对你的爬虫的反应，以便根据需要自动打开或收紧爬取限制。

你还应该仔细注意你正在爬取的任何网站的“服务条款”或“使用条款”——虽然有些网站是“开放营业”的，但另一些网站有法律限制，它们不希望你了解它们在网站上可以做什么和不可以做什么，包括爬取。总的来说，可以这样说，如果某些东西是公开的，那么它就可以被自动阅读（爬取/抓取）（但不能重用，那是另一回事）。但是，如果某些东西在 付费墙 后面，或者用户必须同意一套特定的 T&C 才能使用特定的登录访问，那么规则就不同了，你*绝对需要注意* T&C。 Ryan MItchell 有一篇关于你可以/不可以做什么的很好的博客文章。

作为网站 T&C 与爬取/抓取相关的例子，这里摘录了 Apple 网站的使用条款（是的，继续，笑吧，我确实会读这些东西！！）

引用

你不得使用任何“深度链接”、“页面抓取”、“机器人”、“爬虫”或其他自动设备、程序、算法或方法，或任何类似或等效的手动过程，来访问、获取、复制或监控网站的任何部分…… Apple 保留禁止任何此类活动的权利……你同意你不会采取任何会给网站基础设施带来不合理或不成比例的负载的行动。

在进行任何大规模操作之前，识别此类封锁符合你的最大利益。寻求法律建议始终是最好的建议！

最后，请注意，爬取某些链接会触发服务器端操作，从而导致服务器负载过重，因此要小心。例如，我曾爬取过一个服务器，它有一系列链接，当跟踪这些链接时，会触发生成一个非常长的报告，该报告会占用服务器 2 到 7 分钟的时间——非常低效，但这就是我所处理的，所以必须加以考虑。这里的关键信息是，不要假设你可以肆无忌惮地攻击服务器。你需要确保你友好相处，并随时准备在需要时退缩。

安排你的爬取

除了密切关注你爬取服务器的激进程度外，你还应该意识到服务器在一天中的某些时间可能会承受更大的压力。服务器繁忙的时间可以由它服务的市场（时区）决定，还可能有例如活动高峰时间（如果是一个体育网站，在大赛期间和周围可能会有更重的用户使用）。因此，在计划爬取时，要考虑时间因素。除了采取智能的时间安排方法外，还应检查你正在索引的网站是否有“最小 ping 延迟”——也就是说，机器人/爬虫在返回进行后续重新索引之前期望等待的最小时间。

可能出现的问题

总的来说，当我们爬取网页链接时，我们将通过一系列线程或线程池来完成——这是最有效的方式。当我们使用线程时，我们需要非常小心，确保它们以安全的方式执行，并且如果出现问题，我们能优雅地处理并恢复。以下是可能出现的一些问题——我们需要在遇到它们时识别并处理每一个问题。

• 服务器响应代码是服务器发送给客户端的代码，用于指示特定状态。它们范围从信息性/成功消息（如“ok”），到重定向标志（临时重定向 307，永久重定向 301）。400 错误是客户端错误（404，页面未找到），500 错误由服务器生成（例如：500 内部服务器错误）。在此处查看有关错误代码的更详细信息。
• 超时 - 如果 URL 调用超时——服务器没有响应——如何处理？
  • 重试/重新入队？
  • 终止？
  • 报告？
• 循环/递归/周期性链接——我们需要确保我们监控自己不会陷入无限循环，即使是深度循环——这会随着时间的推移而摧毁我们的爬取策略，导致无休止的资源调用浪费——考虑使用黑名单或“已访问”列表，在允许我们的优先级队列使链接可用于爬取之前进行检查。
• 互联网速度 - 如果你的连接中断，或者你在访问服务器时服务器过载，响应时间*稍长*怎么办？
• 你打开了太多线程——你的爬虫对它所托管的服务器有什么影响？…你需要监控内存使用情况来处理这个问题吗？*（这里有一个提示，你需要！）*
• 最大线程数 - （取决于你在做什么）并发爬取的线程数量是有限制的（并且在 Windows 和 UNIX 中是不同的）——你需要考虑到这一点。

洗涤，漂洗，重复……

据说一旦一本参考书写出来，它就过时了——原因很简单，大多数事物都不会保持稳定，它们会改变，这对网络爬取来说非常重要。当我们去爬取一个网站时，甚至在我们完成之前，它的内容可能已经改变了。所以，如果我们正在进行爬取，我们不仅要知道从哪里开始和结束，还必须知道何时重新开始！
 

我消失了

虽然严格来说不属于网络爬虫的领域，但监控网页并通知爬虫某物已更改，并且需要重新索引网站的能力是整个爬取系统的组成部分。本质上，要做到这一点，我们不仅需要知道链接*应该*是什么，还需要知道*不应该*是什么。
有许多方法可以识别我们需要看到的更改——范围从简单到复杂。

对于相对静态的页面（简单），我们可以拍摄一个 HASH 快照，并比较前后。对于更复杂（且可扩展）的实现，我们可以研究使用“布隆过滤器”。由 Burton Howard Bloom 于 1970 年描述为

引用

一种非常节省空间的概率性数据结构，用于测试一个元素是否是集合的成员。可能出现误报，但不会出现漏报，因此布隆过滤器具有 100% 的召回率。换句话说，查询返回“可能在集合中”或“绝对不在集合中”。
来源：维基百科.

布隆过滤器是一种极其有用且高效的结构，我们可以用它来回答“有什么变化”，“有什么新东西”等问题。以下是一些大公司如何成功使用布隆过滤器解决我们进行网络爬取时遇到的类似问题的例子：

• Google BigTable、Apache HBase 和 Apache Cassandra 使用布隆过滤器来减少非现有数据的磁盘查找。
• Google Chrome 浏览器曾经使用布隆过滤器来识别恶意 URL。
• Squid Web Proxy Cache 使用布隆过滤器来处理缓存摘要。
• Bitcoin 使用布隆过滤器来加速钱包同步。
• Venti 存档存储系统使用布隆过滤器来检测先前存储的数据。
• Medium 使用布隆过滤器来避免推荐用户已读过的文章。 来源：维基百科

如果你去 搜索 有关布隆过滤器和 C# 的阅读材料，你会找到很多。这是 Venknar 用 C# 实现的一个 布隆过滤器 示例。

对于内容动态变化（复杂）的页面，我们通常需要能够将链接目标页面分解为元素组，并分别以及作为一个整体来检查这些组，以确定（任何）更改状态。我们可以使用不同的工具和技术来协助进行此分析，例如正则表达式和模板缩减只是其中两种。查看一些 HTML/CSS 代码并看到重复的模式是相对容易的。这些是“自己动手”的代码块，其中 DIV 和其他元素会重复，或者我们可以清楚地看到框架的重复，如 KnockoutJS 的 `data-bind="foreach:"` 和 AngularJS 的 `ng-repeat=..`。模板缩减的概念是剥离数据到核心原始模板，并使用它来帮助确定链接目标页面的设计是否已更改，而不是数据内容。

如果你想深入研究这个领域（非常有趣！），你可以看看以下一些内容：

• 一种基于哈希和减少相似性计算次数的快速 HTML 网页更改检测方法 
• 并行爬虫架构和网页更改检测
• 动态生成网页中的片段自动检测
• 基于页面更改检测策略的定向网络爬虫

我认为更改检测的位置应该在 Guvnor 系统范围内——不是作为核心部分，而是作为关键的辅助过程，它会被频繁调用，但可能是一个独立的、但支持性的过程。

在监控更改和关注“知道你不知道的东西”的同时，进行大规模爬取同样重要的是能够识别何时出现新事物。在处理与爬取链接相关的抓取记录的非常大的数据库时，最好制定一个策略来识别新出现的记录，而无需直接查询数据库的大部分内容，或者同样重要的是，无需重新遍历目标网站的每一个链接。如果你有一个不断增长的数据集，当你*认为*遇到了新东西时，最不想做的事情就是每次都进行递归扫描，无论是在目标网站还是在你自己的数据库中。semantics3.com 的人 यांनी 在他们题为“索引一个电子商务商店可能是一次亚马逊式的冒险”的文章中提到：
 

引用

检测新产品的挑战不是将每个潜在产品与数百万种现有产品数据库进行比较。我们的科学家使用智能产品排名算法来解决这个问题。搜索按产品类别进行，而不是按单个产品进行，从而减少了所需的处理时间。我们可以在 24-48 小内找到任何零售商的新产品（届时已经推出了更新的产品！）。

他们说的是，在这种情况下，而不是扫描*“选择所有页面并查找新页面”*，他们说的是——*“从类别中选择所有条目并查找新条目”*……从爬取和抓取的角度来看，这是一个小得多的问题。这里的关键信息是，当你试图找出诸如

• 有什么新东西？
• 自上次访问以来此页面是否有任何更改？
• 链接是否仍然存在？

不要只是一头扎进大规模的爬取狂潮，而是要仔细思考，并寻找获取所需信息的方法，这些方法需要最少的处理和最少的资源消耗，以及目标网站的网络资源。

如何管理/优化

在掌握了上述概念之后，接下来我们需要考虑的是将所有这些整合到一个健壮、高性能、可扩展的架构中。无论是否有人已经构建了一个我们可以依赖的框架，我们都可以从那些早已存在的巨头那里学到很多东西。那些已经在大规模处理事物的巨头，例如 Facebook、Microsoft 和 Google，可以教给我们很多东西，无论是直接还是间接。立即想到的两个项目是 Hadoop 和 MongoDB。这两种技术都旨在极好地解决规模化问题，并且两者都能处理大量数据。
 

谁负责？- Guvnor！

在许多机械系统中，你会遇到一个“Governor”……在下面的精彩图示中，它是一套规则的硬件实现，根据输入，调节和管理系统的正确高效运行。在古老的英语中，经理（有时仍然是）被称为“Guv'ner”。

（附注：如果您有几分钟空闲时间完成本文，并想阅读一些很酷的题外话，请看看这个关于柴油机车发动机上的Governor的精彩 描述。）

你会在大规模系统中看到的一个常见模式是中心复制的管理器。在大多数情况下，这个管理器充当分布式工作节点网络的交通控制器。在我们的爬虫架构中，我们可以使用这样的管理器为工作节点分配任务，接收结果，并监控以确保一切顺利运行。虽然 Guvnor 的概念是作为顶级管理器，但自然地，为了扩展性、性能和弹性，Guvnor 本身可能是一系列较小的引擎，它们作为一个连接的系统集合构成主控制器。

在开始从头开发自己的 guvnor 之前，看看有什么可用的，什么可以取代 Guvnor 的位置，或协助 Guvnor。例如，Gearman “提供了一个通用的应用程序框架，可以将工作分配给更适合执行工作的其他机器或进程”。.Net 社区有两个相关的发行版：GearmanSharp 和 Gearman.net。你可以在 Gearman 下载页面 上获取更多信息。
 

作为幽默的题外话，我看到 GearMan 被描述为

引用

“GEARMAN - ** the Manager ** ...

因为它分派任务去做，但它自己不做任何有用的事”：）

分布式工作节点

我们从 Hadoop 中学到的一些概念是 map/reduce，以及将小任务分配给 1..n 个分布式机器以“分担工作负载”。Hadoop 等大型项目也教会我们，在大多数情况下，设计良好的架构通过横向扩展（fanning out）而不是纵向扩展（fanning up）会更好地扩展。在构建我们希望扩展的系统时，使用这种扩展模式非常有益。在我们的网络爬虫架构中，我们可以设计轻量级的工作节点，它们不过是非常基本的插件式运行器外壳。这些的目标如下：

• 启动（在线程池中）
• 联系 Guvnor 获取指示
• 可选地下载/安装轻量级代码插件（否则使用现有的默认插件）
• 在默认/新插件中运行抽象的“execute”方法
• 完成爬取/其他任务
• 将结果报告给 Guvnor
• 终止，或返回 Guvnor 进行进一步工作（后者更有效率）

通过以这种方式使用分布式工作节点集群，我们可以高效地进行扩展，利用 Guvnor 按需动态地启动/关闭虚拟机。
 

托管优先级队列

我们之前讨论过优先级队列的概念。这种类型的队列索引量不大，非常适合例如一个简单、极其快速且高度可扩展的基于字典的数据库系统，如 Redis 或 Riak。这两种系统都可以轻松地用作*带优先级的* FIFO 数据库。



使用这些现有解决方案来处理大型系统的好处是显而易见的——它们为我们节省了大量的开发时间，经过了大规模的实际检验，最重要的是，它们服务于手头的目的。现在，这并不是说这些是唯一可以使用的解决方案——仅仅是它们似乎很合适。在考虑一项技术时，你应该始终考虑的不仅是它是否适用于手头的任务，还有你是否有技能和资源来处理它——*这才是关键*。

连接点

虽然我们可能使用字典数据库来跟踪我们的爬取队列，但我们可能会考虑其他技术来帮助我们管理获取的数据，以及我们获取的链接之间的关系。请记住，在爬取网络时，我们不仅需要知道我们要去哪里，还需要知道我们去过哪里，以及我们*去过*的地方与我们*将要*去的地方*如何*相关*（哇，我知道，这是一个蜘蛛网！）。很久很久以前，人们认为将所有东西都塞进一个技术栈是好习惯。现在情况已经不是这样了。找到并使用最适合手头工作的工具——如果将事物强行整合在一起更合适，就不要试图强行实现。



这样，我们可能会考虑使用 SQL Server 或 MongoDB 等工具来存储我们爬取过程中收集的更高级别的数据，然后使用更适合深度和复杂对象链接的工具来管理我们链接之间的关系。在这方面，我指的是近年来出现的极其有用的图数据库。值得注意的是 Neo4J 和 VelocityDB/Graph。从*所有事物*的 Oracle——维基百科——那里了解更多关于图数据库的知识。

要考虑的技术

语言和框架

总的来说，对于一项需要快速完成的小型任务，我通常建议坚持使用你已知的技术。如果你有一些时间，并且可以负担得起将这项工作作为一个学习项目，那么就尽情尝试一些新东西吧。 .Net 生态系统的优点在于，你可以（几乎）并排使用不同的语言，如 VB.net、C# 和 F#，也就是说，你可以从用一种语言编写的类/程序集调用另一种语言的代码。当你面临需要从一种语言转换到另一种语言的情况时，有时这是一个好方法——基本上是对旧代码进行“包围并替换”。

C# 是一种非常有能力的语言，我曾广泛用于爬取和抓取。然而，如果你对函数式语言家族提供的机会感到兴奋，那么考虑一下使用 F# 进行爬取和抓取可以获得的效率可能很有价值。Tomas Petricek 的这个 F# 示例代码 说明了如何使用 F# 进行爬取。如果你从未接触过 F# 或函数式语言，你会惊讶于它的清晰度——值得一读！

最后，关于语言，如果你想学习并站在巨人的肩膀上，你也可以考虑研究一下 Python 语言中可用的非常好的 Web Scraping 和 Crawling 库——这现在也得到了 .net 生态系统的支持。

我最近发现了一个有趣的 Web 爬取框架，它涵盖了本文中我们讨论的大部分内容，但不是全部。它叫做 ABot，它绝对值得一看和认真考虑。用维护者的话来说：
 

引用

Abot 是一个为速度和灵活性而设计的 C# 网络爬虫。

Abot 是一个开源的 C# 网络爬虫，专为速度和灵活性而设计。它负责底层的所有工作（多线程、HTTP 请求、调度、链接解析等）。你只需注册事件来处理页面数据。你还可以插件化你的核心接口实现，以完全控制爬取过程。Abot 目标是 .NET 4.0 版本。

它有什么优点？

• 开源（商业和个人使用免费）
• 速度快！
• 易于定制（插件化架构允许你决定爬取什么以及如何爬取）
• 经过大量单元测试（高代码覆盖率）
• 非常轻量级（不过度设计）
• 无进程外依赖（数据库、已安装服务等…）
• 可在 Mono 上运行

我将在以后的文章中对该框架进行详细介绍，因为它确实显示了很多潜力。当然，与其他开源项目一样，如果它们不能完全满足你的需求，你可以轻松地分支并进行自己的工作。
 

平台

除非你一直住在某个岛屿上，否则你不可能不知道 Microsoft 目前正在发生的巨大变化。开源的代码量之多，以及移植到*真正*多平台上的代码量之多，是惊人的，特别是考虑到他们过去的历史 OSS。真的，这是一个*巨大的*交易，我非常欢迎。我们都知道，多年来，Microsoft 的操作系统平台已经臃肿（就像许多其他平台一样），并且当然是高度面向桌面的。这并不是说 MS 服务器不好，不，我只是指出，对于绝大多数*通用*服务器应用程序，你根本不需要图形用户界面，一劳永逸。我在这里提出的观点是，在这个我们现在工作的以云为中心的世界里，你应该努力批判性地审视你的代码的应用，并决定它是否真的*需要*位于图形化操作系统上。如果不需要，那么你应该看看你能做什么来将其转移到替代方案。截至 2016 年初，如果你想在非图形操作系统上使用你的 .net 代码，你有一些不错的选择。第一个是编译和在 MONO 上运行你的代码。这是 .net OS 在某些类 UNIX 系统上的低级移植。第二个选择是针对新的“无头”MS 服务器平台，称为“NANO”——虽然还处于早期阶段（2016 年第一季度），但预计这个“云优先”的操作系统将为大规模基础设施式应用程序带来巨大的好处，并且对于大规模网络爬取安装可能非常有用。
 

引用

Nano Server 是 Windows Server 的一个深度重构版本，占用的空间很小，并且可以远程管理安装，针对云和 DevOps 工作流程进行了优化。它设计用于更少的补丁和更新事件，更快的重启，更好的资源利用率和更严格的安全。直接受到我们构建和管理全球最大规模云环境的学习启发，并在下一版 Windows Server 中可用，Nano Server 专注于两个场景：

1. 云原生应用程序——支持多种编程语言和运行时。（例如 C#、Java、Node.js、Python 等）在容器、虚拟机或物理服务器中运行。
2. Microsoft 云平台基础设施——支持运行 Hyper-V 的计算集群和运行 Scale-out File Server 的存储集群。

Nano Server 将允许客户仅安装他们需要的组件，不多也不少。初步结果令人鼓舞。根据当前版本，与 Server 相比，Nano Server 具有：

• VHD 大小降低 93%
• 关键公告数量减少 92%
• 重启次数减少 80%

附加代码

我附上了一些演示使用线程从网站获取数据的示例代码。它来自我之前关于线程的文章，从线程的角度来看是相关的。我将在接下来的短时间内提供更多有用的网络爬取演示代码。

摘要

这完成了本文的基础知识。系列中的下一篇文章将介绍代码的实现。

最后——如果你喜欢这篇文章，请在上方投一票！！

历史

2016 年 3 月 24 日 - 版本 1 *（包括一次大型编辑器崩溃，不幸丢失了大量文章！）*
2016 年 3 月 26 日 - 版本 2 - 添加了关于整体架构的部分
2016 年 3 月 30 日 - 版本 3 - 次要更正，链接。
2016 年 4 月 3 日 - 版本 4 - 添加了 Amazon robots 文件的示例，添加了其他相关链接
2016 年 4 月 4 日 - 版本 4.1！- 添加了关于布隆过滤器及其在爬虫引擎中使用的信息
2016 年 4 月 5 日 - 版本 4.2 - 添加了关于 T&C 的信息，进行了一些更正
2016 年 4 月 7 日 - 版本 4.3 - 修改了副本和新链接文章