【问题标题】:crawler design - calling an async job vs. calling a service爬虫设计 - 调用异步作业与调用服务
【发布时间】:2020-06-14 04:27:48
【问题描述】:

我正在查看donne martin's design for a web crawler。 爬虫服务处理一个新爬取的url,然后:

  • 作业添加到反向索引服务队列以生成反向索引
  • 作业添加到文档服务队列以生成静态标题和sn-p

如果爬虫服务同步调用这两个服务会发生什么?我仍然可以根据每个服务的负载水平扩展所有 3 项服务,对吧?如果其中一个失败,我认为可能的原因是更复杂的流量控制。这些异步作业还有其他更令人信服的原因吗?

【问题讨论】:

    标签: asynchronous architecture microservices jobs system-design


    【解决方案1】:

    如果爬虫服务同步调用这两个服务会发生什么?

    第一点——那么最慢的服务将成为爬虫的瓶颈。同步调用意味着爬虫需要等待请求被服务处理。在队列的情况下,爬虫将更快地工作,处理新链接而不等待其他服务。我们可以假设爬虫可以有自己的内部队列。

    第二点——耐用性。如果任何服务出现故障并且无法处理来自爬虫的请求,是否会丢失一个或多个链接也许并不那么重要。但是队列可以是持久的,可以在磁盘上保存状态,在它停止的地方恢复它的工作。如果所有服务同时关闭并且许多链接将丢失,则可能非常有用。

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

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

    【讨论】:

      【解决方案2】:

      这种设计选择背后可能有更多原因,但几乎可以肯定是使用Microservices。这是一种流行的技术,因此演示它的命令是回答设计问题的好主意,它的好处在维基百科上有很好的描述:

      • 模块化:这使应用程序更易于理解、开发、测试,并且对架构侵蚀更具弹性。[6]与单体架构的复杂性相比,这种优势经常被争论。[33]
      • 可扩展性:由于微服务是相互独立实施和部署的,即它们在独立的进程中运行,因此可以独立监控和扩展。[34]
      • 异构系统和遗留系统的集成:微服务被认为是对现有单体软件应用程序进行现代化改造的可行手段。[35][36]有几家公司的经验报告已经成功地用微服务替换(部分)他们现有的软件,或者正在这样做。[37]遗留应用程序的软件现代化过程是使用增量方法完成的。[38]
      • 分布式开发:它通过使小型自治团队能够独立开发、部署和扩展各自的服务来实现并行开发。[39]它还允许通过持续重构来出现单个服务的架构。 [40]基于微服务的架构有助于持续集成、持续交付和部署。 [41] [42]

      所有这些都适用于这种情况。事实上,定义良好的 API 使模块分离、可重用、易于理解。很可能这 3 个模块中的每一个都有非常不同的执行时间和 CPU/内存要求,因此单独扩展它们很有意义。页面上提到的一些公司(如亚马逊)可能会根据团队编号将这些模块进一步拆分为微服务,因此可以根据拥有 3 个团队的假设而不是技术限制来选择这种拆分为 3 个服务的服务。

      该页面还描述了对该技术的批评。

      【讨论】:

      • 谢谢!但我认为这里存在误解:我不是在问为什么我们不应该将它们分成自己的微服务,我完全同意这是一个好主意,因为你提到的所有好处。我正在考虑为什么我们应该异步而不是直接通过 API 调用它们。它们仍然是微服务,对吧?
      • 不完全是因为你不能单独对它们进行负载平衡,这正是我在笔记中提到的。如果是直接同步调用,性能会受到最慢操作的限制。 Downvoter 是否愿意解释或发布更好的答案?
      猜你喜欢
      • 2020-02-06
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-03-15
      • 1970-01-01
      • 2011-09-03
      相关资源
      最近更新 更多