UDN-企业互联网技术人气社区

板块导航

浏览  : 1206
回复  : 0

[资源分享] 使用 Apache Kafka 和微服务实时分析 Twitter 趋势,第 2 部分

[复制链接]
htmlman的头像 楼主
发表于 2016-10-8 14:27:17 | 显示全部楼层 |阅读模式
  处理实时 Twitter 数据流应用程序的后端架构

  在这篇博客文章中,我们将分析后端架构,该架构使 Match Tracker 能够"实时"分析数千条有关足球比赛的推文。该应用程序必须能够跟踪正在进行的比赛,不断搜索所有有关比赛的消息,并实时处理所有生成的数据。
1.jpeg

  我们不会设计单一的整体式应用程序架构,让所有这些组件和服务作为一个整体运行,而将使用微服务方法,将应用程序分解为可单独运行的独立服务。使用微服务架构具有许多优势,其中包括让扩展处理管道的各部分变得更简单,因为隔离了故障会提高系统恢复能力,让我们能够混合使用不同的语言、库和框架。

  下图展示了该应用程序的组件和服务的整体架构。
2.png

  图字:Message Hub:消息中心 Tweet Search:推文搜索 Tweet Processor:推文处理器 Web App:Web 应用程序

  该应用程序的处理管道使用以下 3 个微服务:

  FixtureMonitor 服务

  此服务使用外部 API 监视即将到来的足球比赛。由于可能与其他比赛的安排有冲突,所以会定期重新安排赛程。我们会用所有更改来更新赛程数据库,使之与比赛开始时间相符。每次比赛开始时,该服务都会负责将事件细节发送到一个消息队列,供另一个微服务进行处理。它使用比赛细节来创建搜索查询,使用该查询来监视有关某个事件的推文。TwitterSearch 服务

  此服务执行传入搜索查询,使用 IBM Insights for Twitter 服务查找有关足球比赛的推文。来自 Twitter API 的结果被作为单独的推文发送给另一个主题进行处理。针对比赛的搜索查询包括开始和结束时间,用于确保搜索是在整场比赛期间进行的。收到新比赛搜索请求时,搜索服务需要在接下来的两小时内轮询,以便"实时"检索结果。TweetProcessing 服务此服务处理 Twitter 服务返回的推文,将结果存储在一个数据库中,供 Web 应用程序进行访问。Twitter 搜索结果包含大量有关各种消息的元数据。从搜索结果提取众多属性并查看推文中提到了哪些球队,然后将内容作为文档存储在 Cloudant 数据库中。当该服务检测到推文中的情绪时,"polarity" 属性就会表明该情绪划分为正面、负面还是中性。

  Match Tracker 微服务的源代码在 GitHub 上的 IBM-Bluemix/match_tracker/microservices 项目中。

  使用 Apache Kafka 实现可伸缩的消息排队

  Apache Kafka 提供了一个可伸缩的消息队列,其中消息生成者会将记录发送到由使用者处理的主题。在 Match Tracker 应用程序中,我们使用消息队列作为微服务之间的通信总线。我们在该应用程序中使用了两个队列,一个用于对 Twitter 搜索请求进行排队,另一个用于对来自搜索结果的推文进行排队。

  使用消息队列安排任务,使得在多个服务实例之间分发工作和处理实例故障而不丢失工作变得很简单。Kafka 支持对从主题读取记录的使用者同时采用发布-订阅和队列消息模式。它通过允许使用者属于使用者分组来实现此目的。发布到一个主题的每条消息都被传送到每个订阅使用者组内的一个使用者实例。如果所有使用者实例都属于同一个组,那么这个组类似于传统的消息队列。如果所有使用者属于不同的组,则类似于发布-订阅主题。

  Match Tracker 使用了消息队列方法,所有使用者都属于同一个组,每条消息都由一个使用者实例处理。例如,我们不想多个使用者实例运行相同的 Twitter 搜索。采用这种模式意味着随着我们将会调整微服务实例数量来处理变化的负载,消息队列将透明地处理所有实例之间的工作分发,无需对应用程序进行任何修改来处理这种情况。

  Kafka 简化了应用程序故障的处理

  使用 Kafka 建立消息队列来安排工作,还使得从处理任务期间发生的应用程序故障中恢复变得很简单。如果在运行长时间 Twitter 搜索期间,使用者实例发生崩溃,或者在保存已处理的推文时数据库提交失败,我们希望重新安排这些任务而不丢失任何工作。在此场景中,无需手动重新发布任务,我们可以使用 Kafka 的"手动偏移量提交"模式来自动处理这种情况。当使用者阅读来自某个主题的消息时,他们会将最后一条消息的偏移量提交回该主题,让后一个使用者能够阅读该主题上的新消息。此提交过程可在成功读取所有消息后自动发生,也可以由客户手动控制。

  在使用手动提交模式时,工作者可以安排任务的处理,仅提交自后台工作完成以来(而不是开始之前)读取的消息。如果处理任务失败,则不会提交这些消息偏移量,它们最终会被发送到另一个使用者实例。在我们的应用程序中,我们对 Twitter 搜索请求和推文结果处理作业都采用了这种方法。处理推文结果时,使用者从队列读取一系列推文,处理它们,然后将结果保存为数据库的批量更新。已处理消息的主题偏移量仅在数据库更新成功完成后处理。

  Twitter 搜索是一项会花费很长时间的工作任务,将在比赛的两小时内一直运行,这比手动提交消息偏移量所用的最长时间还要长。因此,我们会在Twitter 搜索成功开始后提交消息的偏移量。如果运行 Twitter 搜索的微服务实例在此刻之后失败,我们需要采用某种机制来重新启动以前的作业,而不是将它们自动发送给另一个使用者。

  我们可以轻松地处理该场景,因为 IBM MessageHub 会将所有已发布消息保留 24 小时。实例重新启动时,会首先读取所有保留的消息,而不是从使用者上一次的偏移量开始。如果搜索查询包含未来的结束时间,那么我们就会知道该作业应该处于"活跃"状态,因此可以为该记录重新启动后台搜索进程。

  从零个搜索结果扩展到数千个结果

  根据时间安排,可能有数十场比赛同时举行,每场比赛都会产生数千条 Twitter 搜索结果。架构必须能够处理处理从 0 到大量流量的负载。

  Fixture Monitor 服务是一个轻量型服务,在比赛开始之前的大部分时间里,它都处于休眠状态。该服务是作为单个实例而运行的,无需为期提供扩展到多个进程的支持。当多场比赛同时开始时,处理负载会拆分到 Twitter Search 和 Tweet Processing 微服务。两个服务都支持"水平扩展",允许同时运行无状态服务的多个实例来分散负载。Kafka 的订阅者分组功能会自动处理实例之间的消息分布。使用 IBM Bluemix 中的 Auto Scaling 服务,该平台可基于 CPU 或内存使用量等性能指标,在繁忙期自动创建新实例,并在之后删除它们。

  此架构意味着应用程序可以在运行时动态扩展来处理大量负载,不会出现任何宕机。

  使用 Twitter Insights 将各个部分衔接起来

  IBM Insights for Twitter 允许用户通过布尔运算符来组合关键词,以便从可用的语料库中同时搜索历史推文和实时推文。在我们的应用程序中,我们希望发现在比赛进行期间发送的所有引用了足球比赛的推文。Premier League 有一个官方主题标签集,用于标记对球队和比赛的引用。通过搜索比赛球队,我们可以进而搜索包含比赛主题标签或同时包含球队主题标签的推文。例如,当曼联在 Everton 比赛时,可以将该搜索转换为以下搜索查询:

  ((#MUFC AND #EFC) OR (#MUNEVE))

  搜索中还可以包含开始和结束时间,以筛除这段时间外包含这些词汇的消息。在 Twitter Search 微服务中,通过在比赛进行期间用 Twitter 服务不断轮询搜索词汇,我们可以检索所有可用的推文。在每次发送请求时,调整开始时间过滤器值可以确保我们不会收到以前的结果。推文从 Twitter 的"消防带"过滤到IBM Insights for Twitter 服务中可能会花 60 秒时间。在开始轮询之前应添加人工延迟,这样可以确保在发送搜索请求之前已有结果可用。

  结束语

  使用 Apache Kafka 作为消息总线来连接微服务,使得设计可伸缩的、稳健的架构来处理 Twitter 流变得非常容易。通过利用使用者组,消息系统可在数量不断变化的使用者实例之间分配工作。手动提交记录偏移量,使该应用程序能自动从故障中恢复,而不会丢失任何工作。部署在 IBM Bluemix 上的具有"自动扩展"功能的微服务,意味着该平台可在负载增加时自动扩展服务。现在我们已成功地"实时"处理数千条推文,我们可以看看能对结果执行哪些操作。

原文作者:佚名 来源:http://www.ibm.com/

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部