问爬虫设计-调用异步作业与调用服务

EN

如果爬虫服务同步调用这两个服务，会发生什么情况？

首先，最慢的服务将成为爬虫的瓶颈。同步调用意味着爬虫需要等待服务处理请求。在排队的情况下，爬虫将工作得更快，处理新的链接，而不是等待其他服务。我们可以假设爬虫可以有自己的内部队列。

第二点--耐久性。如果一个或多个链接丢失了，如果任何服务都会被关闭，并且无法处理来自爬虫的请求，这可能就不那么重要了。但是队列可以是持久的，在磁盘上保存状态，在停止时恢复它的工作。如果所有服务同时中断，并且许多链接将丢失，则可能非常有用。

我认为可能的原因是如果其中一个失败的话，更复杂的流控制。

这种方法不灵活。通常，您应该能够添加任意数量的新服务，可以轻松地扩展工作负载，而无需对代码进行任何更改。因此，“流控制”不应该作为每次添加或删除服务实例时都需要修改的代码而存在。在可以向上或向下扩展的实际应用程序中，所有这些操作都是自动完成的，而无需重新部署应用程序。

这种设计选择背后可能有更多的原因，但几乎可以肯定的是使用微型服务。它是一种流行的技术，因此演示它的命令是回答设计问题的一个好主意，维基百科很好地描述了它的好处：

• 模块化:这使得应用程序更容易理解、开发、测试，并更好地抵御体系结构的侵蚀。6与单块体系结构的复杂性相比，这种好处常常被认为是有好处的。
• 可伸缩性:由于微服务是相互独立地实现和部署的，即它们在独立的进程中运行，因此可以独立地监视和扩展它们。
• 异构和遗留系统的集成:微服务被认为是使现有单块软件应用现代化的可行手段。35有几家公司的经验报告说，它们已经成功地用微服务取代了现有软件的(部分)，或正在这样做。37遗留应用程序的软件现代化过程是以增量方式完成的。
• 分布式开发:它通过使小型自治团队能够独立地开发、部署和扩展各自的服务来并行开发。39它还允许通过连续重构出现单个服务的体系结构。40基于微服务的体系结构有助于持续集成、连续交付和部署。

所有这些都适用于这种情况。事实上，定义良好的API使模块分离、可重用、易于理解.很可能这三个模块中的每个模块都有非常不同的执行时间和CPU/内存需求，因此单独扩展它们很有意义。页面上提到的一些公司可能会进一步将这些模块分割成基于团队号的微服务，因此这种分割成3种服务的前提是假设有3个团队，而不是技术上的限制。

这一页还描述了对这项技术的批评。