纵观 Kafka 的发展脉络,它的确是从消息引擎起家的,但正如文章标题所问,Apache Kafka 真的只是消息引擎吗?通常,在回答这个问题之前很多文章可能就要这样展开了:那我们先来讨论下什么是消息引擎以及消息引擎能做什么事情。算了,我还是直给吧,就不从“唐尧虞舜”说起了。这个问题的答案是,Apache Kafka 是消息引擎系统,也是一个分布式流处理平台(Distributed Streaming Platform)。如果你通读全篇文字但只能记住一句话,我希望你记住的就是这句。再强调一遍,Kafka 是消息引擎系统,也是分布式流处理平台。
众所周知,Kafka 是 LinkedIn 公司内部孵化的项目。根据我和 Kafka 创始团队成员的交流以及查阅到的公开信息显示,LinkedIn 最开始有强烈的数据强实时处理方面的需求,其内部的诸多子系统要执行多种类型的数据处理与分析,主要包括业务系统和应用程序性能监控,以及用户行为数据处理等。
当时他们碰到的主要问题包括:
为了解决这些问题,LinkedIn 工程师尝试过使用 ActiveMQ 来解决这些问题,但效果并不理想。显然需要有一个“大一统”的系统来取代现有的工作方式,而这个系统就是 Kafka。
Kafka 自诞生伊始是以消息引擎系统的面目出现在大众视野中的。如果翻看 0.10.0.0 之前的官网说明,你会发现 Kafka 社区将其清晰地定位为一个分布式、分区化且带备份功能的提交日志(Commit Log)服务。
这里引出一个题外话,你可能好奇 Kafka 这个名字的由来,实际上 Kafka 作者之一 Jay Kreps 曾经谈及过命名的原因。
因为 Kafka 系统的写性能很强,所以找了个作家的名字来命名似乎是一个好主意。
大学期间我上了很多文学课,非常喜欢 Franz Kafka 这个作家,另外为开源软件起这个名字听上去很酷。
言归正传,Kafka 在设计之初就旨在提供三个方面的特性:
随着 Kafka 的不断完善,Jay 等大神们终于意识到将其开源惠及更多的人是一个非常棒的主意,因此在 2011 年 Kafka 正式进入到 Apache 基金会孵化并于次年 10 月顺利毕业成为 Apache 顶级项目。
开源之后的 Kafka 被越来越多的公司应用到它们企业内部的数据管道中,特别是在大数据工程领域,Kafka 在承接上下游、串联数据流管道方面发挥了重要的作用:所有的数据几乎都要从一个系统流入 Kafka 然后再流向下游的另一个系统中。这样的使用方式屡见不鲜以至于引发了 Kafka 社区的思考:与其我把数据从一个系统传递到下一个系统中做处理,我为何不自己实现一套流处理框架呢?基于这个考量,Kafka 社区于 0.10.0.0 版本正式推出了流处理组件 Kafka Streams,也正是从这个版本开始,Kafka 正式“变身”为分布式的流处理平台,而不仅仅是消息引擎系统了。今天 Apache Kafka 是和 Apache Storm、Apache Spark 和 Apache Flink 同等级的实时流处理平台。
诚然,目前国内对 Kafka 是流处理平台的认知还尚不普及,其核心的流处理组件 Kafka Streams 更是少有大厂在使用。但我们也欣喜地看到,随着在 Kafka 峰会上各路大神们的鼎力宣传,如今利用 Kafka 构建流处理平台的案例层出不穷,而了解并有意愿使用 Kafka Streams 的厂商也是越来越多,因此我个人对于 Kafka 流处理平台的前景也是非常乐观的。
说了这么多,我只想阐述这样的一个观点:Apache Kafka 从一个优秀的消息引擎系统起家,逐渐演变成现在分布式的流处理平台。你不仅要熟练掌握它作为消息引擎系统的非凡特性及使用技巧,最好还要多了解下其流处理组件的设计与案例应用。