文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

人类如何做出决策? 在日常生活中,情感总是导致在复杂或关键性行为仓促决定的关键因素。但对专家而言,做出有长期影响的复杂决策,不可能是纯粹依赖冲动。一旦他们那专业的潜意识吸收了作出决定所需的所有事实,就会快速利用“本能”,“直觉”,或其他的情绪立即做出决定。

今天有很多的消息传递技术, 在市场上也有数不清的 ESBs,和近100 iPaaS供应商。 自然,这导致了有关如何为您的需要-特别是那些已经投资在一个特定的选择,选择正确的消息传递技术的问题 。我们选择很多吗? 能用正确的工具做正确的工作就行?我们有没有正确地布置手头的工作以满足业务需求? 鉴于此,对我来说,合适的工具是什么? 更糟糕的是,详尽的市场分析可能永远无法完成,但由于集成代码的平均寿命,尽职调查是至关重要的。

第 1 段(可获 2.1 积分)

这篇文章致力于给予潜意识,表意识 一些公平的考虑,从今天最现代,最受欢迎的选择: RabbitMQ和Apache Kafka。 每个都有自己的起源故事, 设计意图,使用案例,被应用, 整合能力,和开发人员的经验。对于任何的软件,起源揭示总体设计意图,都是一个很好的起点。

起源

RabbitMQ 是一个 “传统的” 消息代理,实现多种消息传递协议。 是第一个达到合理的功能水平,有看的过去的客户端库,开发工具,和质量文档,的开源消息代理。 RabbitMQ 最初开发实现了AMQP(一种具有强大路由功能,消息传递的,开放式路由协议)。尽管Java有自己的消息传递标准,比如JMS,但不适用于需要传递消息的分布式,非java应用,这严重限制了很多集成方案,微服务或单组件。直到AMQP到来,它那跨语言的灵活性,帮助RabbitMQ 成为了真正的开源消息代理。

第 2 段(可获 2.01 积分)

Apache Kafka是用Scala开发的,起初应用于 LinkedIn ,作为一种简化Hadoop 从 Apache Flume提取消息的方案。  kafka实现了复数数据源生产数据,复数消费端消费数据,并能为每个数据源和消费端配对独立的数据管道。Kafka 帮助 LinkedIn 标准化数据管道,并允许将数据从每个系统中取出一次,然后向每个系统存入一次,使相关操作更简单。Kafka是如今Apache软件基金会软件的通用配置。特别地,很好的与Zookeeper集成,实现了Kafka分布式分区集群。 许多人认为 Zookeeper的作用并不是那么大,但它赋予了Kafka用户使用集群的能力。

第 3 段(可获 1.58 积分)

体系结构和设计

RabbitMQ i被设计为通用消息代理,实现了点对点的几种变化, 比如请求/答复和发布-订阅通信风格模式。它使用智能代理/哑消费者模型,专注于消息传递的一致性,跟踪消费者的状态,保证数据以大致相同的速度被消费。它在配置正确时表现良好,性能成熟,支持完善 (客户端库包括 Java, .NET, node.js, Ruby, PHP和很多其他语言),扩展众多,这也将其应用到了更多使用区域和集成场景。

第 4 段(可获 1.2 积分)

图15 - 简化的整体 RabbitMQ 体系结构(source). 

RabbitMQ的通信,允许设置为同步或异步。生产者者发送消息到交换区,消费者从交换区队列检索消息。 通过发送消息到交换区的形式,生产者被解耦,也就不需要承担路由硬编码压力。 RabbitMQ 还提供了一些分布式部署方案 (要求所有节点可以解析主机名),比如设置为多节点为集群,并且不依赖外部服务 (但设置集群可以借助AWS APIs, DNS, Consul等插件)。

第 5 段(可获 1.2 积分)

Apache Kafka 是专为高容量发布-订阅消息流设计的,意味着它耐用,快速,而且可扩展。Kafka 在服务器集群中运行,提供持久的消息存储(在某些方面,本质上,有些类似于数据库),它分类下存储的流记录被称为主题。

图11 - 全局 Apache Kafka 体系结构(1 主题, 1 分区, 4 复制因子). (source).

每条消息包含一个键,一个值和一个时间戳。 同RabbitMQ相反, Kafka使用了哑代理/智能消费者模型,消费者自行读取缓冲区。 Kafka不尝试跟踪那些被消费者消费的消息,只保留未读消息;Kafka只保留消息的时间戳,消费者自行负责跟踪每个数据在日志的位置 (消费状态)。 因此,优良开发者才能创建优良的消费者代码, Kafka 可以仅仅花费很少的开销,就完成支持大量消费者并且保留大量数据的工作。而且,正如上图所示,Kafka需要外部服务的支持 - 在这种情况下,Apache Zookeeper, 通常被认为是kafka正常运行,配置,操作所必备的。

第 6 段(可获 2.4 积分)

需求和用例

许多开发人员,当他们意识到他们必须把很多东西连接在一起,比如不同的集成模式,比如共享数据库不可行或太危险,的时候,开始探索消息传递。

Apache Kafka 自述为分布式流媒体平台,但人们更愿意相信它一个持久的存储库,自带很好的Hadoop/Spark支持。它的文档做得很好,描述了很多流行用例,比如网站活动跟踪、统计,日志聚合,流处理,事件溯源或日志提交。有的用例描述的不清晰,可能会带来一些混乱。 所以让我们走近一点,更清晰的看一看,哪种消息方案更适合Kafka,比如:

第 7 段(可获 1.48 积分)
  • 从A到B的流没有复杂的路由, 有很高的吞吐量(100k/sec+),还要求至少一次按分区顺序交付。
  • 当你的应用程序需要至少一次的流历史和分区交付顺序的访问。Kafka是持久的消息存储,可以完成客户“replay” 事件流的需求。而更传统的消息代理,一旦消息被交付,就会从队列中移除,不会保留历史。
  • 当你有聪明的消费者,能可靠地跟踪他们的日志偏移(消费状态)。
  • 如果您的应用程序需要 “无限的” 队列。

RabbitMQ是一个通用消息传递解决方案,通常用于,当用户等待结果时,允许web服务器快速响应请求,而不是被迫重复执行耗费资源的程序。也适用于分发一条消息到复数消费者进行消费, 或在高负荷条件下平衡worker之间的荷载 (20k+/sec)。即使你的需求不只是吞吐量, RabbitMQ也有很多解决方案: 各种特性比如可靠消息传递,路由,组合,HA,安全, 管理工具和其他特性。让我们看看一些更适合RabbitMQ的场景,比如:

第 8 段(可获 2.29 积分)
  • 您的应用程序需要与现有协议组合,比如AMQP 0-9-1, STOMP, MQTT, AMQP 1.0.
  • 你需要为您的信息传递提供成熟、容易理解的一致性保证,。
  • 你的应用需要提供多种点对点协议,比如请求/应答和发布/订阅模式.
  • 复杂的消费者路由,多服务/应用程序整合,路由逻辑难以控制。
  • 与现有的 IT 基础设施整合。

RabbitMQ 也不是不能解决上面那几个更适合Kafka的用例,但要借助额外的软件。当应用程序需要访问流历史时,Apache Cassandra是很好的选择,如果需要 “无限” 队列,可以借助LevelDB插件,但它们都不是RabbitMQ自带的。

第 9 段(可获 1.5 积分)

为了更深入了解微服务, Kafka和RabbitMQ的特定用例,请查阅博客, 阅读这篇短文章by Fred Melo.

开发经验

RabbitMQ正式支持Java, Spring, .NET, PHP, Python, Ruby, JavaScript, Go, Elixir, Objective-C, Swift - 与许多其他 客户和开发工具,通过社区插件。RabbitMQ 客户端库是成熟且良好文档的。

Apache Kafka 在这一领域已经取得了长足进步,虽然他主要是Java客户端,有越来越多的社区目录 开放源码客户端生态系统项目,以及作为适配器 SDK 允许您建立自己的系统集成。大部分的配置已经设定好了,通过.properties 文件或编程方式。

第 10 段(可获 1.44 积分)

这两个软件很流行,对许多软件供应商都有很强的影响力,它们通过他们的技术,确保RabbitMQ 和Kafka正常工作。

安全性和易用性

安全性和易用性都是RabbitMQ的强项。 RabbitMQ管理插件提供了HTTP API,提供了用于管理和监控的浏览器的UI ,还提供了易用的CLI工具。 如果长期监测数据存储,使用CollectD, Datadog或者New Relic就很方便。 RabbitMQ还提供了API和监控工具,提供了审核和应用故障排除工具,提供了RBAC支持内置数据存储,支持TLS, 支持LDAP或外部供应商的HTTPS,支持代替用户名/密码对的使用x509证书的身份验证。就是还需要额外的身份验证方法,也可以使用插件相当直接地扩展。

第 11 段(可获 1.59 积分)

这些领域对Apache Kafka.构成了挑战。但在安全方面,最近的Kafka 0.9版本附加了TLS,JAAS基于角色的访问控制,Kerberos/plain/scram认证,并添加了CLI管理安全策略。这使得kafka的安全性大幅改善,早期版本只能在网络级别锁定访问权限,但对于共享或多用户不起作用。

Kafka管理CLI由shell脚本,属性文件,特别是格式化JSON文件组成。 Kafka 代理,生产者和消费者工作指标可以通过Yammer / JMX管理,但它但不维护任何历史,这意味需要使用第三方监测系统。使用这些工具,能够管理分区和主题,检查消费者偏移位置(消费状况),以及使用Apache Zookeeper为Kafka提供的HA和FT功能。例如,一个3节点Kafka集群即使两个节点失败也能提供服务。然而,如果你想让Zookeeper支持这么大数目的失败,需要额外的5个Zookeeper节点 ,Zookeeper是基于法定人数的系统,只能容忍 N/2+1的失败。这明显的不应该与Kafka节点共存 - 因此,要建立的3节点卡夫卡系统,您需要大约八台服务器。所以,当运营商推理任何卡夫卡系统的可用性时,必须考虑到ZK集群属性,无论资源消耗还是设计方面。

第 12 段(可获 2.93 积分)

性能

Kafka照以下设计:100k/sec性能往往是人们选择 Apache Kafka的关键驱动力。它的实现很大依赖开发者能够写出聪明的消费者代码。

当然,每秒消息速率是很难状态和量化,因为他们依赖很多,包括你的环境和硬件,工作负载的性质,使用哪种交货保证 (e.g. 持久性是昂贵的,镜像更是如此), etc.

20K/sec是很容易使用一个Rabbit队列实现的, 事实上跟多一些也不是很难,只要没有太多要求的担保。队列的支持,通过一个, 在本地操作系统线程池上进行协作调度的,轻量级的Erlang线程 - 因此,它自然成为了单队列的关键点或瓶颈,永远不会做比CPU周期内能得到的更多的工作。

第 13 段(可获 2.03 积分)

增加信息秒速率通常归结为妥善利用可用的并行性环境,通过诸如通过聪明的路由打破交通跨多个队列 (从而可以同时运行不同的队列)。当RabbitMQ实现一百万每秒的消息传递, 它通常会明智的慢下来 - 但通过使用大量的资源,周围 30 RabbitMQ节点。  大多数RabbitMQ使用者享受由三到七个RabbitMQ节点提供的高性能。

第 14 段(可获 1.08 积分)

Making the Call

市场上的其他高级选项的一些研究。如果你想深入与最流行的选择,查看 Nicolas Nannoni硕士论文 ,它独具特色的一面,比较表在4.4节 (page 39) 两年后仍然相当准确 - 值得一读。 

在研究时,尽可能形成涉众和业务的循环。理解商业用例是为你的情况做出正确的选择的最大的单因素 。  然后, 如果你是流行技术粉,你最好的办法就是睡在上面, 让它渗透,让你的本能接管。 你就明白了。

第 15 段(可获 1.54 积分)

文章评论

CY2
速度很快啊 ~
CY2
前面一两段翻译不怎么通顺
GreyWord
翻译的时候,我也觉得挺混乱的。但是反复考虑了几遍后,也没想到更通顺的翻译。
班纳睿
感觉标点符号的使用不够灵活可能也是导致不通顺的一个原因
GreyWord
我本以为就前两段不通顺,看了看评论,发现原来全文都不通顺。你看看,现在是不是好点了。
杭州访客
还以为是机器翻的
访客
确实有点,楼主能否消除这种感觉呢?
访客
这个翻译,差评。。。
兰州访客
我是搞RabbitMQ的,本想了解下与Kafka的不同使用场景。但我连介绍RabbitMQ的部分都读不下去了。
兄弟这翻译欠点火候啊。
如果对某个技术不了解,要么学习了解,要么别翻译。