Kafka at the Edge：用例和架构

边缘Kafka部署的用例和架构，包括零售店、手机发射塔, ......

边缘使用Apache Kafka的事件流不再是前沿。这是一种常见的方法，可以在边缘提供与云或数据中心相同的开放、灵活和可扩展的架构。Kafka边缘部署的可能位置包括零售店、手机发射塔、火车、小工厂、餐馆等。我在过去已经详细讨论了概念和架构：“Apache Kafka是边缘的新黑人”和“分布式、混合、边缘和全球Apache Kafka部署的架构模式”。这篇博客文章是一个插件，专注于卡夫卡在边缘的跨行业用例。

在您继续阅读之前，请明确：边缘不是数据中心。

“边缘卡夫卡”不仅仅是另一个在远程使用卡夫卡的物联网项目。边缘卡夫卡实际上是跨越物联网（或工业物联网中的OT）和非物联网（传统数据center/cloud基础设施）的流式神经系统的重要组成部分。

这篇文章的重点是Kafka客户端和Kafka代理在边缘运行的场景。这使得边缘处理、集成、解耦、低延迟和经济高效的数据处理成为可能。

Kafka at the Edge的分类和架构

一些物联网项目的构建与“普通的卡夫卡项目相似”，即构建在（边缘）数据中心或云中。例如，更大的工厂可以提供基础设施来部署可靠的卡夫卡集群，并与云保持稳定的网络连接。不幸的是，许多物联网项目需要真正的边缘能力。

边缘有什么不同？

即使无法连接到中央数据中心或云，离线业务连续性也很重要。Disconnected/offline站点通常不需要或提供高可用性（因为不值得努力）：本地预处理、低延迟的实时分析、仅不时在线（即连接到数据中心或云）或低带宽。
通常这些项目需要跨数百个地点部署卡夫卡经纪人。单个经纪人通常足够好，没有高可用性，但用于背压和本地处理。用例存在于各个行业，包括零售店、火车、餐馆、手机发射塔、小工厂等。
对于许多这样的用例来说，低占用空间、低接触、很少或不需要开发操作的Kafka经纪人安装（不仅仅是客户端）是强制性的。在这种情况下，没有信息技术专家“现场”来操作Kafka。因此，使用经过认证的原始设备制造商硬件是在边缘安装和操作Kafka的绝佳选择。
许多边缘用例都围绕着传感器和遥测数据。这不是每条消息都重要的事务数据。每秒处理数百万条消息的应用程序可以丢失一些消息，因为它不会影响计算结果。
混合而不仅仅是云：消费者物联网（CIoT）总是包括智能家居、拼车、零售店等用户。），工业物联网（IIoT）总是包括有形商品（汽车、食品、能源, ...)
成千上万的连接接口：传感器、机器、移动设备等。

使用单一的技术基础设施可以构建边缘和混合架构。不需要大量不同的框架和产品。从开发、测试、运营和支持的角度来看，这是一个巨大的好处！

Kafka at the Edge的用例

卡夫卡在边缘的行业包括制造业、制药、汽车制造商、电信、零售、能源、餐馆、游戏、医疗保健、公共部门、航空航天、运输等。

架构和用例包括数据集成、预处理和复制到云、大小数据边缘处理和分析、断开连接的离线场景、数百个位置的极低占用空间场景、没有高可用性的场景等。

使用Kafka进行边缘计算的场景

Kafka在边缘的部署有各种各样的例子。几乎所有这些用例都与上述几个类别和需求有关，例如低硬件占用空间、断开的离线处理、数百个位置和混合架构。

我曾与不同行业和全球的企业合作过以下场景：

公共部门：每个城市的地方管理，智能城市项目，包括公共交通，交通管理，来自不同汽车制造商的各种联网汽车平台的集成，网络安全（包括物联网用例，如捕获和处理相机图像）
Transportation/Logistics/Railway/Aviation：跟踪和跟踪，卡夫卡在列车离线和本地processing/storage，旅客信息（延迟或取消flight/train/bus），实时忠诚度平台（等级升级，休息室访问）
制造业（汽车、航空航天、半导体、化工**、食品**和其他）：物联网售后市场客户服务、机器和车辆的原始设备制造商、嵌入标准软件（如企业资源规划或制造执行系统）、网络安全、devices/machines/productionlines/processes的数字双胞胎、工厂生产线监控，以实现预测性maintenance/qualitycontrol/production效率、运营仪表板和生产线健康（工厂经理现场监控，高管管理的全球关键绩效指标汇总）、跟踪和跟踪以及车间的地理围栏
Energy/Utility/Oil和天然气：智能家居、智能建筑、智能电表、远程机器监控（如钻井、风车、采矿）、管道和炼油厂操作（如预测故障或异常检测）
Telecommunications/Media：开放源码软件实时monitoring/problemanalysis/metricsreporting/root导致网络设备和基础设施（路由器、交换机、其他网络设备）的analysis/action响应、BSS客户体验和OTT服务（面向数百万用户的移动应用集成）、5G边缘（例如，街道传感器）
医疗保健：医院跟踪和跟踪，远程监控，机器传感器分析
Retailing/Food/Restaurants/Banking：客户沟通、cross-/up-selling、忠诚度系统、零售店支付、永久库存、（本地）支付和（远程）客户关系管理集成的销售点（PoS）集成、EFTPOS（销售点电子资金转移）

零售业边缘计算的一个很好的实际例子是快餐连锁店Chic-filA。他们在2000家餐厅的每一家都部署了一个Kubernetes集群，在没有互联网连接的情况下在边缘进行实时分析。硬件非常小，提供了一个8GB内存和固态硬盘的英特尔四核处理器：

示例边缘架构：运输和物流中的卡夫卡

让我们用一个具体的例子让这个“边缘的卡夫卡”的事情变得更清楚。在这种情况下，我使用铁路和运输行业。但是这可以很容易地映射到你的行业和用例。

以下示例展示了铁路的边缘和混合解决方案，以改善客户体验并增加铁路公司的收入。它利用离线边缘处理进行客户沟通，复制到云中进行分析，并与合作伙伴的第三方接口和API集成。

混合架构—从边缘到云

边缘的本地处理正在火车上进行。但是每列火车也将相关数据实时复制到云中——如果有互联网连接和免费网络资源的话。如果火车不在线，卡夫卡正在处理反向压力，并在再次在线时复制到云中：

与卡夫卡在火车边缘的事件流

火车上的卡夫卡不仅仅用于实时消息传递和处理反向压力。这些已经是在边缘使用卡夫卡的很好的理由。尽管如此**，当卡夫卡也用于数据集成**（餐馆、旅行者信息、忠诚度系统等）时，创造了更大的价值。）和数据处理（up-/cross-selling、实时延迟信息等）。）在边缘。这样，只需要一个平台来解决所有不同的问题：

卡夫卡Disconnected/Offline场景

火车**（和许多其他边缘位置）定期**离线。例如，火车穿过隧道或到达没有手机连接的区域。本地处理仍然是可能的。业务连续性是改善客户体验和增加销售流程的关键——即使火车与互联网断开了连接。乘客仍然可以使用移动应用程序查看旅行者信息，在餐馆购买食物，或者在火车的本地服务器上观看电影商店。一旦列车再次连接互联网，乘客的购买将转移到云中的忠诚度系统，最新的延迟信息将从云中消耗并存储在列车中的边缘卡夫卡经纪人等。等等。等等。：

跨公司卡夫卡和边缘集成

数据处理不会随着边缘（火车）和云（客户关系管理、忠诚度系统等）之间的混合集成而停止**。）。不同的部门或合作伙伴公司也**需要集成。不是使用不可扩展的同步REST应用编程接口调用/应用编程接口管理进行合作伙伴集成，而是使用卡夫卡本地技术进行流式复制是一种更好的、可扩展的方法：

我希望这个关于Kafka在边缘的故事能帮助您更好地理解如何利用行业中的事件流和用例来构建从边缘到云的端到端流基础架构。

边缘部署卡夫卡的基础设施和硬件需求

最后，重要的是讨论如何在边缘部署卡夫卡，明确一点：卡夫卡还需要一些计算能力。

显然，这取决于许多因素：您正在使用的硬件供应商和基础设施、特定的SLA和HA需求等等。好消息是Kafka可以部署在许多基础设施中，包括裸机、虚拟机、容器、Kubernetes等。另一个好消息是用于计算资源的新硬件（即使是“边缘”）通常有4、8甚至16GB内存，因为这是目前芯片供应商生产的最小的芯片（用于小型工厂、零售店等环境）。

**运行非常小的占用空间Kafka的最低硬件要求是单核处理器和几个100MB内存。这已经允许在单个Kafka节点上进行100+Mb/sec吞吐量的体面边缘处理（复制因子=1）。**然而，真正的值取决于分区数量、消息大小、网络速度和其他特性。不要期望与数据中心或云中的性能和可扩展性相同！

因此，您可以在Raspberry Pi上部署Kafka代理，但不能在一些小型嵌入式设备上！后者是Kafka客户端可以运行的地方。

在边缘部署卡夫卡的“融合方式”

从技术角度来看，在边缘部署Kafka与在数据中心或云中部署Kafka是一样的。然而，正如我们上面所了解的，环境和要求有点不同。一些额外的功能肯定有助于在边缘部署和操作Kafka。

我为合流工作。因此，我为你提供**“合流方式”，在你未来的项目中部署卡夫卡，包括创新的、差异化的**功能：

融合服务器包括Kafka Broker和各种增强功能，如自平衡集群、分层存储、嵌入式REST应用编程接口、服务器端模式验证等。它可以部署为单个节点（非常轻量级，但没有高可用性）或集群（用于需要边缘高可用性的关键任务工作负载）。
2020年，ZooKeeper仍然是一个额外的组件。然而，ZooKeeper的移除将在2021年到来！许多合流工程师全职工作，从Kafka项目中移除（丑陋的）动物园管理员依赖关系，这意味着有可能运行一个由Kafka驱动的独立的单进程边缘解决方案。整个Kafka社区都期待着这种架构变化。当然，你今天已经可以在边缘运行Kafka了。它也和ZooKeeper一起工作得很好。
**集群链接**允许所有这些小型卡夫卡边缘站点使用卡夫卡协议连接到数据中心或云中更大的卡夫卡集群。不需要使用额外的工具和基础设施，如合流复制器或镜像制作器。这显著降低了开发工作和基础设施成本。
使用合流工具集进行监控和**主动支持。例如，一个控制中心可以监控几个不同的（远程）卡夫卡集群。合流遥测报告**器从边缘站点收集数据。监控包括技术基础设施，也包括应用程序和端到端集成。
Kubernetes正在成为**许多边缘部署的首选边缘编排平台。例如，使用MicroK 8s Kubernetes发行版。融合运营商（自定义资源定义，CRD）提供了在边缘预配和运营单代理或集群部署的能力。这包括滚动升级、安全自动化等。融合运营商已经在融合云和数据中心融合平台的大规模部署中经过了战斗测试。Chic-fil-A在2000多家快餐店运行Kubernetes以提供断开连接的边缘服务和低延迟方面有着巨大的成功故事。Kubernetes显然是可选的。只有当它真正增加价值时才使用它，并且不要太复杂和资源匮乏。许多边缘部署可能会使Kubernetes**失去资格，因为它太重量级和复杂。
数据集成和数据处理是边缘的关键。合流为传统和现代系统提供连接器（包括**用于PLC、OPC-UA和IIoT集成的PLC 4X、数据库CDC连接器、MQ和MQTT集成、用于高安全性或肮脏环境中单向UDP网络的数据二极管连接器、云连接**器等）。卡夫卡流和ksql DB允许轻量级但强大的流处理，而不需要另一种技术。
轻量级边缘客户端（例如，嵌入式设备）利用**Kafka和REST代理的C或C++客户端**应用编程接口通过超文本传输协议（超文本传输协议）从任何编程语言进行通信。这对于许多计算能力有限的低功耗边缘设备来说很重要，因为Java或类似的“资源饥饿技术”无法部署。
可选的是，认证的、预配置的原始设备制造商硬件是可用的。你把盒子放在边缘，连接到局域网或无线网络，然后使用它。就这样。基础设施的管理和监控是通过硬件供应商的远程软件进行的。“Hivecell上可行的视频处理”演示了卡夫卡集群、卡夫卡流应用程序和实时图像识别的嵌入式机器学习模型的边缘分析。

边缘的卡夫卡（以及混合架构中的卡夫卡）是新的黑色

Kafka是一个很棒的边缘解决方案。它能够在边缘、数据中心和云部署相同的开放、可扩展和可靠的技术。这与跨行业相关。卡夫卡被用于越来越多以前没人见过的地方。边缘网站包括零售店、餐馆、手机发射塔、火车和许多其他网站。我希望各种用例和架构能给你一点启发。

你在边缘有什么经验？你的用例是什么？你是否或计划使用Apache Kafka及其生态系统？你的策略是什么？让我们**在**领英上联系并讨论它！

主题：

kafka，物联网，工业物联网，机器学习，分析，边缘，边缘计算， opc， kafka连接器， iot

【译】Kafka at the Edge：用例和架构