通常，企业服务总线（ESB）或其他集成解决方案（如提取-转换-加载（ETL）工具）已用于尝试使系统脱钩。 但是，大量的连接器以及应用程序同时发布和订阅数据的要求，意味着系统始终是纠缠在一起的。 结果，开发项目对其他系统有很多依赖性，并且没有什么可以真正解耦的。

这篇博客文章显示了为什么这么多企业利用ApacheKafka®生态系统成功地集成了不同的遗留和现代应用程序，以及这种差异如何，同时也补充了现有的集成解决方案，例如ESB或ETL工具。

集成的需要-一个永无止境的故事

无论您在哪个企业工作，无论公司何时成立，都需要将应用程序彼此集成以实现业务流程。

这包括许多不同的因素：

· 技术（SOAP，REST，JMS，MQTT等标准，JSON，XML，Apache Avro或协议缓冲区之类的数据格式，Nginx或Kubernetes等开放框架以及EDIFACT或SAP BAPI等专有接口）

· 编程语言和平台，例如Cobol，Java，.NET，Go或Python

· 诸如Monolith，客户端服务器，面向服务的架构（SOA），微服务或无服务器的应用程序架构

· 通讯模式，例如批处理，（近）实时，请求-响应，即发即忘，发布订阅，连续查询和倒带。 有关更多信息，Mulesoft在线培训

许多企业体系结构有些混乱-如下所示：

...

每个公司都需要解决这些意大利面条体系结构。 根据十年的经验，您要么购买了诸如ETL工具来构建批处理管道，要么购买了ESB来设计SOA。 一些产品也更改了名称。 今天，为您提供了诸如中间件消息传递，集成平台，微服务网关或API管理之类的功能。 品牌和产品名称无关紧要。 您始终会看到同一张图片作为从意大利面体系结构移动到中间的中央整体框的解决方案，如下所示：

...

不幸的是，这在实践中很少能很好地起作用。 在过去的二十年中，大多数SOA项目都失败了。 企业现在不再使用ETL工具或ESB，而是转向流媒体平台来解决此问题。 这是市场上的下一个泡沫吗？ 只是一个新名词？ 或者，是否发生了真正的变化以允许在整个企业中成功集成？是将旧的大型机，CRM和ERP等标准应用程序集成，使用任何编程平台构建的现代微服务，还是公共云服务？ 为什么现在公司迁移到Apache Kafka来构建此流平台？ 为什么每个人都会在会议，技术讲座和博客文章中对此感到高兴？ 它与ESB或ETL工具相比如何？

下一节将回答所有这些问题，并解释Apache Kafka生态系统与其他现有集成解决方案之间的原因和差异。

事件驱动的处理和流式传输是企业体系结构中的关键概念

事件流平台（您也可以在此处输入另一个流行词）将事件作为核心原则。 您可以考虑事件的数据流，并在运动时处理数据。

许多概念（例如事件源）或设计模式（例如企业集成模式（EIP））都基于事件驱动的体系结构。 以下是流媒体平台的一些特征：

· 基于事件的数据流是（近）实时和批处理的基础。 过去，所有内容都创建在数据存储（静态数据）上，因此无法构建灵活，敏捷的服务以在数据相关时对数据进行操作。

· 可扩展的中枢神经系统，可处理任意数量的源和汇之间的事件。 中央不是在中间意味着一个或两个大盒子，而是一个可扩展的分布式基础结构，该基础结构是设计用于零停机时间，处理节点和网络的故障以及滚动升级。 可以以灵活，动态的方式部署和管理不同版本的基础架构（例如Kafka）和应用程序（业务服务）。

· 任何类型的应用程序和系统的可集成性。 技术无所谓。 连接任何东西：编程语言，REST之类的API，开放标准，专有工具和旧版应用程序。 速度无所谓。 阅读一次。 阅读几次。 从头开始重新阅读（例如，添加新应用程序，使用相同数据训练不同的机器学习模型）。

· 用于解耦应用程序的分布式存储。 不要尝试使用您喜欢的传统消息传递系统和内存缓存/数据网格来构建自己的流媒体平台。 这背后有很多复杂性，流平台只是内置了它。 例如，这允许您存储微服务的状态，而不需要单独的数据库。

· 无状态服务和有状态业务流程。 业务流程通常是有状态流程。 它们通常需要通过事件和状态更改来实现，而不是通过远程过程调用和请求-响应方式来实现。 事件源和CQRS等模式有助于在事件驱动的流体系结构中实现此目标。

流架构在企业架构中的优势

流平台为您的企业体系结构带来了巨大的好处：

· 关于节点，数量，吞吐量的大而灵活的可伸缩性-全部在商品硬件上，在任何公共云环境中或通过混合部署实现。

· 体系结构的灵活性。 创建小型服务，大型服务，有时甚至还不算什么。

· 事件驱动的微服务。 异步连接的微服务为复杂的业务流建模，并将数据移动到需要的地方。

· 开放性，无需承诺独特的技术或数据格式。 肯定会出现下一个新的标准，协议，编程语言或框架。 即使某些源或接收器使用专有数据格式或技术，中央流媒体平台也是开放的。

· 作为产品进行管理的独立和分离的业务服务，具有自己的有关开发，测试，部署和监视的生命周期。 松耦合允许在不同的生产者和消费者之间，在线/离线模式和处理背压之间进行独立的处理速度。

· 多租户以确保只有合适的用户才能在单个集群中创建，写入和读取不同的数据流。

· 使用容器，devops等进行工业化部署，无论是在内部，在公共云中还是在混合环境中，都可以根据需要进行部署。 从M子培训中了解更多信息

这些特性为流媒体平台奠定了基础，是成功进行数字化转型的开始。 通过服务实现一组有限的功能，以及独立开发，部署和扩展服务，您可以缩短获得结果的时间并提高灵活性。 只有具有上述特征的流媒体平台才有可能做到这一点。

流平台的用例

以下是一些通用方案，说明如何利用具有上述特征的流媒体平台：

· 事件驱动的大数据集处理（例如日志，物联网传感器，社交订阅源）

· 关键任务实时应用程序（例如付款，欺诈检测，客户体验）

· 不同的旧版应用程序与现代应用程序之间的去耦集成

· 微服务架构

· 分析（例如，用于数据科学，机器学习）

不同应用程序的生产者和消费者之间确实是分离的。 他们根据自己的速度和要求进行独立扩展。 您可以随着时间的推移在生产者和消费者方面添加新的应用程序。 通常，一个事件需要由许多独立的应用程序使用以完成业务流程。 例如，酒店客房预订需要实时实时进行付款欺诈检测，能够近乎实时地通过所有后端系统处理预订的能力以及通宵整批分析以改善客户360度，售后，酒店物流和其他业务流程。

尽管某些流程需要实时处理，但您还需要能够支持批处理流程。 您甚至需要比开始时更频繁地重新消耗数据，例如，在应用程序关闭一段时间后，使用不同版本的应用程序进行A / B测试，添加需要消耗的新应用程序 从头开始创建数据，或者通过基于相同数据集的机器学习构建不同的分析模型。

考虑一下您可以使用真正的分离系统轻松构建的更多用例，该系统仍然是一个集成良好且可扩展的流平台：

· 在客户离开商店之前进行销售

· 在欺诈发生之前终止交易

· 在生产机器损坏之前更换它的一部分

· 告知客户航班或火车晚点了（发送更新，重新预订或优惠券）

· 您命名-清单继续。

从批次到实时的大爆炸？

现在，您了解了真正的分离，可扩展的流媒体平台的附加价值。 因此，我是否必须将此作为我们所有应用程序的中央数据平台引入？

警告！ 没有成熟的企业可以成功实现大爆炸。 遗留应用程序无处不在。 从预流媒体逐步过渡到流媒体平台。 如果您来自大型机时代，那么您甚至可能永远拥有批处理和非流式处理应用程序（或者至少在接下来的20-30年实际上是这样）。 没关系。 您只需要将这些系统中的事件带入事件驱动的中枢神经系统。

下面显示了我们用来识别大型企业的现状和计划的流式成熟度模型：

...

你今天在哪里？

· 预先串流（批次或旧版）

· 兴趣（概念或飞行员的第一证明）

· 早期生产（一些正在生产中的独立项目）

· 集成流媒体（具有生产中不同项目的流媒体平台）

· 事件流平台（具有主要基于事件的应用程序的流企业）

大多数传统企业都在预流阶段开始他们的旅程。 很好 下一部分将说明为什么几乎所有成功转换为流媒体平台都将Apache Kafka生态系统用作关键架构组件的原因。

将Apache Kafka生态系统引入流媒体平台

通常，人们对Apache Kafka都很熟悉，因为Apache Kafka是一个非常成功的开源项目，由LinkedIn创建，用于大数据日志分析。 那是Kafka的开始，只是今天许多用例之一。 对于先前讨论的所有用例，Kafka从数据摄取层演变为实时流平台。 许多项目专注于围绕Kafka构建关键任务应用程序。 它必须启动并且性能为24/7。 如果Kafka宕机，其业务流程将停止工作。

Kafka之所以与众不同，是因为它将消息，事件的存储和处理都集中在一个平台上。 它在分布式架构中使用分布式提交日志和将主题划分为多个分区的方法来执行此操作，如下所示：

...

通过这种分布式体系结构，Kafka与现有的集成和消息传递解决方案有所不同。 它不仅可以大规模扩展并为高吞吐量构建，而且不同的使用者也可以彼此独立地以不同的速度读取数据。

应用程序将数据发布为事件流，而其他应用程序则选择该流并在需要时使用它。 由于所有事件都已存储，因此应用程序可以挂接到该流中，并按要求进行消费-批量，实时或近实时。 这意味着您可以真正解耦系统并实现适当的敏捷开发。 此外，在适当停用现有系统之前，新系统可以订阅该流并追上历史数据直到当前。

在一个分布式，可扩展，容错，高容量，技术独立的流媒体平台中进行消息传递，存储和处理的独特性，是Apache Kafka在全球几乎所有大型公司中获得全球成功的原因。

那么，Apache Kafka和周围的生态系统是什么？ 让我们从高层次看一下：

· Apache Kafka作为分布式消息传递和存储的核心。 高吞吐量，低延迟，高可用性，安全。

· Kafka Connect是一个集成框架，用于将外部源/目的地连接到Kafka。

· Kafka Streams是一个简单的库，可在Kafka框架内进行流应用程序开发。

· 非Java编程语言的其他客户端，包括C，C ++，Python，.NET，Go和其他几种。

· Confluent REST Proxy通过HTTP（S）从任何网络连接的设备提供对Kafka的通用访问。

· Confluent Schema Registry作为Kafka数据格式的中央注册表，可确保所有数据始终是可消耗的，包括模式演变。

· 融合的KSQL作为流式SQL引擎，可在不编写源代码的情况下针对Apache Kafka进行本机可扩展的高容量流处理。

所有这些组件都基于Apache Kafka的核心消息传递和存储层，并且都利用了其高可伸缩性，高容量/吞吐量和故障转移的功能。 此外，Confluent还提供24/7支持和企业工具，以进行端到端监控，Kafka集群管理，多数据中心复制等。

好的，所以我们应该开始在概念验证（POC）中评估Kafka吗？

POC？ 好吧，Apache Kafka生态系统已经经过了实战测试，其规模可能在未来5-10年内无法达到。 许多着名的组织都是Kafka用户：

· LinkedIn在2018年每天处理超过4.5万亿条消息。

· Netflix在2018年每天处理超过6 PB的数据。

· Ebay，Uber，Paypal，请给它命名。 只需Google（您最喜欢的科技巨头+ Apache Kafka）即可了解他们如何使用Kafka。 到处都是！

· 甚至银行，保险，电信，零售，汽车和制造业中的"传统"公司也使用Kafka来改变和革新其核心业务。 在网上可以找到包括ING Group（银行），Audi（汽车）和Target（零售）的公共参考。

不要将时间浪费在POC上，涉及性能，成熟度或可扩展性。 相反，请评估如何将Kafka集成到您的企业体系结构中，以发展业务场景并朝着数字化转型创新。

是否应该替换现有的MQ和ESB部署？

像Netflix，LinkedIn和Zalando这样的年轻公司在Kafka上创建了整个基础架构。 较老的公司并不是那么幸运，因为它们拥有大量的大型机，整体设备和传统技术。 但是，正如所讨论的那样，大爆炸式替换并不是成功的正确方法。 这很像改造您的房屋。 尽管从理论上讲从头开始重建它可能很有意义，但通常扩展房屋，更换某些房间或重新装修更为实用。

仅仅撕掉和替换与其他可以正常工作并需要熟练的团队操作的应用程序紧密集成的任务关键型应用程序是很困难的。 话虽如此，有时更换旧建筑可能更具成本效益，就像有时从头开始重新装修房屋确实有意义。 俄罗斯最大的银行Sberbank就是这种情况，该银行围绕卡夫卡创建了完整的核心银行系统，作为中枢神经系统。

Apache Kafka和其他中间件作为补充组件

传统应用通常基于诸如EDIFACT之类的复杂数据格式，使用诸如CORBA之类的复杂接口，或者使用诸如Cobol之类的难以维护且不灵活的编程语言来构建。 您不能简单地将其关闭或切下并更换它。 这必须逐步完成。 传统和现代应用程序共存，可以运行现有业务并添加新产品以增强业务。

通过流式平台（即Apache Kafka生态系统）集成旧系统进行创新。 使用诸如变更数据捕获（CDC）和集成工具（如ESB或ETL）之类的概念，并为传统应用程序提供出色的图形工具和连接器。 有了这个基础，您就可以围绕Apache Kafka原生地使用现代技术，大数据系统，机器学习等来构建新的应用程序，同时可以访问您的遗留事件，您仍然需要在新项目中增加附加值 。

真正的去耦合技术独立性还意味着您拥有笨拙的管道和智能端点。 如果将所有集成逻辑（或更糟糕的是，一些业务逻辑）构建到中央集成层中，那么不同系统的所有可伸缩性，敏捷性和独立性都将消失。 这是与传统集成解决方案的主要区别，在传统集成解决方案中，您将所有逻辑都放在了中间层ESB中。 它创建了对此（专有）技术/ API的依赖以及灵活性。

智能端点可以是任何东西。 您可以利用Kafka生态系统，利用Kafka Streams，KSQL或任何Kafka客户端（例如Java，.Net，Python或Go）围绕Kafka构建应用程序。 您还可以使用任何其他应用程序将其他应用程序与Kafka集成。 长期成功的秘诀是基础架构对任何技术和架构模式都是开放的。

ETL和ESB具有出色的工具，包括用于与SOAP，EDIFACT，SAP BAPI，COBOL等进行复杂集成的图形映射。 集成。 因此，已经与您的旧世界集成的现有MQ和ESB解决方案与Apache Kafka相比没有竞争力。 相反，它们是互补的！ 像过去一样利用它们与旧世界融合。 您可以使用以下内容：

· 适用于IBM MQ和其他JMS代理的融合JMS连接器

· Kafka Connect CDC连接器，用于大型机和数据库

· 与旧协议（SOAP，EDIFACT等）和应用程序（SAP，Siebel等）集成的ESB或ETL工具。 所有这些工具同时也具有Kafka连接器。

· 同时，传统的消息经纪人也可以代理Kafka。 即使前段时间他们告诉大家您不能构建通用的消息传递平台，但传统的消息传递代理现在已集成到Kafka和MQTT等其他标准，不会被遗忘

· 如果没有其他可行的集成选项可用，则Kafka的官方低级客户端API（如Java，.NET，Go和Python）将实现直接集成。

最后，在解释了Kafka世界中ESB和ETL工具的用法之后，我引用ThoughtWorks来提醒您不要尝试围绕Kafka构建新的ESB：

一些组织通过集中化Kafka生态系统组件（例如连接器和流处理器），而不是让这些组件与产品或服务团队一起使用，来使用Kafka重新创建ESB反模式。 这使我们想起了严重问题的ESB反模式，其中越来越多的逻辑，业务流程和转换被引入到一个集中管理的ESB中，从而严重依赖集中团队。 我们称其为阻止这种有缺陷的模式的进一步实现。

Apache Kafka及其生态系统被设计为具有内置许多智能功能的分布式体系结构，以实现高吞吐量，高可伸缩性，容错和故障转移！ 让产品或服务团队使用Kafka Streams，KSQL和任何其他Kafka客户端API来构建其应用程序。 如果您需要Kafka与ESB和ETL工具的功能进行特定的旧式集成，请将它们集成。 与其他任何Kafka生产者或使用者API一样，ESB或ETL流程可以成为Apache Kafka的源或接收者。 通常，使用这种工具与旧系统的集成通常已经创建并正在运行。 当前，所有这些工具也都具有Kafka连接器，因为市场以这种方式驱动它们。 因此，您只需要将现有集成与Kafka连接器结合起来，就可以了：通过Kafka在旧生态系统和未来生态系统之间进行灵活，可扩展且高度可用的集成。

Apache Kafka作为遗产与新现代世界之间的流媒体平台

Apache Kafka是一个开放源代码流平台，可让您构建可扩展的分布式基础结构，以灵活，分离的方式集成旧版和现代应用程序。 它已经为每天处理数万亿条消息和PB级数据进行了测试。 只需在企业体系结构中利用Apache Kafka生态系统，即可成功，动态地集成各种系统。 但是，无论您做什么，都不要尝试围绕Kafka构建ESB，因为这是一种反模式，会产生僵化和不必要的依赖关系。 相反，可以利用Apache Kafka生态系统的分布式体系结构构建具有高吞吐量，高可伸缩性，容错和故障转移的，事件驱动的灵活流式基础结构。

下一步，请查看我关于Apache Kafka与集成中间件的演讲，以了解如何利用Apache Kafka及其开源生态系统构建完整的事件流平台。 在本节中，我还将介绍它与MQ，ETL和ESB等中间件的区别。 为了获得进一步的证明，您可以查看过去在伦敦，纽约和旧金山举行的Kafka峰会，许多技术巨头和软件供应商在会议上解释了如何使用Apache Kafka进行业务数字化和产品创新。

要获得深入的知识，请在Mulesoft Training上注册免费的现场演示

(本文翻译自SivaCynixit的文章《Apache Kafka vs. Enterprise Service Bus (ESB)》，参考：https://medium.com/@sivacynixit/apache-kafka-vs-enterprise-service-bus-esb-8d2978c00560)