在与客户的交谈中，几乎每周都出现以下问题：我可以而且应该在边缘部署Apache Kafka吗？还是应该将 Kafka 部署在”真正的”数据中心或公共云基础架构中？我很高兴有人问，因为这是一个有效的问题，在各个行业，包括制造业，自动化工业，航空，物流和零售。
本文解释了为什么ApacheKafka是物联网（IoT）项目中”边缘新黑“。我介绍案例和不同体系结构的使用。最后一节讨论了 Kafka 作为事件流平台如何补充边缘的其他IoT 框架和产品，以便大规模实时进行数据集成和边缘处理。
您可能还喜欢：边缘上的 IoT
多个卡夫卡集群成为常态，不是例外！
Apache Kafka 的多群集和跨数据中心部署已成为常态，而不是例外。在边缘的 Kafka 部署可以是一个独立的项目。然而，在大多数情况下，卡夫卡的边缘是整个卡夫卡建筑的一部分。
在您的组织中创建多个 Kafka 群集的原因有很多：
- 独立项目。
- 混合集成。
- 边缘计算。
- 聚集。
- 迁移。
- 灾难恢复。
- 全球基础设施（区域甚至跨大陆通信）。
- 跨公司沟通。
在我们考虑在边缘运行卡夫卡之前，我们需要定义术语”边缘”。
什么是”边缘”或”边缘计算”？
维基百科说，”边缘计算是一种分布式计算模式，它使计算和数据存储更接近需要的位置，从而缩短响应时间并节省带宽”。其他优势包括增加成本降低、灵活的体系结构和关注点分离。
阿帕奇卡夫卡在边缘
讨论”卡夫卡边缘计算”有不同的选项。
- 只有边缘客户端： Kafka 客户端在边缘运行。部署在数据中心或公共云环境中的 Kafka 群集。
- 边缘的所有东西：卡夫卡集群和卡夫卡客户端（例如工厂的传感器）部署在边缘。
- 边缘和超越：卡夫卡集群部署在边缘。Kafka 客户端（例如该地区的智能手机）在边缘运行。
因此，”卡夫卡在边缘”的范围是巨大的：
- IIoT 车间的边缘可以是用 C编写的 Kafka 客户端，并部署到传感器中的微控制器上
它在死亡和被替换之前会活一段规定时间。
在大多数情况下，”卡夫卡在边缘“意味着在边缘部署一个卡夫卡集群。Kafka 客户要么在现场运行，要么靠近现场（在某些情况下，”关闭”可能在几英里之外）。这也是我对这个博客文章的定义。在与同事和客户交谈时，只需定义”边缘”一词的含义。
现在，让我们考虑一下在边缘运行 Kafka 的用例。
边缘卡夫卡的用例
卡夫卡部署在边缘的用例存在于各个行业。无论”你的东西”是智能手机，车间的机器，传感器，汽车，机器人，提款机，或其他任何东西。
让我们来看看2019年在许多不同的企业中所看到的几个例子：
- 工业物联网 （IIoT）：实时边缘集成和处理是现代物联网架构成功的关键。工业 4.0 有多种使用案例，包括预测性维护、质量保险、流程优化和网络安全。使用 Kafka 构建数字 Twin是最常见的方案之一，非常适合许多用例。
- 零售：数字化转型支持许多新的创新用例，包括客户 360 体验、交叉销售和与合作伙伴供应商的协作。这与任何类型的零售商都相关。不管你会想到像沃尔玛这样的零售商店，像星巴克这样的咖啡店，或者像亚马逊Go商店这样的尖端商店。
- 物流：大规模实时数据关联是任何物流场景的改变游戏规则：包裹递送的端到端跟踪、交付无人机（或使用汽车的人）与本地自助收集亭之间的通信、物流中心的加速处理、汽车共享/乘车共享的协调与规划、智能城市的交通灯管理等。
卡夫卡的边缘 + 高级建筑
无论使用哪个案例，您都想要实现：Apache Kafka 边缘的体系结构通常看起来或多或少类似于以下内容（在非常高的级别上）：
卡夫卡为什么和如何帮助边缘？
上面讨论的想法和用例并不新鲜。但是，想想您最喜爱的消费者应用程序、零售商或咖啡店：有多少企业已经以可靠的方式推出了针对特定上下文的推送消息、客户体验或其他服务的实时应用程序？
老实说，不是很多。只有一些科技公司，如优步和莱夫特做了伟大的工作毫不奇怪，所有的科技公司都使用事件流平台Kafka作为他们实时基础设施的核心。
但如今情况越来越好。越来越多的传统企业已经在其数据中心或云中推出了一个事件流平台，以大规模实时处理数据，以构建创新应用程序。
边缘的挑战
企业往往面临挑战，无法将这些创新的实时应用程序引入数据在本地站点（如工厂、零售商店、咖啡店等）中分发的方案。
挑战包括：
- 由于网络不良和许多其他限制，与所有硬件、机器、设备在边缘进行集成是很困难的
- 对于许多用例来说，大规模和实时处理是强制性的。因此，处理应该在现场进行，而不是在远程数据中心或云中（通常有数百英里远）。
- 各种技术和协议必须在边缘集成。通常，传统和专有协议需要与隧道另一端的现代大数据工具进行通信。
- 有限的硬件资源和人才在边缘。IT 专家不能到现场前往每个位置。团队不能在每个站点上持续花费大量资金在硬件和操作上。
数据必须在本地大规模实时存储和处理。此外，需要将数据复制到数据中心或云，以便对来自不同站点的聚合数据进行进一步处理和分析。在最好的情况下，通信是双向的，因此可以通过将命令和控制事件发送回本地站点，从一个点控制较小的本地站点。
边缘和数据中心/云中的相同基础架构和技术
边缘用例的实现需要付出很多努力。向所有站点推出解决方案是另一个重大挑战。理想情况下，企业可以在工厂或商店以及大数据中心或云中现场利用相同的基础架构、技术和应用程序。
这就是为什么 Apache Kafka 在越来越多的边缘场景中发挥作用的原因：利用无处不在的相同基础架构、技术和应用程序。实时流处理、可靠性和灵活的可扩展性是卡夫卡的核心功能。这允许在云中出现大规模方案，在边缘使用中小型规模方案。
让我们来看看在边缘部署卡夫卡的不同选项。
用于边缘计算的卡夫卡架构
你必须问自己的关键问题：我需要在边缘高可用性吗？
边缘计算并不总是需要高可用性。如果是这样，则部署传统的 Kafka 群集。如果没有，那么你选择简单和更便宜的选项，只有一个单一的卡夫卡经纪人在边缘。硬件设备可以使在数十个或数百个站点中推出它变得更加容易。
下面的示例显示了三个边缘站点。每个站点都部署了一个 Kafka 群集，包括额外的 Kafka 组件：
与 3+ 卡夫卡经纪商在边缘进行弹性部署
Kafka 及其生态系统专为高可用性和零停机时间（即使单个节点发生故障）而构建。通常，部署分布式系统。卡夫卡和动物园管理员至少需要三个节点cheeli.com.cn/wp-content/uploads/2020/01/Resilient-Kafka-Configuration-at-the-Edge.png”样式\”显示：块;垂直对齐：顶部;边距：5px自动;文本对齐：中心;”宽度=”602″/*
有关部署最佳实践的更多详细信息，请查看Apache Kafka 和 Confluent 平台参考体系结构。这些最佳实践不会在边缘更改。话虽如此，负载和吞吐量通常较低的边缘。因此，内存较少，磁盘更小通常就足够了。这完全取决于您的 SL、要求和用例。
一个单一的卡夫卡经纪商在边缘进行非弹性部署
在边缘部署”轻量级卡夫卡群集”和与更大的中央 Kafka 群集同步/复制数据的需求越来越多。由于硬件限制或低S.SAS关于高可用性，只部署一个单一的卡夫卡经纪人（加上一个动物园管理员）的边缘是完全罚款。您甚至可以在一台服务器上部署整个 Kafka 环境：
这造成了一些明显的缺点：没有复制，节点或网络发生故障时停机，数据丢失的风险;但是，单节点 Kafka 部署工作，仍然提供了卡夫卡基本原理的许多好处：
- 生产者和消费者之间的脱钩。
- 反压处理。
- 大容量实时处理（即使是一个代理也有很大的功能）。
- 磁盘上的存储。
- 能够重新处理数据。
- 所有 Kafka 原生组件均可用（Kafka 连接用于集成，Kafka Streams 或 ksqlDB 用于流处理，架构注册表用于治理）。
单Broker Kafka 部署效果良好。只需注意缺点，并仔细检查这是否适合您的 S…A和要求。
动物园管理员删除 – 卡夫卡在边缘的一个伟大的帮助
卡夫卡是一个强大的分布式基础设施。因此，卡夫卡并不是最容易运营的基础设施。一个关键的原因是依赖于 ZooKeeper（许多其他分布式系统（如 Hadoop 或 Spark）也是如此）。我不会详细介绍动物园管理员的挑战和问题。网上有足够的信息。TL;DR：动物园管理员使卡夫卡更难操作，也不太可扩展。许多P1和P2支持门票不是关于卡夫卡，而是关于动物园管理员（不是因为动物园管理员是不稳定的，但因为它很难操作）。
由于大多数物联网项目不会只计划一年，而是在 5 年及更多年内推广到不同的地点，因此请记住，Kafka 在 1 年之后，如果没有 ZooKeeper，将更容易、更轻巧。
卡夫卡作为边缘设备和云之间的网关
卡夫卡网关是体系结构中的附加可选组件。在某些配置中，您可能希望边缘设备与本地网关进行内部通信。
例如，在工业工厂中，您可能会看到多台机器或生产线作为边缘设备。它们与自己的 Kafka 群集集成，并将此数据发送到网关 Kafka 群集。在网关 Kafka 群集中，您可以在本地直接执行一些分析，并可能筛选或转换数据，然后再将其发送到大型远程聚合 Kafka 群集：
Hivecell是一个有趣的示例，您可以使用。”Hivecell 使公司能够在没有技术人员大军的情况下在边缘部署和维护软件”是此次创业公司的口号。只需将一个或多个盒子运送到站点，将其连接到本地 WiFi，其他一切都可以远程完成。
Hivecell 盒以预配置的方式发货。例如，硬件可能已经安装了Kubernetes、卡夫卡生态系统和其他业务应用程序。像Confluent 运算符这样的工具可以在包装盒上运行，以简化和自动化边缘 Kafka 环境的操作。这样，远程管理通常就足够了。
通信、连接、集成、数据处理
如上图所示，卡夫卡环境不仅包括卡夫卡经纪人和强制动物园管理员。通信、连接、集成和数据处理是 Kafka 基础架构中的重要组件，无论在云、内部还是边缘：
卡夫卡经纪商与卡夫卡客户之间的沟通：
仅边缘： 设备 -> 边缘卡夫卡 – > 设备
- 边缘到远程： 设备 -> Kafka 在边缘 – > 复制 -> Kafka （数据中心 / 云） – > 分析/实时处理。
- 双向：1）和2）的组合，用于边缘和远程卡夫卡集群之间的双向通信。
卡夫卡-原生连接、集成、数据处理：
卡夫卡原生组件利用卡夫卡在引擎盖下。这样，您就只需管理一个平台，以便大规模实时通信、集成和处理数据：
- 卡夫卡连接： MQTT， OPC-UA， FTP， CSV， PLC4X （传统和专有的IIoT协议和PLC，如Modbus，西门子S7，贝克霍夫，艾伦布拉德利）等。
- 镜像制造商 2/Confluent 复制器：两个 Kafka 群集之间的单向或双向复制
- Kafka 客户端（生产者/消费者）：Java、Python、C++、C、Go、Javascript、…
- 数据处理： 使用 Kafka 流或 ksqlDB 的流处理（无状态流式处理 ETL 或有状态应用程序）
- 代理： 用于 HTTP（S） 通信的 REST 代理，用于 MQTT 集成的 MQTT 代理
- 架构注册表：治理和架构实施
特别是在通常硬件资源有限的边缘…仔细检查是否需要其他数据库或外部处理框架！也许卡夫卡堆栈足以满足您的需求？
卡夫卡不是物联网框架
卡夫卡可用于非常不同的场景。它最适合大规模事件流，并构建可靠和开放的基础架构，以在边缘和企业的其他部分集成物联网。
卡夫卡不是每个问题的灵丹妙药。特定的物联网产品可能是集成和处理物联网接口和车间车间的更好选择。这取决于具体要求、现有生态系统和已经使用的软件。
需要评估解决方案的复杂性和成本。”构建与购买”始终是一个有效的问题。通常，最佳选择和解决方案是构建开放、灵活、自建的中央流式传输基础架构和购买 COTS 以进行特定的边缘集成和处理方案。
混合架构 – 何时以及为什么使用其他 IoT 框架和产品？
你应该总是问自己：单独卡夫卡足够吗？如果是，为什么使用额外的框架或产品？随着每一项附加技术，端到端集成变得更加困难。24/7 部署、零数据丢失和无延迟峰值的实时处理是 Kafka 最适合的要求。
如果 Kafka 本身不够，请将它与其他 IoT 框架或解决方案相结合：
有时，车间连接到 IoT 解决方案。IoT 解决方案用作网关或代理。这可以是一个广泛、强大（但更复杂和更昂贵的）解决方案，如西门子MindSphere。或者选择部署”只是”一个特定的解决方案，一个更轻量级的解决方案来解决一个问题。
例如，HiveMQ 可以部署为可扩展的 MQTT 群集，以连接到计算机和设备。此 IoT 网关或代理连接到卡夫卡。Kafka 部署在同一基础设施或其他数据中心或云中。Kafka 群集连接到企业的其余部分。
在其他方案中，Kafka 用作 IoT 网关或代理，可直接连接到 PLC 或分布式控制系统 （DCS）。然后，Kafka 连接到 IoT 解决方案，如 AWS IoT 或 Google 云的 MQTT 桥，在那里进行进一步的处理和分析。
沟通通常是双向的。无论您选择何种体系结构：数据都是从车间或其他 IoT 设备引入的，实时处理和关联，最后控制事件将发送回计算机。例如，在预测分析中，您首先使用云中的 TensorFlow 等工具训练分析模型。然后，在边缘部署分析模型以进行实时预测。
您是否需要 NiFi/MiniFi 或 ESBETL 工具？
我刚刚解释了为什么您可以将 Kafka 与其他 IoT 框架或解决方案相结合。这些与 Kafka 生态系统非常互补，并侧重于不同的用例，如设备管理、培训分析模型、报告或构建数字孪生。
例如，主要云提供商为设备管理、云服务代理和分析工具提供 IoT 服务。在边缘，Eclipse IoT 仅提供各种 IoT 框架。例如，Eclipse ditto 是构建数字孪生体的绝佳开源框架基础架构必须全天候运行，而不会停机和数据丢失。中间件组件组合越多，就越难确保您的 SL 和要求。
如果可以运行 Kafka 基础结构 99.95，对于与它结合的每个附加中间件组件，端到端可用性就会下降。此外，您必须开发、测试、操作和支付两个或多个中间件组件，而不是只关注单个基础结构。
SLAs 重要吗？卡夫卡吃狗食
这是卡夫卡的主要优势之一;Kafka 吃狗食：所有组件都利用 Kafka 协议及其功能，如偏移、复制、消费群体等：
我看到像ApacheNiFi或Node-RED这样的工具的附加价值：你有一个拖放UI来构建管道。这很好！如果你只需要建立一个管道，将数据从边缘发送到数据湖的报告和分析，Nifi等人是伟大的工具 – 如果你能忍受停机和数据丢失的风险！
Kafka + NiFi + XYZ = 太多的分布式系统无法运行！
如果您必须构建一个可扩展、可靠的流式处理基础架构，以便进行边缘计算和混合架构，而不会造成停机和数据丢失：相信我，您将感到痛苦。我见过许多部署，其中结合不同中间件工具的端到端集成没有通过集成测试。这个想法在开始时看起来不错，但对于任务关键型方案来说不够可靠。
再想想：组合的工具越多，中断或数据丢失的风险就越高！例如，NiFi 运行自己的分布式基础架构。这意味着您必须保证从生产商通过 NiFi 和 Kafka 到最终消费者全天候的端到端升期。
卡夫卡原生工具，如卡夫卡连接或卡夫卡流使用卡夫卡主题（包括卡夫卡的所有高可用性功能）引擎盖下。这意味着您必须在 24/7 模式下只运行单个基础架构，以确保端到端集成，而不会造成停机和数据丢失。
当我看到架构建议时，我的心疼痛，你有管道，如”传感器ABC > NiFi （吸收） ->卡夫卡主题A ->NiFi（转换） ->卡夫卡主题B ->NiFi（负载） -&>应用程序XYZ”。同样，这对批处理 ETL 管道来说很好，我看到像 NiFi 这样的漂亮 UI 工具的附加价值。但这不是建立24/7基础设施的正确方法，用于大规模实时处理，实现零数据丢失。
我有很多材料可以了解事件驱动的流平台（如 Apache Kafka）和中间件（如 NiFi、节点-RED、消息队列 （MQ）、提取-转换加载 （ETL） 和企业服务总线 （ESB））之间的差异。
卡夫卡在边缘巩固混合物联网架构
“卡夫卡在边缘”是新的黑色。许多行业在混合架构中部署 Kafka。边缘计算允许创新的用例，提高处理速度，降低网络成本，使整个基础设施更具可扩展性、可靠性和鲁棒性。
从小处着手，在一个站点的边缘推出 Kafka，将其连接到远程卡夫卡群集。然后，逐步连接越来越多的站点或构建双向用例。
边缘计算只是整个体系结构的一部分。在咖啡店、零售商店或小工厂等小网站只部署一个 Kafka 经纪人是可以的本地处理允许大规模实时处理任务关键型，而无需远程通信。这降低了成本并提高了安全性。
附加价值通常来自将来自不同站点的数据组合出来，以便将其用于实时决策。物联网卡夫卡基础设施通常将小型边缘部署与数据中心或公共云中更大的卡夫卡部署相结合。同时，您甚至可以跨多个数据中心运行单个 Apache Kafka 群集，以构建区域和全球 Kafka 基础设施，并将这些集群连接到本地边缘的 Kafka 群集。
你对卡夫卡在边缘和混合架构有什么看法？请让我知道。让我们LinkedIn，讨论您的用例、体系结构和要求。
