Python，Node.js 哪个比较适合写爬虫

Posted 2023-04-17

简单的定向爬取：
Python + urlib2 + RegExp + bs4
或者
Node.js + co，任一一款dom框架或者html parser + Request + RegExp 撸起来也是很顺手。
对我来说上面两个选择差不多是等价的，但主要我JS比较熟，现在选择Node平台会多一些。

上规模的整站爬取：
Python + Scrapy
如果说上面两个方案里DIY 的 spider是小米加步枪，那Scrapy简直就是重工加农炮，好用到不行，自定义爬取规则，http错误处理，XPath，RPC，Pipeline机制等等等。而且，由于Scrapy是基于Twisted实现的，所以同时兼顾有非常好的效率，相对来说唯一的缺点就是安装比较麻烦，依赖也比较多，我还算是比较新的osx，一样没办法直接pip install scrapy

另外如果在spider中引入xpath的话，再在chrome上安装xpath的插件，那么解析路径一目了然，开发效率奇高。 参考技术A NodeJS：对一些垂直网站爬取倒可以，但由于分布式爬取、消息通讯等支持较弱，根据自己情况判断。 Python：强烈建议，对以上问题都有较好支持。尤其是Scrapy框架值得作为第一选择。优点诸多：支持xpath；基于twisted，性能不错；有较好的调试工具； 此种情况下，如果还需要做js动态内容的解析，casperjs就不适合了，只有基于诸如chrome V8引擎之类自己做js引擎。 参考技术B 最好的爬虫语言是前嗅的ForeSpider爬虫脚本语言。是一门专门的爬虫脚本语言，而不是爬虫框架，可以用简单几行代码，实现非常强大的爬虫功能。
ForeSpider是可视化的通用性采集软件，同时内置了强大的爬虫脚本语言。如果有通过可视化采集不到的内容，都可以通过简单几行代码，实现强大的脚本采集。软件同时支持正则表达式操作，可以通过可视化、正则、脚本任意方式，实现对数据的清洗、规范。

对于一些高难度的网站，反爬虫措施比较多，可以使用ForeSpider内部自带的爬虫脚本语言系统，简单几行代码就可以采集到高难度的网站。比如国家自然基金会网站、全国企业信息公示系统等，最高难度的网站完全没有问题。
在通用性爬虫中，ForeSpider爬虫的采集速度和采集能力是最强的，支持登录、Cookie、Post、https、验证码、JS、Ajax、关键词搜索等等技术的采集，采集效率在普通台式机上，可以达到500万条数据/每天。这样的采集速度是一般的通用性爬虫的8到10倍。
对于大量的网站采集需求而言，ForeSpider爬虫可以在规则模板固定之后，开启定时采集。支持数据多次清洗。
对于关键词搜索的需求而言，ForeSpider爬虫支持关键词搜索和数据挖掘功能，自带关键词库和数据挖掘字典，可以有效采集关键词相关的内容。
可以去下载免费版，免费版不限制采集功能。有详细的操作手册可以学习。 参考技术C 看你更熟悉哪一个咯

Node.js vs Ruby on Rails：哪个最适合Web开发？

点击关注公众号，每天 免费 推送价值 800元的 文章 

大家好，在本文中，我们将比较Node.js和Ruby on Rails在Web开发上孰优孰劣。我写这篇文章的主要原因是我们的团队不断被问及哪种语言或哪个框架最适合学习。无论如何，我们从不给出一个简单的答案，因为就没有一个明确的答案。

我认为最好是依据事实和统计数据说话。我们将了解Node.js和Ruby on Rails在服务器端技术方面的一些优缺点。

在开始之前，我想先说说我的一些看法。有批评者可能会质疑我们如何将作为运行时的Node.js与作为框架的Ruby on Rails进行比较？我接受这样的质疑，但我要比较的是两个服务器端技术和Web栈。我们要弄清楚现在学什么更好，以及对于业务哪个更佳。我的意思并不是说直接比较Ruby on Rails和Node.js的功能，如果你觉得用Express或者其他基于Node的框架代替Node.js会更好的话。无论如何，我们比较的是后端结构和堆栈，而不是个别技术。

我们的团队已经使用过这两种技术，并且我们中的一些人对这两种技术都很喜欢。我不是在厚此薄彼。重要的是要知道适合我们的可能并不适合你，反之亦然。另外，你应该记住，每个人的大脑都是不同的。所以，孰胜孰劣并不定论。

首先让我们来看看这两种技术之间的一些相似之处。

• 受欢迎的服务器端技术。

• 相当容易学习。

• 高性能。

• 为顶级网站/应用程序使用。

• 强大的社区。

• 基于类似MVC的结构。

• 快速开发。

Node.js和Rails都是备受推崇和流行的服务器端技术，可以做很多不同的事。它们可以与许多不同的堆栈和数据库等等协同工作。两者都相当容易学习。Node使用JavaScript，而Rails使用Ruby。但是Ruby和JavaScript比Java，C#或其他一些高级语言更容易学习。它们都是相当宽容的语言，有大量的资源可供学习。Node.js和Ruby on Rails执行优良，因此我们将讨论性能水平。有很多流行网站使用这两种技术。Node和Rails拥有非常强大和坚持自我的社区。

Rails存在的时间更久一点，有更多老前辈。但是Node日渐变得越来越流行。现在MVC，即Model-View-Controller成为了一种设计模式。而Ruby on Rails有很强的MVC。针对模型、控制器和视图有一个文件夹。通过Node中的某些框架，例如Express，可以实现MVC。不过，Express比Rails更灵活。你可以只采纳MVC的某些方面。这不是唯一可能的结构。Node和Rails用于快速开发和原型。Rails有一个很棒的折叠功能，当然Express也有生成器和命令行工具。

Rails的优点

• 一致的结构。

• 非常坚持自我。

• 数据库迁移。

• 开发速度。

• Ruby是一门伟大的语言。

• Ruby gems。

• 成熟和受尊重的社区。

首先，让我们来看看Ruby on Rails的优点，然后再看缺点。正如我所说，Rails有一个非常强大的MVC结构。大多数Rails应用程序在核心文件和文件夹方面看起来非常相似。有了这个坚实的基础之后，然后在gems和自定义的包和库之上构建。另外，Rails非常坚持自我，这就意味着它允许你坚持自己的做事方式。Rails假设你将要以某种方式编写代码，有些人可能会说这稍微有点限制。但是它也使代码变得更简单，更简洁，而且也使得更不容易创建错误和出现问题。从某种意义上说，你不能制造你想要的东西，但却是助你到达目的地的途径。如果你以正确的方式去做，那很可能就是最简单的方法。

Rails也有非常好的数据库迁移功能。它们允许我们在数据库中创建和编辑表格与列，而无需手动进入去添加或更改内容。它也会给你一个很好的小日志或路径，允许你查看对数据库结构究竟做了什么。

现在再说Node。有一些用于迁移的软件包或模块，比如DB-migrate就可以很好地工作，但不像Rails chord migration system那样深入和易于使用。在原型设计和快速开发方面，没有太多技术可以打败Rails。所以，通过一些基本配置和一些scaffolding命令，你可以拥有一个完整的CRUD应用程序。数据库迁移被添加到这个速度。如果你使用第三方工具和模块的话，Node.js和Express在快速开发方面相当不错。但Rails拥有的所有这些东西都是开箱即用的。

Ruby语言有优点也有缺点，但在大多数情况下，它是很受尊敬的，而且非常干净。 Ruby是一个多范式语言，你可以做到程序代码功能化，但大部分是面向对象的。一切都可以看作是一个对象。RubyGems是Ruby on Rails的包管理器，它用于扩展框架的核心功能。这与Node.js的npm相似。所有Rails应用程序都有一个gem文件，你可以在其中指定你的gems。然后运行bundler命令来安装它们，类似于使用Node.js的npm install。

关于Ruby on Rails的另一个好处是，它已经存在了一段时间，因此拥有一个非常受人尊重的智能社区。维护Ruby on Rails的开发人员非常聪明，并且非常热爱框架。核心框架上有大量资源，包括论坛，博客文章和文档，以帮助你解决问题。这些都是Ruby on Rails的巨大优势。

Rails的缺点

• 性能

• 太简单

• 声望

• 缺乏文档

我们来谈谈Rails的一些缺点。我们知道的关于Ruby on Rails的最大抱怨是它相对较慢。Rails是一个很大的框架，有很多很多功能。除了一些较轻便的框架之外，还有gem和应用程序文件依赖的因素。有太多的自动化和scaffolding，以致于开发人员并没有真正学习很多关于Rails框架如何工作的内容。你可能了解Ruby语言，了解应用程序的语法或结构，但对于真正了解Rails如何工作的人来说，自动化和scaffolding是非常棒的，因为有助于快速开发。另一方面，一些开发者的确需要做更多的努力才能真正理解某些事情。Rails对于大型项目，也比小型应用程序更困难。它也有一些缩放问题。

所以另外一个缺点是Rails不像Node.js那样受欢迎。此时，Node.js处于Web开发的前沿，而且Rails令人兴奋的时代已经逝去。我们认为，如果你正在找工作，那么我们言之凿凿地建议学习Node，以及可能的话还有Express。比起其他语言，有更多的公司正在招聘JS开发人员。如果是在五年前，那么Rails或Ruby必将是值得学习的前三大语言之一。但是现在它没有那么受欢迎了。所以我在前面简单地提到，核心Rails框架有一些非常好的文档和示例，可以让你学习简单的scaffolding命令和数据库迁移。这一切都很好。然而，当你试图学习更高级的编程，并且试图了解特定的gems时，有时候感觉就像大海捞针一样。

一些名气相当大的平台曾经使用过或正在使用Ruby on Rails。Twitter就是其中一个巨头。另外，由于一些扩展问题，他们已经把很多后端服务移到了Scala和Java上。但是由于他们使用过Rails很长一段时间，所以我非常确定他们仍然在平台的其他方面使用它，比如与Shopify的合作。此外，作为项目管理解决方案的Basecamp表示，Rails是他们项目的核心和灵魂。运行GitHub的软件是建立在Rails上的。Soundcloud和Hulu，流行的流媒体服务，都是建立在Rails上的。从一开始，Groupon和LivingSocial，SlideShare和Urban Dictionary就在他们的开发中使用Rails。

Node.js的优点

• 非常受欢迎。

• 高性能。

• 异步。

• 非常可扩展。

• JavaScript前端和后端。

• 灵活的文件结构。

• npm和模块。

看了Rails之后，现在让我们开始看看Node.js。我们将从它的优点开始。Node.js的一个巨大的优势是它非常受欢迎。它基本上是web开发中的最新的尖端技术。市场需求非常大。极其受创业公司的欢迎。围绕Node和Express框架有一个繁荣的开源社区。在npm基础上有很多开发良好的模块，并且当谈到速度和性能的时候，Node对上Rails有着绝对的优势。事实上，Node几乎所向披靡。它运行在速度如闪电般的Google JavaScript引擎上。Node用于构建几乎感觉像桌面应用程序一样的实时Web应用程序。

接下来，Node.js也是异步的。这意味着程序向服务器发送请求时，不必等待回复。它可以继续执行。Node运行在单个线程上，而不像其他语言一样发送请求。这些语言需要等待，直到请求完成，然后发送下一个，再等待。所以Node.js也是非常可扩展的，在单线程中发挥了很大的作用。Node也可以和像MongoDB这样的NoSQL数据库一起工作，它比传统的关系型数据库如MySQL更具可扩展性。几乎所有我了解的大公司都转移到了Node.js上，他们报告说生产力有了很大提高。

Node的另一个很棒的优势是它使用JavaScript，而JavaScript被广泛用于许多Web栈。很多时候，前端的语言与后端的语言是不一样的，但是在使用Node.js的时候并不是这样。我们在前端和后端都可以使用JavaScript。有很多主导业界的客户端框架——React，Angular，Vue.js。所以这对Node.js来说是一个巨大的优势。显然，JavaScript也和非常受欢迎的JSON API也可以协同工作。

Node.js，Express或Happy.js，这些框架中的任何一个都具有非常灵活的文件结构。它们能让你构建你想要的应用程序。你可以将所有内容都塞进应用程序的单个JS文件。如果你想有更多传统的MVC结构，那就有利有弊了。但是大多数情况下，如果你知道你在做什么，而且你是一个好的程序员，那么灵活性是一件好事。和Ruby gems一样，Node也有它自己的包管理器，称为npm或Node包管理器。npm和Ruby gem最大的区别就是依赖关系的管理方式。使用Ruby，依赖关系是全局安装的。所以你必须使用捆绑器，并且必须自己管理它们。 npm实际上负责你的所有模块。它们被放入Node模块文件夹。这些模块也可以拥有自己的Node模块文件夹，并具有自己的依赖关系。npm模块似乎也有更好的文档，至少以我的经验来看是这样的。

Node.js的缺点

• 糟透了的CPU密集型任务。

• 不一致性。

• 较新的技术。

• 回调地狱。

• 太模块化。

好的，既然我们了解了Node.js的优势之后，让我们来看看它的一些缺点。对于许多CRUD类应用程序来说，Node是很好，但对于CPU密集型应用程序来说，这绝对是一件非常糟糕的事情。原因是，只要执行某些操作一些时间（例如CPU操作），它就会将所有传入的请求排队，因为它在单个线程上运行。像Apache这样有更多可用线程的，将会在它们之间分配CPU时间。只有IO操作是并行的，因为它们是异步执行的。CPU密集型任务的例子为3D渲染，视频编码，科学建模等等。

关于Node的另一个抱怨是它可能有点不一致。有些人觉得API保持经常的改变。它有时不是很向后兼容。不仅如此，而且Express应用程序的结构通常非常自由和灵活。因此，有时它反而会使得开发者作茧自缚。

Rails是非常严格的，所以编写坏代码更困难。由于Node是异步的，所以你将会处理很多回调函数，它们经常会蜂拥而至并进入所谓的回调地狱（callback hell）。对此的解决方案有异步工具和使用promises。你也可以做一些事情来预防。我觉得就我个人而言这不是问题，但我知道一些不习惯异步编程的开发人员对回调真的很头疼。

正如你可以看到这两个后端选择都有其优点和缺点，但它们都是很棒的技术。我们应该根据具体情况具体对待，而不是绝对地说这个比另一个更好。

文章来源于网络，如有侵权请联系我们，将予以删除

      一个集50万的技术大牛圈子

         

  程序员期刊

---

ID:http546