您或许听说过 Apache Kafka。Kafka 为应用程序和数据管道传输数据和记录，由于它的容错能力，它可以充当企业消息系统。在本文中，我将深入剖析让 Apache Kafka 变得如此实用的原因，以及它如何为您的应用程序提供帮助。我还将介绍最适合应用 Kafka 的环境（并假设该环境适合您的应用程序架构）。然后，我将介绍您的架构的发展方向，以及发展道路上的阻碍！
您的大数据环境中包含以下内容
大量数据源
您拥有数据源。大量的数据源。这些数据源就是您的应用程序：从 支付处理系统 ，到 面向客户的网站 ，再到 社交媒体平台 ，等等。更别提所有提供行政职能、管理报告等特性的内部应用程序了。
这些应用程序生成了大量数据。它们也使用着大量数据。或者同时生成和使用大量数据。如果您的系统架构 看起来像在开始使用 Kafka 之前在 LinkedIn 上实现的架构 ，那么 Apache Kafka 可能很适合您。
数据压力（大数据的 3V
除了大量数据源之外，您还存在“大数据问题”：您企业中（许多不同种类）的数据源正以越来越快的速率生成数据，导致要处理的数据越来越多。
换句话说，数据迫使您想出一个解决方案（剧透一下：已经有一个解决方案）。
如果这还不够糟，那么更糟的是您企业中每个组织内的各个小组都拥有（并竭力保护）自己的应用程序和 数据孤岛 。
这自然导致了重复（由于缺乏集成而导致孤立）和过时的数据，以及不准确的指标。
用户压力
除了存在数据压力之外，内部和外部用户还想要更快的响应时间、（更）完整的数据视图、更实时的数据和（哦，还有！）准确的指标。
情况就是这样。
以下是您希望在大数据上发生的事情
相互理解的系统
您想要的是不仅能相互通信，还能相互理解的系统， 就像他们在 LinkedIn 上构建的系统一样 。
毕竟，相互理解的系统才是真正集成的系统。而无法相互理解的系统不是。
实时数据
您需要向应用程序提供实时数据。用户期望获得实时数据，管理人员也希望如此。
所以当应用程序中发生某个事件时，该事件（和配套数据）需要可供您企业中的其他每个应用程序用于可能的用途。
容易维护
由于您集成现有应用程序来理解彼此的数据，并添加新的应用程序，所以得到的代码需要易于维护。
您遇到的阻碍
大量 API
每个数据生产者都拥有自己的 API。确实如此。假设您将应用程序 B 与应用程序 A 集成（即 B 使用 A 的 API 来获取数据），而且一切正常。
现在假设您需要将应用程序 C 与 A 集成。您已集成过一次（与 B，还记得吧？），所以一些设计或代码可能可以重用（也可能无法重用），但无论如何，您完成了集成。非常棒！
然后，C 需要与 B 集成（假设 B 有一个针对此用途的很棒的 API，也可能没有）。呼！现在还有应用程序 D、E 和 F 需要与所有这些应用程序集成。这可能很快 变成一场集成噩梦 。
使用者有时需要成为生成者
一些内部应用程序存在的意义仅在于，使用来自某个数据源的数据、转换它，并将它写入另一个应用程序。
这没什么问题，但它是您的架构中的另一个集成点。
或许您认为可以使用一个 ETL 解决方案完美解决这个问题，但该解决方案是一个批处理解决方案。
实时数据是一个复杂问题
您需要实时数据。而且要实现这种水平可扩展性，您需要将实时数据变成实际可用的数据，将所有这些数据源解耦（您的计划是使用最佳实践）。
因此，或许您想使用 ActiveMQ 这样的传统消息代理来实现解耦和水平可扩展性。问题在于，传统消息代理并不总是能够扩展。
Kafka 如何为您的大数据环境提供帮助
Kafka 是一个基于流的发布/订阅系统，它可以实时创建一个按时间排序的日志记录序列。
等等，这是什么意思？听我细细道来。
基于流
将一个流看作一个事件序列，该序列导致数据库中的应用程序的状态发生改变。数据库（作为应用程序的记录系统）始终包含当前状态，而不是包含导致该状态的事件。
这些（导致更改的）事件 就像一个故事 。您的应用程序的故事。
“大数据”的一个主要优势是，能捕获这些事件，以便对它们进行分析。通过这些事件讲述的故事，您能了解您的应用程序的执行情况，并为管理人员的决策提供素材。
发布/订阅
Kafka 运用了一种发布/订阅架构。数据生成者将记录发布到一个主题。订阅该主题的使用者会收到最新的记录并执行相应处理（这可能涉及到某种转换，然后发布到另一个 Kafka 主题）。
使用这样的发布/订阅模式会得到一种高度解耦的架构。而且得益于 Kafka 超快的只能追加的分区日志，它提供了 令人难以置信的水平可扩展性 。
按时间排序的日志记录序列
当我在 Kafka 上下文中谈到“日志”时，我并不是指“存储日志消息的文件”。而是指应用程序日志。
在 Kafka 的上下文中，日志是 只能追加的按时间排序的记录系统 。
日志包含您的应用程序输出的事件流：您的应用程序中发生的事情（事件），您向 Kafka 告知该事件（发布），其他相关各方（订阅者，比如您的应用程序）可以执行相应操作。
这提供了大量优势：
- 让系统作为一个整体具有更高的容错能力
- 提供了重放事件序列（撤销、恢复到最后已知正常状态等）的能力
- 日志可以（潜在地）存储所有信息（当然，实际上并不会这么做）
后续计划
欢迎发表评论！期待听到您对 Kafka 的看法。
本文翻译自 Apache Kafka: Change the way you think about big data and enterprise messaging （2017-10-31）
注：本文内容来自互联网，旨在为开发者提供分享、交流的平台。如有涉及文章版权等事宜，请你联系站长进行处理。