【.com快译】在边缘技术领域，从事制造、自动化、航空、物流、零售等应用的开发者经常会思考一个问题是：ApacheKafka应该是部署在边缘、“真实”数据中心或公共云基础设施中？)边缘的不同用例和架构用法。在文章的最后，我们还将讨论Kafka作为事件流平台如何在边缘与其他物联网框架和产品相辅相成，实现大规模的实时数据集成和边缘处理。规范化多Kafka集群如今，ApacheKafka的多集群、跨数据中心部署已经成为业界一定的常态。虽然“边缘卡夫卡（Kafkaattheedge）”可以作为一个独立的项目进行部署；但在大多数情况下，它是整个Kafka架构的一部分。很多企业创建多个Kafka集群的原因如下：独立的项目需求。混合集成方法。边缘计算。组件聚合。平台移植。灾难恢复。区域或洲际通信所需的全球架构。跨企业沟通。什么是“边缘”或“边缘计算”？在我们考虑在边缘部署Kafka之前，让我们先了解与“边缘技术”相关的定义。维基百科说：“边缘计算是一种分布式计算范式。它通过使计算本身和数据存储更靠近所需位置来缩短响应时间并节省带宽。”同时，它的其他优点还包括：降低成本、增加系统灵活性和关注点分离。ApacheKafkaattheedge目前，业界对如何将Kafka应用到边缘计算上有不同的看法，包括：Onlyattheedgeclient：Kafka客户端运行在边缘；而Kafka集群部署在数据中心或公有云环境中。一切都在边缘：在边缘部署Kafka集群和Kafka客户端（例如工厂中的各种传感器）。Edgevs.Remote：Kafka集群部署在边缘；Kafka客户端（例如该地区的智能手机）靠近边缘运行。可以看出边缘的Kafka具有相对灵活和广泛的应用，包括：工业物联网（IIoT）车间边缘的Kafka客户端可以用C语言编写，部署到车间的微控制器上传感器中间。这种传感器通常只有几千字节的内存，并且可以“使用”一定年限。在电信业务的边缘，一个完整的分布式Kafka集群可以运行在StarlingX（https://www.starlingx.io/）上。StarlingX是一个基于Kubernetes的开源私有云架构栈，可用于工业物联网、电信、视频交付等对超低延迟等苛刻要求的应用边缘环境。通过部署，连接传统银行或保险公司的核心硬件和边缘硬件。可以看出，在大多数情况下，边缘的Kafka是指部署在系统边缘的Kafka集群。相应的Kafka客户端程序可以在本地或就近运行。当然，在某些情况下，“附近”可能意味着数英里之外。Kafka在边缘的用例让我们讨论在许多不同企业中运行的Kafka在边缘的用例。工业物联网：实时边缘集成和处理是现代物联网架构成功的关键。在工业4.0中，此类用例比比皆是，包括：预测性维护、质量保证、流程优化和网络安全。其中，使用Kafka构建数字孪生体（DigitalTwin，译者注：在虚拟空间中模拟、映射和反映相应物理设备的整个生命周期过程）是最常见的场景之一。零售：无论是沃尔玛这样的零售商，星巴克这样的咖啡店，还是AmazonGo这样的时尚商店，数字化转型都会带来很多方面的创新。其中包括：客户体验、商家与消费者之间的交叉销售，以及与其他合作供应商的协作。物流：大规模实时数据关联是改变任何物流场景的关键要素。其中包括：端到端的包裹跟踪和交付、无人机（或自动驾驶）与本地自助服务亭的通信、履行中心的加急处理、共享汽车的协调和调度，以及智慧城市的交通信号灯管理。无论使用上述哪一种用例，Kafka在边缘的总体架构如下图所示：边缘计算的挑战是当企业试图将各种创新的实时应用程序引入工厂、零售店、咖啡厅等，并将数据分发到边缘在部署站点时，经常会遇到以下挑战：边缘的各种硬件、机器和设备由于网络条件差等诸多限制，难以平滑集成。许多用例需要大规模的实时处理。而且这些过程必须在现场边缘执行，而不是在远程数据中心或数百英里外的云端执行。必须在边缘集成各种技术和协议。此外，各种传统或专有协议必须通过隧道才能与另一端的大数据工具进行通信。硬件资源和人员有限。出于成本考虑，IT专家无法到达每个边缘站点进行硬件运维。各种数据都必须在本地进行大规模实时存储和处理。同时，这些数据还需要复制到数据中心或云端进行进一步的聚合、处理和分析。另外，为了实现每个边缘站点由单个节点通过发送命令或事件来控制，各种通信最好是双向的。面向边缘计算的Kafka架构在开始讨论Kafka在边缘的部署方案之前，我们需要提前明确一个问题：是否需要高可用的边缘架构。事实上，边缘计算并不一定需要具备高可用性。如果确实需要，就部署一个传统的Kafka集群；如果没有，只需在边缘设置一个简单、低成本的KafkaBroker。如果需要部署在数百个站点，现成的硬件设备将更容易实施。下图显示了三个边缘站点。每个站点部署一个Kafka集群，每个集群包含不同的Kafka组件。通过三个以上的KafkaBrokers在边缘弹性部署Kafka及其生态系统，旨在确保即使单个节点出现故障，系统的高可用性和零停机时间。如下图所示，要部署一个分布式系统，至少需要三个Kafka节点和三个Zookeeper节点。其他组件至少需要两个节点来确保运行可靠性和数据丢失预防。您可以参考文章《Apache Kafka与Confluent平台参考架构》了解部署的最佳实践。当然，由于边缘的流量负载和吞吐量通常较低，如果SLA允许，较少的内存和磁盘空间可能就足够了。通过KafkaBroker在边缘进行非弹性部署如今，越来越需要在边缘部署“轻量级Kafka集群”，然后与更大的中央Kafka集群同步或复制数据。但是由于硬件本身的限制，以及SLA对高可用的要求不高，所以只能在边缘部署一个KafkaBroker加一个Zookeeper。如下图所示，你甚至可以只在一台服务器上部署整个Kafka环境。但是，这种部署方案有一个明显的缺陷：由于数据之间没有复制，如果节点或网络出现故障导致宕机，你的数据就有丢失的风险。当然，这种单节点的Kafka部署方案还是有以下优势的：实现了生产者和消费者的解耦。可以有效地处理背压。即使只有一个Broker，也能实时处理大容量数据。存储在磁盘上。重新处理数据的能力。可以使用KafkaConnect进行集成，可以使用KafkaStreams或者ksqlDB进行流处理，可以使用SchemaRegistry进行管理。堪称Kafka本地组件的“全家桶”。删除ZooKeeper将有助于边缘的Kafka。与Hadoop、Spark等其他分布式系统类似，由于过度依赖ZooKeeper，Kafka不仅运维困难，而且扩展性差。对于大多数物联网项目，由于整体部署时间较长，建议您去掉ZooKeeper，让Kafka更轻量、更易操作。使用Kafka作为边缘设备和云服务之间的网关在某些配置中，您可能希望边缘设备与本地网关进行通信。此时，可以使用网关式的Kafka架构方案。例如，在工厂中，多台机器或生产线被视为边缘设备。它们需要与各自的Kafka集群集成，作为网关向Kafka集群发送数据。相应地，在Kafka集群网关上，可以直接在本地进行分析、过滤或转换数据，最后发送并聚合到一个大型的远程Kafka集群中。如上图所示：首先，两个独立的工厂在各处部署了一个单一的非弹性KafkaBroker，实现数据的本地处理。然后通过一个弹性的Kafka集群网关聚合三个KafkaBrokers，在工厂本地处理各种数据。然后，只有那些重要的和经过预处理的数据才会被转发到远程Kafka集群（图中表示为ConfluentCloud）。最终，云中的Kafka集群聚合来自不同工厂的数据，以便与其他业务应用程序或分析工具集成。边缘的Kafka作为OEM或硬件组件企业，在边缘安装硬件会比本地数据中心或公有云更加复杂和麻烦。如果我们在边缘采用标准化的Kafka组件安装方式，工作量和潜在风险都会大大降低。目前，已有数十家硬件供应商可以协助您打造OEM硬件设备。当然，你也可以远程管理和使用一些DevOps工具来安装所有需要的软件组件。为了简化以Hivecell（https://hivecell.io/）为代表的Kafka集群在边缘的安装和运行，公司推出预装Kubernetes、Kafka生态系统、ConfluentOperator（https://www.confluent）.io/confluent-operator/)工具，以及其他业务应用程序的产品框。它简化并自动化了边缘Kafka环境中的操作。用户只需将一个或多个产品箱运送到边缘站点即可。将其连接到本地WiFi后，其他一切都可以远程完成。该公司甚至声称可以让客户在不需要技术人员的情况下在边缘部署和维护软件。通信、连接、集成和数据处理如上图所示，Kafka环境不仅仅包括KafkaBroker和Zookeeper。无论是在云端、本地还是边缘，通信、连接、集成和数据处理都是Kafka基础设施的重要组成部分。具体来说，KafkaBroker和Kafka客户端之间，从边缘到远端的通信过程是：设备->边缘的Kafka->复制->数据中心和云端的Kafka集群->数据分析和实时加工。通常，此类通信是双向的。然后，对于Kafka的每一个原生组件，你只需要管理一个Kafak后台就可以进行大规模的实时通信、集成和数据处理。涉及以下几个方面：KafkaConnect：包括MQTT（消息队列遥测传输）、OPC-UA、FTP、CSV、PLC4X（一套传统的、专有的IIoT协议，如Modbus、SiemensS7、Beckhoff、AllenBradley四种可编程程序控制器，或PLC）。Mirrormaker和ConfluentReplicator：实现两个Kafka集群之间的单向或双向复制。Kafka客户端（Producers/Consumers）：支持Java、Python、C++、C、Go、Javascript等语言。数据处理：使用KafkaStreams或ksqlDB进行流处理（包括用于无状态流和其他有状态应用程序的ETL）。代理：使用REST代理进行HTTP(S)通信，使用MQTT代理进行MQTT集成。ArchitectureRegistry：负责治理和架构实施。由此可见，由于边缘的硬件资源有限，我们应该在一开始就规划好整体架构和数据通信，这样Kafka全栈才能真正满足边缘的需求。混合架构物联网的实际需求往往是多种多样的。面对24小时/7天的实时部署、零数据丢失、实时处理无延迟，我们有时光靠Kafka架构是做不到我们想做的。此时，我们需要结合使用其他物联网框架或解决方案，实现与Kafka端到端的集成。如上图所示，我们可以在工厂车间使用西门子的MindSphere（功能强大、应用广泛，但也是复杂昂贵的物联网解决方案）作为网关或代理。当然，我们可以部署HiveMQ（译者注：Anenterprise-levelMQTTBroker）作为一个可扩展的MQTT集群来连接机器和设备。在某些情况下，Kafka也可以直接用作物联网网关或代理，连接到PLC或分布式控制系统(DCS)。同时，Kafka还可以连接到AWSIoT或GoogleCloud的MQTTBridge等物联网解决方案进行进一步的处理和分析。由于数据通信通常是双向的，无论选择哪种架构，都必须能够从车间或其他物联网设备中提取数据，实时处理和关联，最后将控制事件发送回机器。例如：在预测分析中，您首先需要使用TensorFlow等云工具训练分析模型，然后再将分析模型部署在边缘以进行实时预测。可以看出，通过与其他物联网框架或解决方案的结合，Kafka生态系统不仅得到了有效的补充，而且各自可以专注于不同的功能用例。例如：Kafka可以专注于设备管理和模型训练。主要的云提供商可以提供物联网服务、云代理和用于设备管理的分析工具。开源框架Eclipse可用于构建数字孪生。小心太多的分布式系统组合当然，如果你想为边缘计算和混合架构构建一个可扩展且可靠的流式结构，并达到不会造成任何宕机或数据丢失的效果，这实际上是很难实现的集成多个中间件工具的环境。也就是说：参与组合的工具越多，服务中断或数据丢失的风险就越高。例如：NiFi（译者注：Apache的NiFi项目是一个实时数据流处理系统）有自己的分布式基础设施，那么你必须保证从生产者到消费者通过NiFi和Kafka，整个过程有24小时/7天的端到端正常运行时间。同样，当KafkaConnect和KafkaStreams等原生工具使用KafkaTopic在后台提供高可用性时，您也需要保证这样的24/7不停机或数据丢失。因此，请使用“传感器ABC->NiFi（捕获）->KafkaTopicA->NiFi（转换）->KafkaTopicB->NiFi（加载）->应用XYZ”这样的流水线架构进行Large-scale实时处理，无数据丢失。总结边缘计算往往只是整个架构的一部分，但作为该领域的“黑马”，边缘的Kafka通过部署混合架构。更好的可扩展性、可靠性和健壮性。原标题：ApacheKafkaIstheNewBlackattheEdgeinIoTProjects，作者：KaiW?hner
