在边缘处部署Kafka的用例与架构 (在边缘处部署的英文)

教程大全 2025-07-15 11:01:03 浏览次

在边缘处部署Kafka的用例与架构

译文2020-11-17 09:00:00本文通过介绍边缘处Kafka的用例与架构，帮助您更好地了解如何在各个行业中，利用事件流和工具来构建从边缘到云端的物联网架构。

【51CTO.com快译】如今，在IoT(物联网)的边缘处，使用Apache Kafka来进行事件流传输，已不再是什么高深的技术了。作为一种通用的方法，Kafka在边缘处提供了与云端、以及数据中心，相同的开放、灵活且可扩展的架构。它是横跨IoT和非IoT(如：传统数据中心和云端基础架构)的流式神经系统的基本组件。实际上，Kafka可以被部署在零售商店、手机信号塔、火车、小型工厂、以及饭店等各种边缘位置。

本文将重点向您介绍Kafka客户和Kafka代理(brokers)在跨行业边缘处的用例与架构，其中包括边缘的处理、集成、去耦、低延迟、以及经济高效的数据处理。

Kafka在边缘的类别和体系架构

大多数物联网项目的构建，都与在数据中心或云端的普通Kafka项目有着本质的区别。它们无法提供可靠的Kafka集群，以及在云端建立稳定的网络连接，而具有如下的边缘功能：

边缘处Kafka的用例

总的说来，Kafka在边缘处的体系架构和部署场景会包括：数据集成，预处理，云端复制，边缘大(小)数据的处理和分析，连接中断时的脱机方案，具有数百个点位的极低硬件空间占用率方案，以及非高可用性的方案等。下面，我们来看几个典型行业的应用：

我们曾经为一个零售快餐连锁品牌–Chic-fil-A，部署了针对边缘计算的相关服务。我们在其2000家餐厅中都部署了KuberNetes集群(请参见–，以便在没有互联网连接的情况下，仍然可以凭借着边缘计算实现实时的分析(请参见–。下图是他们的硬件边缘设备，外观体积非常小，内部配置了Intel四核处理器、8 GB RAM和SSD。

边缘架构示例：运输和物流行业的Kafka

让我们通过一个铁路公司的特定案例，来具体讨论边缘处的Kafka混合方案。该方案利用离线式边缘处理，实现了客户通信，云端复制分析，以及与第三方合作伙伴的接口和API相集成。虽然这是一个铁路和运输行业的例子，但是我们可以轻松地将其映射到其他的行业中。

混合架构—从边缘到云端

设想，一列火车正在边缘处对产生的信息进行局部处理。如果有互联网连接和免费的网络资源，那么这列火车会将相关的数据实时复制到云端。而如果火车在行进中失去网络连接，那么Kafka将处理背压，并在网络连接恢复时将数据复制到云端。下图是在边缘和云端用到的Kafka混合架构：

Kafka在边缘处的事件流

如下图所示，火车在边缘处使用Apache Kafka，实现对实时消息/事件流的传递和背压处理。

在掉线/离线场景中使用Kafka

火车在驶过隧道或到达没有网线连接的区域时，就会出现离线的情况。此时，我们需要火车上的边缘设备仍然可以进行本地处理。毕竟，业务连续性是改善客户体验和增加销售量的关键因素。即使火车处于离线，乘客仍然需要通过移动应用，来查看时刻表信息，在餐厅购买食物，或在火车的本地服务器上观看电影。同时，一旦火车重建互联网连接，乘客的购买交易将会被转移到云端的用户忠诚度系统中，需要查询的最新消息也会从云端被传递(consume)过来，并存储在火车的边缘–Kafka代理处。下图展示了Kafka在离线和断开连接的模式下，如何在边缘处进行数据处理。

跨公司的Kafka和边缘整合

由于数据处理会在边缘(如：火车)和云端系统(如：CRM、忠诚度系统等)之间的整合系统中持续发生，因此不同的合作伙伴也要进行此类整合。与通过非扩展性的同步REST API调用/API管理，进行合作伙伴间的整合相比，使用Kafka原生的事件流复制机制，是一种更好、更具可扩展性的方法。下图展示了合作伙伴之间如何进行跨公司的Kafka复制与API管理。

在边缘部署Kafka的基础架构和硬件要求

下面我们来讨论如何在边缘处部署Kafka。注意，Kafka需要目标系统具有一定的计算能力。这取决于您正在使用的：硬件供应商、基础架构、特定的SLA、以及高可用性要求等诸多因素。值得庆幸的是，Kafka可以被部署在包括裸金属(bare metal)、虚拟机、容器、Kubernetes在内的许多基础架构中。而当前厂商能够生产的、可被用在边缘处的最小芯片通常具有4GB、8GB、甚至16GB的RAM。

在实际应用中，运行Kafka所需的最低硬件配置为：单核处理器 + 几个100MB的RAM。该配置已经能够让单个Kafka节点(复制因子 = 1)以超过100Mb/sec的吞吐量进行边缘处理了。当然，实际数值也会取决于分区的数量、消息的大小、网络的速度等各方面的因素。这与数据中心或云端的性能和可扩展性肯定是没法比的。

所以说，您可以将Kafka代理部署在树莓派(Raspberry Pi)上，但不能部署到小型嵌入式设备上，毕竟我们可以在设备上运行Kafka客户端。

在边缘处部署Kafka的“Confluent Way(融合方式)”

从技术角度来看，在边缘处部署Kafka与在数据中心或云端比较类似，只是环境和要求有所不同。而且一些附加的功能还会方便我们部署和操作Kafka。下面，让我们来了解一下Confluent部署方式的创新与差异化功能：

1. Confluent服务器包含了Kafka代理和各种增强型功能，其中包括：自平衡群集、分层存储、嵌入式REST API、服务器端模式验证等。它可以被部署为单个节点(非常轻便，但不具备高可用性)或群集模式(主要针对依赖于边缘处高可用性的关键任务负载)。

2. 虽然目前该方式仍需要ZooKeeper作为附加组件，以实现协同工作，但是预计2021年将不再需要。届时，它将是一个由Kafka支持的、独立且单流程化的边缘解决方案。

3. 群集链接(Cluster Linking，请参见–允许所有小的Kafka边缘站点使用Kafka协议，连接到数据中心或云端更大的Kafka群集中，而无需使用诸如Confluent Replicator或MirrorMaker等其他工具与架构。据此，开发人员可以大幅减少在基础架构上的成本与工作量。

4. 使用Confluent的工具集，来进行监控和主动支持(Proactive Support，请参见–。例如，一个控制中心可以监控几个不同的远程Kafka群集。受监控的目标不仅包括技术架构，还包括应用程序，以及端到端的集成。而Confluent Telemetry Reporter(请参见–则会从边缘站点收集相关的数据。

5. 目前，Kubernetes(MicroK8s Kubernetes发行版，请参见–正在成为许多边缘部署的首选编排平台。Confluent Operator恰好能以CRD(自定义资源定义，的方式，提供了对边缘处单一代理、或群集部署的滚动升级、以及安全自动化等操作功能。前文提到的Chic-fil-A其在2000多家快餐店中运行着Kubernetes(请参见–，并提供各项低延迟的边缘服务，恰恰是Confluent Operator在Confluent Cloud和数据中心内Confluent Platform上进行大型实际部署的成功案例。当然，Kubernetes是按需选用的。有些边缘处在使用了Kubernetes后，反而增加了复杂性，以及对于有限资源的耗费。

6. 由于数据集成和数据处理是边缘计算的关键，Confluent提供了用于新旧系统的连接器，其中包括针对PLC、OPC-UA和IIoT集成的PLC4X(请参见–、数据库CDC的连接器、MQ与MQTT的集成、云端连接器、以及用于高安全性或“肮环境”中的单向UDP网络的Data Diode连接器(请参见–。当然，Kafka Streams和ksqlDB则允许轻量级且功能强大的事件流处理。

7. 轻量级边缘客户端(如：嵌入式设备)可以利用Kafka和REST代理的C与C++客户端上的API(请参见–，通过HTTP(S)与任何编程语言进行通信。这对于许多计算能力有限的低功率边缘设备来说是非常重要的。毕竟，我们在这些设备中无法部署Java、或类似的“资源密集型(resource-hungry)技术”。

8. 您也可以选择将已认证的、预配置的OEM硬件放置在边缘处，将其连接到LAN或WiFi上，然后使用由硬件商提供的远程软件，对基础架构进行管理和监控。“在Hivecell上进行可行性处理”的视频(请参见–展示了如何通过Kafka集群、Kafka Streams应用、以及用于图像识别的嵌入式机器学习模型，进行边缘分析。

小结

作为绝佳的边缘解决方案，Kafka使您能够在边缘处、数据中心和云端，部署同样开放、可靠、且可扩展的技术。希望上述介绍的有关边缘处Kafka的用例与架构，能够帮助您更好地了解如何在各个行业中，利用事件流和工具来构建从边缘到云端的物联网架构。

SD-WAN网络一般由什么组件构成？

SD-WAN 技术使用软件定义网络 (SDN) 的原理，将控制平面和数据平面分开。基于此原则，SD-WAN 部署通常由以下两个组件组成：

管理员用来集中配置 WAN 拓扑和定义流量路径规则的控制器。

SD-WAN 边缘设备（物理或虚拟）驻留在每个站点并充当 SD-WAN 结构的连接和终止点。

本节介绍两种不同类型的 SD-WAN 架构：

类型 1（分支机构和总部部署）— 在每个分支机构站点，组织可以部署一个或多个 SD-WAN 边缘设备并将它们连接起来以形成 SD-WAN 结构或 SD-WAN 覆盖。管理员使用基于云或组织内部的 SD-WAN 控制器来管理和配置这些边缘设备，并在每个站点定义流量转发策略。

类型 2（分支机构、总部和区域数据中心部署）— 此架构在区域数据中心添加 SD-WAN 设备，以及在每个分支机构和总部站点添加 SD-WAN 设备。这些区域数据中心可以是公共或私有云环境。区域数据中心的 SD-WAN 设备聚合该区域较小站点的网络流量。当有多个区域分支机构站点的 Internet 连接带宽较低时，组织会使用此部署。