vlambda博客
学习文章列表

企业面临着前所未有的集成挑战。信息技术的发展要求更多的技术集成，应用程序部署在边缘、混合和多云架构中，传统的中间件，如 MQ、ETL、ESB，都不能很好地扩展，仅能批量处理数据而无法实现实时处理。

本文将探究为何 Apache Kafka 会成为集成项目的新贵、怎样将其纳入到围绕云原生 iPaaS 的解决方案中，以及为什么说事件流是一种新的软件类别。

iPaaS（Enterprise Integration Platform as a Service，企业集成平台即服务）是 Gartner 创造的一个术语。以下是 Gartner 的官方定义：“集成平台即服务（iPaaS）是一套支持集成流开发、执行和治理的云服务，连接个人或跨多个组织内基于企业内部和云端的流程、服务、应用和数据的任何组合。” 在一些报告中，首字母缩写 eiPaaS（企业集成平台即服务）被用作 iPaaS 的替代。

Gartner 的 iPaaS 魔力象限显示了各种供应商：

上图中，有三点让我印象深刻：

• 许多不同的供应商提供了广泛的集成解决方案。

• 许多供应商为提供 iPaaS 发布了各种各样的产品，这意味着其中包含了各种不同的技术、代码库、支持团队等。

• 魔力象限中没有一个 Kafka 的产品（如 Confluent、Cloudera、Amazon MSK）。

那么，基于 Kafka 的解决方案能否被看作是 iPaaS？

这取决于“iPaaS”的定义。Kafka 解决方案符合 iPaaS 的要求，但这仅仅是事件流处理的一部分。Kafka 是一个事件流处理平台，用例不同于传统的中间件。如果你对这些用例一无所知，那么可以在现实中了解一下 Kafka 的跨行业部署。

Kafka 并不直接与 Talend 或 Informatica 等 ETL 工具、IBM MQ/RabbitMQ 等 MQ 框架、MuleSoft 等 API 管理平台，以及 Boomi/TIBCO 等基于云的 iPaaS 竞争。如果人们足够了解 Kafka 与传统中间件间的区别，就不会认为他们是一样的产品。

那么，各种不同的供应商都在 iPaaS 魔力象限中，Kafka 供应商是不是也应该被纳入其中？我的答案是肯定的，因为我见过数以百计的用户，常常在混合和多云架构中将 Kafka 生态系统用做云原生的、可扩展的、事件驱动的集成平台。这不就是一个 iPaaS 吗？

如果你是新手，可以看看《Apache Kafka vs. MQ、ETL、ESB》这篇文章或者与之有关的幻灯片和视频。为什么说 Kafka 是集成场景里独一无二的选择？我的结论是：事件流的独特卖点就是能够利用单一平台，而其他 iPaaS 解决方案需要不同的产品（包括代码库、支持团队、附加技术之间的集成等）。

现代 iPaaS 解决方案与传统中间件，在软件架构、平台可扩展性和操作性以及数据处理能力等方面有着本质的不同。从更高的层面来看，“Kafka iPaaS”必须具有如下特性：

• 云原生基础设施。弹性对于现代 IT 企业的成功至关重要。企业必须有能力扩展或缩减 Kafka 集群，这种能力可以从一个小的试点项目起步，逐步扩大规模或能够处理负载高峰（如零售业的圣诞节业务）。

• 自动化操作。如果软件在公有云中运行，那么真正的无服务器 SaaS 将永远是首选方案。像 Kubernetes 这样的编排工具和相关工具（如 Kubernetes 的 Kafka 运营商），是自我管理数据中心或边缘数据中心的下一个最佳选择。

• 完整的平台。一个集成平台需要实时的消息传递和存储，以实现背压处理和长期运行。数据集成和连续地数据处理也是必需的。因此，“Kafka iPaaS”只有企业在能获得各种预建的 Kafka 原生连接器到开放标准、传统系统和现代 SaaS 接口时才有机会成为可能。否则，Kafka 就需要与另外的中间件如 Apache Nifi 结合。

• 单一的解决方案。这听起来微不足道，但是大部分中间件的解决办法都是利用代码库和产品，无论是 IBM、Oracle 这样的传统公司，还是开放源码驱动的 Cloudera 都是如此。复杂的软件栈使其难以实现端到端的集成、24*7 的运营，以及对关键任务的支持。当然，Kafka 原生解决方案，比如 Confluent Cloud，也包含了其他的产品，并且收取额外的费用（例如，完全管理的连接器或者数据治理附加组件），但它们都在单一的 Kafka 原生平台上运行。

从这个角度来看，有些 Kafka 解决方案是现代的、云原生的、可扩展的 iPaaS，但这并不意味着所有的 Kafka 解决方案就是 iPaaS。

尽管有些 Kafka 解决方案可以被用作 iPaaS，但是这仅仅是事件流众多使用场景中的其中之一。正如上面提到的，基于 Kafka 的解决方案与 Gartner 魔力象限中的其他 iPaaS 解决方案有很大不同。因此，事件流值得作为专属的软件类别。

如果你还不能理解，可以就去看看各个行业的事件流用例，了解 Kafka 和传统的 iPaaS、MQ、ETL、ESB、API 工具之间的区别。下图虽然时间有点久但依然概括了大量的事件流用例：

许多创新业务应用都是用 Kafka 构建的，它不仅仅是一个集成平台，还拥有一系列独特的规模化、实时处理端到端数据的能力。

像数据网格这样的新概念也证实了这种演变。领域驱动的设计、微服务、真正的服务解耦，但是现在更多的是把数据当作一种产品。后者意味着，它正在从一个成本中心转变成一个利润为中心和创新的新服务。在数据网格驱动的企业架构中，事件流是重要的组成部分，因为在不同的用例中，实时数据总是战胜慢速数据。

遗憾的是，现在并没有针对事件流的 Gartner 魔力象限或 Forrester Wave，尽管有些事件流的解决方案符合这些报告的要求（如 Gartner iPaaS 魔力象限或 Forrester Wave 用于流分析）。

（译者注：IT 领域有两大知名度和权威性都较高的独立市场调研和咨询机构，一家是 Gartner，另一家是 Forrester。Gartner 因其魔力象限而著称，而 Forrester 有一个 Forrester Wave™，两者都是对 IT 厂商在某个技术领域的综合能力评估模型。）

很多软件供应商都是以事件流处理为基础，业务得到了整体发展。Confluent 是这个领域的领军企业——虽然我作为 Confluent 的员工对公司有些意见，但这一点毋庸置疑。围绕 Kafka 诞生了很多公司，有的公司用其他方式使用 Kafka 协议，有的公司研发出了像 Amazon Kinesis、Apache Pulsar 等具有竞争力的事件流产品。

下面的事件流全景图 2021（Event Streaming Landscape 2021）总结了目前的状况：

我希望能尽快地看到用于事件流的 Gartner 魔力象限和 Forrester Wave。

你也许注意到了我说的：一些事件流解决方案可被视为 iPaaS，其中的关键词就是“一些”。仅仅提供一个开源的框架还远远不够。

iPaaS 需要一个完整的产品，最好是完全管理的服务。许多事件流供应商使用 Kafka、Pulsar 或者其他框架，但是并没有提供完整的运营工具、24*7 小时的业务支持、用户界面等等。以下资源可以帮助你了解 2021 年的事件流全景。

• 为何 Kafka 成为像 Amazon S3 一样的标准 API？

  （https://www.kai-waehner.de/blog/2021/05/09/kafka-api-de-facto-standard-event-streaming-like-amazon-s3-object-storage/）

• 事件流和 Kafka 供应商的比较

  （https://www.kai-waehner.de/blog/2021/04/20/comparison-open-source-apache-kafka-vs-confluent-cloudera-red-hat-amazon-msk-cloud/）

• Apache Kafka 与 Apache Pulsar 的比较

  （https://www.kai-waehner.de/blog/2020/06/09/apache-kafka-versus-apache-pulsar-event-streaming-comparison-features-myths-explored/）

一定要对市面上的各种产品进行评估。许多功能都是为了推广！许多“完全管理的服务”只是部分管理，服务水平协议和支持也十分有限。有些产品看似具备许多非常炫酷的特性，但它们更像是 alpha 版并被过分吹嘘，而非成熟的服务解决方案。

一个反例是 T-Mobile 关于升级 Amazon MSK 中提到的复杂性，这说明了“推广和销售完全管理的服务”和“完全没有完全管理的现实”之间的区别。一个真正完全管理的产品并不需要终端用户升级基础设施。

下面我们来看看一个真实的案例，来了解为何传统 iPaaS 无法在需要使用事件流的情况下提供帮助，并且为何要在单一技术的功能组合中设置一个新的软件类别。

这个例子听上去很简单：通过网站、智能手机和车站的显示屏幕，为旅客提供实时信息和通知，从而提高旅客的出行体验。因为在德国复杂的铁路网络中，车次延误和取消情况时有发生。经常旅行的人都被迫接受，毕竟人们对恶劣天气、技术缺陷等问题无能为力。但是，旅客至少希望得到实时信息和通知，这样他们可以在咖啡馆或休息室里等待，而不必在月台上冻几分钟甚至几个小时。

实际上，德国铁路公司在通知旅客时的顺序是不同的。有的旅客被通知延误 10 分钟，有的 20 分钟，有的 30 分钟，甚至有的是车次被取消。

Reisendeninformation（即旅客信息系统）项目的目标是提高德国数以百万计旅客每天的旅行体验，使其在任何地方都能获得最新、准确、一致的旅行信息。

这听起来也很简单，列车晚点或者取消的话就给旅客发送实时的通知。每一个“黑魔法”iPaaS 盒子都能做到这一点：

德国铁路公司已经开始利用开源的消息平台来发送实时通知。但该团队很快发现，并非所有的信息都是实时发送的。所以，他们在项目中增加了缓存和存储系统，来应付从某些遗留的批处理或基于文件的系统发出的延误信息。

现在该团队需要对遗留系统中的数据进行集成，所以安装了一个集成框架来连接文件、数据库和其他应用程序，这也要求团队能将来自不同系统的实时和非实时数据联系起来对数据进行处理。流处理引擎可以做到这一点。

该试点项目由若干个不同的框架组成。于是，人们开始质疑：

• 如何扩展这些非常不同的技术组合？

• 如何在各种平台上获得端到端的支持？

• 这是否具有成本效益？

• 新特性的发布时间是哪天？

德国铁路公司对其技术栈进行了重新评估，发现 Apache Kafka 提供了所有需要的、开箱即用的功能。

德国铁路公司的团队重新构建了他们的试点项目。新的解决方案利用 Kafka 作为各种系统、技术和通信范式之间的单点链接。

传统的 iPaaS 可以实现这种场景，但除了选择软件厂商，还要有代码库、技术和集群。有些 iPaaS 在刚开始的时候可能表现不错，但随着业务的扩张，各种麻烦就会相继出现。只有事件流能让企业从小处起步，在扩展规模的时候也无需对基础设施进行重新架构。

目前，该项目已经投入生产。用户可以查看手机上的 DB Navigator 移动应用来获得德国所有列车的实时更新消息。生活在德国，我非常感谢这项新的服务。

德国铁路公司的团队在不同的会议上发表过几次公开演讲，并在 Confluent 博客上谈到了关于他们的 Kafka 之旅。不过，这个旅程并没有就此结束。德国铁路公司现在正在评估从公有云中自我管理的 Confluent 平台部署迁移到完全管理的、真正无服务器的 Confluent 云产品。

上述项目只有在一个完整的平台上才能实现。很多人依然把 Kafka 看作是数据湖或数据仓库的摄入层，因为这是 Kafka 最早的突出用例之一。今天，数据摄取依然是一个很好的用例，但许多项目已经不仅仅使用 Kafka 的核心部分来实现这一点。Kafka Connect 提供了 Kafka 和数据存储之间开箱即用的连接。

开发者在公有云中甚至能够以完全管理、无服务器的方式进行集成，无论是否需要与第一方云服务（如 Amazon S3、Google Cloud BigQuery、Azure Cosmos DB）或其他第三方 SaaS（如 MongoDB Atlas、Snowflake 或 Databricks）集成。

连续的 Kafka 原生流处理是完整平台的下一个层次。例如，德国铁路公司经常利用 Kafka 流进行大规模的实时数据关联处理，其他公司使用 ksqlDB 作为 Confluent Cloud 中的一个完全管理的特性，好处就是不需要另一个平台或服务来进行流分析。一个完整的平台使架构更具成本效益，而且从 SLA 和支持角度来看，端到端的集成更容易。

一个完整的平台需要更多的“顶层”服务，如数据流的可视化、数据治理、基于角色的访问控制、审计日志、自助服务能力、用户界面、可视化编码 / 代码生成工具等。目前，与事件流产品相比，可视化编程成为传统中间件和 iPaaS 工具的优势。

然而，事件流并不是解决所有问题的银弹！在探讨 Kafka 和 MQ/ETL/ESB 是朋友、敌人还是亦敌亦友的时候，我已经指出了这一点。例如，MQ 或 ESB 可以作为集成项目中的事件流的补充，这取决于项目需求。

我们再来看看德国铁路公司。如前所述，他们的旅客信息平台是实时的。最近，德国铁路公司宣布与谷歌合作，与谷歌地图进行第三方集成。谷歌地图用户可以获得实时列车时刻表的更新信息：

集成后，企业可以接触到新的人群并扩大业务。用户可以通过谷歌地图页面来购买车票。我不清楚这个第三方集成使用了什么技术或产品。德国铁路公司实时基础设施的核心在于实现新的创新业务模式和与合作伙伴的合作。

德国铁路与谷歌地图的集成，很有可能不是直接采用 Kafka 协议（虽然有时候也会这么做，比如 Here Technologies 为其地图服务所提供的开放 API）。

事件流是对其他服务的补充。有的项目团队使用了一个 API 管理平台来向外部消费者提供内部 API，包括访问控制、计费和报告。《Apache Kafka 和 API 管理 /API 网关——朋友、敌人还是亦敌亦友？》（Apache Kafka and API Management / API Gateway – Friends, Enemies or Frenemies?）这篇文章探讨了事件流和 API 管理之间的关系。

实时数据在任何地方都胜过缓慢的数据。这是一种新的软件类别，因为我们不只是通过消息传递系统将事件发送到另一个数据库。相反，我们实时使用和关联来自不同数据源的数据。这就是创新项目的真正价值，能够改变游戏规则。

因此，事件流必须在每个地方都能实现。虽然对很多 IT 项目来说云优先是一种可行策略，但是在非常重要的边缘和混合场景中，事件流。

假如在上述德国铁路公司有关的项目（但纯属虚构）中有一种混合架构，包含实时应用程序、云和列车中的边缘计算：

我在其他文章中也谈到了这一点，包括《Apache Kafka 跨行业的边缘用例》（Edge Use Cases for Apache Kafka Across Industries）。这篇文章的总结如下：利用事件流的开放架构要能在各地进行实时数据处理，包括多云、数据中心和边缘部署（即在数据中心之外）。企业架构不需要各种技术和产品来实现实时数据处理，再与独立的 iPaaS、ETL 工具、ESB、MQ 系统集成。

不过要再次强调一点，了解事件流如何融入企业架构是至关重要的。例如，Kafka 经常与物联网技术相结合，如 MQTT，在这些边缘场景中其与物联网设备进行“最后一英里”的集成。

Kafka 凭借其独特的功能组合已在各行业的集成项目中脱颖而出。有些 Kafka 解决方案属于 iPaaS 范畴，与其他集成平台一样也有取舍之处。但事件流是软件类别，因此 iPaaS 只是 Kafka 或其他类似事件流平台的一种用法。

你是如何利用事件流和 Kafka 作为集成平台的？欢迎大家在评论区讨论。

原文链接：

https://dzone.com/articles/apache-kafka-as-cloud-native-ipaas-integration-mid