【.com快译】如今，在IoT（物联网）边缘使用ApacheKafka进行事件流处理已不再是一项高深的技术。作为一种通用方法，Kafka在边缘提供与在云端和数据中心相同的开放、灵活和可扩展的架构。它是跨越物联网和非物联网（例如传统数据中心和云基础设施）的流神经系统的基本组成部分。事实上，Kafka可以部署在各种边缘位置，例如零售店、手机信号塔、火车、小型工厂和餐馆。本文将重点介绍Kafkaclients和Kafkabroker（经纪人）在跨行业边缘的用例和架构，包括边缘处理、集成、解耦、低延迟和高性价比的数据处理。Kafka在边缘的类别和架构大多数物联网项目的建设与数据中心或云端的普通Kafka项目有着根本的不同。它们无法提供可靠的Kafka集群并在云端建立稳定的网络连接，但具有以下边缘功能：由于没有与中央数据中心或云端的高可用性连接，因此它们没有一些本地预处理、低延迟实时分析、低带宽间歇性连接等，离线业务连续性非常重要。项目通常需要在数百个位置部署Kafka代理，例如零售店、火车、餐馆、手机信号塔、小型工厂等。因此，单个代理虽然不需要高可用，但必须能够承受背压，提供本地处理能力。Kafka代理（不仅仅是客户）需要低占用空间、低接触和最小的DevOps安装要求（即：几乎没有IT人员在现场操作和维护Kafka）。因此，使用经过认证的OEM硬件是在边缘安装和运行Kafka的绝佳选择。许多边缘用例涉及传感器和遥测数据。与不能丢失每笔交易数据的电子商务系统不同，物联网应用场景允许在每秒处理数百万消息的应用程序中丢失少量消息，而不影响最终的计算结果。混合云或非云：消费物联网（CIoT）将涉及智能家居、共享乘车、零售店等环境，而工业物联网（IIoT）将涉及汽车、食品、能源等生产场景。它通常包括数以千计的连接接口，例如传感器、主机和移动设备。Kafka在边缘的用例总体来说，Kafka在边缘的架构和部署场景包括：数据集成、预处理、云复制、大（小）数据在边缘的处理和分析、连接中断时的离线解决方案、上百点的极低硬件空间占用方案、非高可用方案等。接下来我们来看几个典型行业的应用：来自不同汽车制造商的车联网平台、图像捕获和处理、物联网安全和其他智能城市项目。交通/物流/铁路/航空：在火车上，Kafka可用于离线处理和本地存储，旅行信息的Track&Trace（包括延误或取消等信息的跟踪），实时用户忠诚度平台（包括舱位升级，休息进入房间）。汽车/航空航天/半导体/化工/食品等制造业：物联网售后客服、机器车辆代工、嵌入式标准软件（如：ERP或MES系统）、数字孪生/设备/机器/生产过程线，以及通过监控工厂的生产线，执行预测性维护、质量控制、仪表板/车间/周边健康跟踪等。能源/公用事业/石油和天然气：智能家居/建筑/电表、远程设备监控（例如钻井钻机、风车或采矿机），管道和精炼操作的预测性异常检测和故障排除。电信/媒体：OSS（OperationSupportSystem）实时监控、指标上报、问题分析、根本原因分析、网络设备和基础设施（如：路由器、交换机等网络设备）的响应、BSS（BusinessSupport）系统）客户体验、OTT服务（各种第三方移动应用程序的集成）以及5G边缘（例如：街道上的传感器）设备的状态。医疗保健：在医院实施跟踪、远程监控、设备传感器分析等零售/食品/餐厅/银行：客户沟通、交叉销售、忠诚度分析、零售支付、库存盘点、PoS机器集成、远程CRM集成和EFTPOS（销售点电子资金转账）。我们曾经为零售快餐连锁品牌Chic-fil-A部署过边缘计算的相关服务。我们已经在其所有2000家餐厅中部署了Kubernetes集群（参见--https://www.infoq.com/presentations/chick-fil-a-k8-clusters/），以便在没有互联网连接时，实时分析仍然可以通过边缘计算来实现（参见--https://medium.com/@cfatechblog/edge-computing-at-chick-fil-a-7d67242675e2）。下图是他们的硬件边缘设备，外观非常小巧，内部搭载英特尔四核处理器、8GB内存和SSD。边缘的示例架构：运输和物流中的Kafka让我们通过一家铁路公司的具体案例来举一个边缘的Kafka混合体的具体示例。该解决方案利用离线边缘处理来实现客户通信、云复制分析以及与第三方合作伙伴接口和API的集成。虽然这是铁路运输行业的一个例子，但我们可以很容易地将其映射到其他行业。混合架构——从边缘到云想象一下，一列火车在边缘本地处理生成的信息。如果有互联网连接和免费网络资源，那么列车会实时将相关数据复制到云端。如果火车在行驶过程中失去网络连接，Kafka将处理背压并在网络连接恢复时将数据复制到云端。下图是在边缘和云端使用的Kafka混合架构：Kafka在边缘的事件流如下图所示，train在边缘使用ApacheKafka实现real-时间消息/事件流。在离线/离线场景下使用Kafka当火车通过隧道或到达没有网络连接的区域时，它会出现离线。此时，我们需要列车上的边缘设备仍然能够进行本地处理。毕竟，业务连续性是改善客户体验和增加销售额的关键因素。即使列车处于离线状态，乘客仍然需要一个移动应用程序来查看时刻表信息、在餐厅购买食物或在列车的本地服务器上观看电影。同时，一旦列车上重新建立互联网连接，乘客的购买交易将转移到云端的用户忠诚度系统，需要查询的最新消息也将从云端传递（消费）并存储在火车的边缘——卡夫卡代理处。下图展示了Kafka在离线和断开模式下如何在边缘处理数据。跨公司Kafka和边缘集成由于数据处理将继续发生在边缘（例如：火车）和云系统（例如：CRM、忠诚度系统等）之间的集成系统中，不同的合作伙伴也将不得不进行这种集成。与通过不可扩展的同步RESTAPI调用/API管理在合作伙伴之间进行集成相比，使用Kafka的原生事件流复制机制是一种更好、更具扩展性的方法。下图展示了合作伙伴如何进行跨公司的Kafka复制和API管理。在边缘部署Kafka的基础设施和硬件要求让我们讨论如何在边缘部署Kafka。注意Kafka需要目标系统有一定的计算能力。这取决于您使用的是什么：硬件供应商、基础设施、特定SLA、高可用性要求和许多其他因素。值得庆幸的是，Kafka可以部署在许多基础设施中，包括裸机、虚拟机、容器和Kubernetes。当前供应商可以生产的可用于边缘的最小芯片通常具有4GB、8GB甚至16GB的RAM。实际上，运行Kafka所需的最低硬件配置是：单核处理器+几百MB内存。此配置使单个Kafka节点（复制因子=1）能够以超过100Mb/秒的吞吐量执行边缘处理。当然，实际值还要取决于分区数量、消息大小、网络速度等各种因素。这当然比不上数据中心或云的性能和可扩展性。因此，您可以在RaspberryPi上部署Kafka代理，但不能在小型嵌入式设备上部署，毕竟我们可以在其中运行Kafka客户端。在边缘部署Kafka的“合流之道”从技术角度来说，在边缘部署Kafka与在数据中心或云端部署类似，只是环境和需求不同。并且一些额外的功能会方便我们对Kafka的部署和运维。接下来我们来看看Confluent部署方式的创新差异化功能：1.Confluent服务器包括Kafka代理和各种增强功能，包括：自平衡集群、分层存储、内嵌RESTAPI、服务器端schema验证等。它可以部署为单个节点（非常轻量级，但不是高可用）或集群模式（主要用于依赖边缘高可用性的关键任务工作负载）。2、虽然这种方式仍然需要ZooKeeper作为附加组件来实现协同工作，但预计在2021年不再需要。届时，它将是一个独立的单进程边缘解决方案，由Kafka提供支持。3.ClusterLinking（集群链接，参见--https://www.confluent.io/blog/kafka-cluster-linking-with-confluent-platform）允许所有小型Kafka边缘站点使用Kafka协议连接数据在中心或云端的较大Kafka集群中，无需使用其他工具和框架，例如ConfluentReplicator或MirrorMaker。因此，开发人员可以显着降低基础设施的成本和工作量。4.使用Confluent的工具集进行监控和主动支持（主动支持，请参阅--https://docs.confluent.io/5.4.0/proactive-support.html）。例如，一个控制中心可以监控多个不同的远程Kafka集群。监控的目标不仅包括技术架构，还包括应用程序和端到端的集成。ConfluentTelemetryReporter（参见——https://docs.confluent.io/current/kafka/telemetry.html#what-data-is-sent-and-how-it-is-used）将从边缘站点发送收集相关数据。5.目前，Kubernetes（MicroK8sKubernetes发行版，参见--https://microk8s.io/）正在成为许多边缘部署的首选编排平台。ConfluentOperator可以仅在边缘提供单个代理，或为集群部署提供滚动升级，以及安全自动化等操作功能。上面提到的Chic-fil-A正在2000多家快餐店运行Kubernetes（参见--https://medium.com/@cfatechblog/edge-computing-at-chick-fil-a-7d67242675e2），并提供各种低延迟边缘服务，正是ConfluentOperator在数据中心大规模实际部署ConfluentCloud和ConfluentPlatform的成功案例。当然，Kubernetes是可选的。一些边缘地方使用Kubernetes后，增加了复杂度，消耗了有限的资源。6.由于数据集成和数据处理是边缘计算的关键，Confluent为新旧系统提供连接器，包括用于PLC、OPC-UA和IIoT集成的PLC4X（参见--https://www.kai-waehner.de/blog/2019/09/02/apache-kafka-ksql-and-apache-plc4x-for-iiot-data-integration-and-processing/)、数据库CDC连接器、MQ和MQTT集成、云连接器和DataDiode连接器对于高安全性或“肮脏环境”中的单向UDP网络（请参阅--https://docs.confluent.io/current/connect/kafka-connect-data-diode/index.html）。当然，KafkaStreams和ksqlDB允许轻量级和强大的事件流处理。7.轻量级边缘客户端（例如嵌入式设备）可以利用C和C++客户端上的Kafka和REST代理API（参见--https://github.com/edenhill/librdkafka）通过HTTP(S)与任何编程语言进行通信.这对于许多计算能力有限的低功耗边缘设备来说非常重要。毕竟，我们无法在这些设备中部署Java或类似的“资源匮乏技术”。8.您还可以选择在边缘放置经过认证、预配置的OEM硬件，将其连接到LAN或WiFi，并使用硬件供应商提供的远程软件来管理和监控基础设施。视频“Hivecell上的可行处理”（参见--https://medium.com/hivecell/feasible-video-processing-on-hivecell-a28f9a059ccf）展示了如何使用Kafka集群、KafkaStreams应用程序和嵌入式机器学习模型用于图像识别、边缘分析。总结作为一个优秀的边缘解决方案，Kafka使您能够在边缘、数据中心和云端部署同样开放、可靠和可扩展的技术。希望以上介绍的Kafka在边缘的用例和架构，能够帮助大家更好地理解在各个行业如何使用事件流和工具构建从边缘到云端的物联网架构。原标题：KafkaattheEdge—UseCasesandArchitectures，作者：KaiW?hner
