翻译|季凯策划|赵云ApacheKafka是处理流式数据的事实标准。随着它在各行各业的广泛应用，我经常听到一个很有趣的问题：什么时候不应该使用ApacheKafka？流式数据处理平台有哪些限制？Kafka在什么情况下不能胜任？这篇文章探讨了Kafka擅长什么，不擅长什么。并且单独的章节列出了什么时候Kafka适合，什么时候Kafka不适合，什么时候Kafka可以作为一个选项。首先，Kafka的广泛应用证明了它在流式事件处理领域有着巨大的市场需求。但也要注意：Kafka在流式事件处理领域并没有提供完整的解决方案。简而言之，Kafka不是灵丹妙药，而是流式事件处理领域的重要组成部分！当今世界，信息互联无处不在。这种不断增加的连接性会产生大量相互关联的实时数据。通过对这些数据的加工处理，企业可以有效降低成本和风险，增加企业收入。车联网和游戏是最典型的两个例子：车联网：大量收集的数据和售后服务以下是AlliedMarketResearch出品的2020-2027年全球机会分析和行业预测：Scenarios车联网领域涉及的行业比大多数人想象的要广泛得多，比如：网络基础设施、安防、娱乐、零售、售后市场、车险、智慧城市等场景。游戏行业：数十亿玩家和巨额收入正如Bitkraft所描述的那样，游戏行业已经比所有其他媒体类别的总和还要大，而这只是一个新时代的开始：全球每个月都有数百万新玩家加入游戏社区。生活在不太富裕国家的玩家现在可以负担得起智能手机和移动网络资费。而新的游戏商业模式，比如玩游戏赚钱，将改变下一代游戏玩家玩游戏的方式。5G等更具可扩展性和低延迟的技术支持新场景的出现。区块链和NFT（不可替代代币）正在永远改变货币格局和收藏品市场。这些趋势数据证实了对实时数据处理的需求不断增加。因此了解何时在项目中使用ApacheKafka及其生态系统变得很有价值，它已成为大规模数据处理分析和业务数据流的事实标准。ApacheKafka能做什么，不能做什么？一些开发人员经常会误解Kafka的功能。例如，将Kafka视为一个消息队列。这在很大程度上是由于一些供应商仅涵盖Kafka特定功能（例如将数据导入数据湖或数据仓库）以销售其产品。Kafka能做什么：一个可扩展的实时消息传递平台，每秒可以处理数百万条消息。面向海量大数据分析和少量业务数据处理的事件流平台，支持分布式存储，具有消息缓存功能，支持各种支持消息顺序重放的通信协议。一个用于流式ETL的数据集成框架，一个用于连续无状态或有状态流处理的数据处理框架，cheng'gong'di成功地将所有这些功能结合在一个平台上。Kafka做不到的：不是数百万客户端（如移动应用）的访问网关；但Kafka原生代理（如REST或MQTT）适用于某些场景不是接口管理平台，但这些工具通常是KafkaAPI创建、生命周期管理或货币化的补充，不是用于复杂查询和执行批处理分析的数据库；但能够进行业务查询和相对简单的聚合（尤其是使用ksqlDB），不是一个具备设备管理等功能的数据库物联网平台；但是，它可以直接与支持某些物联网协议（例如MQTT或OPC-UA）的设备集成，并且在某些场景中是推荐的做法。不是完全实时系统（如安全关键或确定性系统）的框架，但对于任何其他IT框架都是一样的，嵌入式系统毕竟是一种不同的软件。可见Kafka与其他技术是互补而非竞争的。因此，我们应该根据任务的特点选择是否使用Kafka，并结合其他框架使用！ApacheKafka在万物互联的世界里，Kafka与其他技术结合的成功例子很多。这些案例展示了Kafka是如何解决业务问题的。这里的重点是案例研究。事实上，对于端到端的数据流解决方案，Kafka往往需要与其他组件结合使用。在ApacheKafka的实时数据流方面，在车联网、物联网边缘计算、移动互联网游戏等领域已有大量大数据分析或业务数据处理的成功案例.这里我列举几个不同行业和场景的案例：奥迪：推出跨区域、跨云的供应商车联网平台宝马：高效物流和供应链的智能工厂太阳能：提供完整的太阳能解决方案和服务皇家加勒比：Cruise基于混合云部署的船舶娱乐系统，支持离线的边缘服务Disney+Hotstar：为数百万粉丝提供交互式媒体和智能手机上的游戏/游戏此类案例不断增加但是我们需要进一步说明何时使用事件流在ApacheKafka系统中以及如何与其他互补解决方案互补Kafka。什么时候使用ApacheKafka合适在讨论什么时候不使用Kafka之前，让我们了解什么时候应该使用Kafka以及如何用其他技术来补充Kafka。我将在每个部分中添加真实示例。这将使您更容易理解这些场景。1、通过Kafka实时处理物联网和移动大数据实时处理大数据是Kafka的关键能力之一。特斯拉不仅仅是一家汽车制造商。同样是一家科技公司，他开发了很多创新和尖端的软件。他们为汽车提供能源基础设施，包括特斯拉超级充电站、生产太阳能的超级工厂等等。特斯拉成功的关键技术之一是实时处理和分析来自汽车智能电网和工厂的数据，并与其他IT后端服务集成。特斯拉构建了基于Kafka的数据平台基础设施，支持百万级设备和万亿级数据埋点。2019年，特斯拉在卡夫卡峰会上展示了他们实时数据业务的演进：请注意，卡夫卡的作用不仅仅是信息传输。Kafka是真正实现生产者和消费者解耦的分布式存储层。此外，Kafka-native处理工具如KafkaStreams和ksqlDB支持实时处理。2、通过Kafka将物联网数据集成到MES、ERP等业务系统中。KafkaConnect等非Kafka中间件为大规模实时数据集成系统和业务系统（如ERP或MES系统）提供核心事件流功能。宝马在边缘节点（即智能工厂）和公共云上部署了执行重要任务的Kafka实例。制造业每停机一分钟都会损失大量资金，因此稳定性变得至关重要。与原生Kafka相比，Confluent的Kafka发行版在稳定性方面有了很大的提升。宝马通过供应链的实时优化和管理。在基于SAP的BMWERP等业务系统中实现正确实物库存的信息。我在这个领域接触过的客户中，近50%都在使用Kafka和SAP的集成。许多下一代ERP、MES平台除了与SAP集成外，还直接使用Kafka作为底层技术支持。3.通过Kafka将部署在边缘、混合云或多云的非物联网IT系统集成到企业系统中。在多个集群和跨数据中心部署ApacheKafka已成为常态。一些特定需求可能需要多集群解决方案，包括灾难恢复、聚合分析、云迁移、关键任务扩展部署和全球Kafka。不同协议之间的解耦是Kafka相对于其他消息平台（例如IBMMQ、RabbitMQ或MQTT代理）的独特优势。Kafka的领域驱动设计（DDD）也是一个值得详细探讨的方向。4.为跨行业应用提供现代基础设施，可通过Kafka基于混合云部署。在这方面，以Unity为例。公司为游戏提供实时3D开发平台，并凭借其AR/VR能力成功进入制造业等其他行业。2019年，这家数据驱动公司产品生成的内容已安装在全球30亿台设备上，安装量已达330亿。同时，Unity运营着世界上最大的盈利网络之一。他们的项目团队将平台从本地Kafka迁移到托管的ConfluentCloud，没有停机或数据丢失。5.Kafka为移动服务和游戏/赌博平台提供可扩展的实时后端许多游戏和移动服务依赖事件流作为其基础架构的支柱。用例包括用户行为分析、基于位置的服务、支付、欺诈检测、用户/玩家保留和用户粘性处理。几乎所有游戏和移动服务领域的应用都需要大规模的实时数据流。例如：移动服务：Uber、Lyft、FREENOW、Grab、Otonomo和HereTechnologies游戏服务：Disney+Hotstar、SonyPlaystation、Tencent、BigFishGaming游戏服务：WilliamHill、SkyGaming一个有趣的现象是：不是每个手机或游戏服务供应商都在公开谈论使用Kafka，但几乎每个人都在寻找Kafka专家来开发和运营他们的平台。这些场景与银行核心平台中的支付流程有着同样高的安全要求。合规性和零数据丢失也很关键。因此，利用Kafka多区域集群（如Kafka跨美东、美中、美西区域的集群）实现高可用，即使发生灾难，也不会宕机和数据丢失。游戏中多区域Kafka集群示例6.在车辆或物联网设备中嵌入单个Kafka实例边缘计算技术发展迅速。由于低延迟、成本效率、网络安全或无互联网连接等原因，某些场景需要将Kafka集群或实例部署在数据中心外的边缘。Kafka在边缘的示例包括在无法连接到中央服务器的运输过程中离线存储日志、传感器数据和图像（例如，街上的卡车或在船上飞行的无人机）。Vehicle-to-surrounding(V2X)通信场景，通过本地小型数据中心（如AWSOutposts）搭建MQTT网关，适用于大面积、大量车辆或网络不佳的场景，或者通过Kafka客户端直接连接上百台机器（例如在智能工厂中）等。离线移动服务，例如将汽车基础设施与地图集成，或将推荐引擎与合作伙伴集成以提供本地服务（例如，10英里内下一家麦当劳的优惠券）RoyalCaribbeanCruises是一个成功的故事。它经营着世界上四艘最大的游轮。截至2021年1月，该航线运营24艘船舶，另有6艘船舶在订购中。皇家加勒比在边缘端实施了最著名的Kafka场景之一。每艘游轮都有一个本地运行的Kafka集群，用于支付处理、用户粘性、客户推荐等。Kafka边缘部署要注意根据实际业务场景进行调整，以保证足够的低延迟性能。搁浅ApacheKafka从了解何时使用Kafka开始。这样才能明白Kafka不适合哪些场景。在本节中，我们假设我们讨论的是生产环境，而不是一些丑陋的解决方法，当您需要在全球范围内部署和扩展、遵守合规性并确保业务服务不会丢失数据时就是这种情况。会改变。考虑到这一点，排除Kafka的某些用例和问题相对容易：1.Kafka不是完全实时的。实时一词很难定义。这通常是一个营销术语。实时程序必须保证在指定的时间限制内响应。Kafka（以及在此上下文中使用的所有其他框架、产品和云服务）只是相对实时的，并且是为IT应用程序构建的。但是许多自动化控制和物联网应用程序需要完全实时且零延迟尖峰。实时的定义很难。这通常是一个营销术语。实时程序必须保证在指定的时间限制内响应。Kafka（以及在此上下文中使用的所有其他框架、产品和云服务）只是相对实时的，并且是为IT应用程序构建的。但是许多自动化控制和物联网应用程序需要完全实时且零延迟尖峰。Kafka是实时的，但不是完全实时的。相对实时通常用于以下应用程序：IT应用程序之间的点对点消息传递从各种数据源到聚合到一个或多个数据接收器数据处理和数据关联（通常称为事件流或事件流处理）如果应用程序需要亚毫秒级延迟，那么Kafka不是正确的技术。例如，高频交易通常是通过专门构建的专有业务解决方案实现的。永远记住：Kafka每次都在最低延迟的竞赛中失败，而最低延迟的最佳解决方案是根本不使用消息系统，而只使用共享内存。然而，没有什么数据丢失比延迟更重要，当涉及审计日志和业务日志或持久性引擎的交换部分时，Kafka胜出。事实上，大多数实时场景只需要毫秒到秒级的数据处理。在这种情况下，Kafka是一个完美的解决方案。许多金融科技公司，如Robinhood，都依赖Kafka进行关键业务工作甚至金融交易。多访问边缘计算(MEC)是使用ApacheKafka和云原生5G基础设施构建的低延迟数据流的另一个很好的例子。2.Kafka对于嵌入式和安全关键系统是确定性的。需要明确的是，Kafka不是一个确定性系统。它们不能用于安全关键型应用，例如汽车发动机控制系统、医疗系统（例如心脏起搏器）或工业过程控制器。Kafka不适用的典型场景如下：汽车或车辆中的安全关键数据处理，包括Autosar/MINRA/Assembler之间的CAN总线通信和类似技术ECU机器人：C/C++或类似的低级语言，带有工业ROS（机器人操作系统）结合安全关键型机器学习/深度学习（例如用于自动驾驶）车对车(V2V)通信：5Gsidelink不能使用类似Kafka的转发。安全相关的数据处理不是Kafka能够胜任的，必须使用专用的底层编程语言和解决方案来实现。同样，IBMMQ、Flink、Spark、Snowflake等类Kafka软件也不适用。3.Kafka不是为不稳定的网络构建的。Kafka要求客户端和实例之间有良好稳定的网络连接。因此，如果网络不稳定，导致客户端不断尝试重连，往往很难满足预先设定的SLA。有一些例外，例如由其他技术构建的用于解决不良网络问题的例外。MQTT就是最典型的例子。因此，Kafka和MQTT是朋友，不是敌人。这种组合功能强大，广泛应用于各个行业。因此，我写了一系列关于Kafka和MQTT的博客。例如，我们使用MQTT、Kafka和TensorFlow构建了Kappa架构的车联网基础设施，可以处理100,000个数据流进行实时预测。4.Kafka不提供连接数以万计的客户端。将Kafka定义为集成解决方案的另一个具体点是Kafka无法连接数万个客户端。如果您需要为移动游戏玩家构建连接的汽车基础设施或游戏平台，客户端（即汽车或智能手机）将通过Kafka集成解决方案连接，而不是直接连接到Kafka。一般来说，千千客户端和Kafka之间会增加一个专门的代理（比如HTTP网关或者MQTT代理），负责客户端和Kafka之间的连接，数据最终会被整合到数据仓库，数据湖或者由Kafka终端应用程序定制。Kafka客户端连接的限制在哪里？通常，很难说。我看到客户通过.net从工厂车间直接连接，并通过JavaKafka客户端直接连接到运行Kafka集群的云。如果机器PLC、IoT网关和IoT设备的数量为数百，则直接混合连接通常效果很好。对于更多的客户端应用，开发者需要评估以下问题：中间是否需要broker，是否需要在边缘部署Kafka来减少延迟，提高经济性？什么时候可以使用ApacheKafka？以下是一些可以选择Kafka的场景：1.Kafka（通常）不会替代另一个数据库。ApacheKafka本身是一个提供ACID保证的数据库，被数百家公司用于关键任务部署。然而，在大多数情况下，Kafka与其他数据库没有竞争力。Kafka是一个事件流平台，用于实时大规模地进行消息传递、存储、处理和集成，并保证不会停机或数据丢失。Kafka通常用作流数据集成层。然后根据应用场景选择其他数据库作为实体视图，例如实时时间序列分析，近实时将文本导入搜索基础设施，以及通过数据湖长期存储数据。综上所述，当你被问及Kafka是否可以替代数据库时，你可以这样回答：Kafka可以持久、高可用的方式永久存储数据，提供ACID保证。Kafka提供了多种查询历史数据的方式。Kafka原生的插件，如ksqlDB或分层存储，为Kafka提供了强大的数据处理和基于事件的长期存储能力。利用Kafka构建有状态应用程序，无需额外的外部数据库。不替代现有的数据库、数据仓库或数据湖，如MySQL、MongoDB、Elasticsearch、Hadoop、Snowflake、GoogleBigQuery等。其他类型的数据库通常是Kafka的补充，通常用于创建和更新实体视图的实时数据经常来自活动中心。Kafka与数据库之间的数据同步，基于双向pull和push集成，有不同的选择，可以相互补充。2.Kafka（通常）不处理大消息Kafka不是为大消息设计的。但是越来越多的项目通过Kafka发送和处理1MB、10MB甚至更大的文件或其他大型消息体。原因之一是Kafka是为高容量/吞吐量而设计的，这是大型消息所必需的。经常出现的一个非常常见的用法是使用Kafka从遗留系统中摄取和处理大文件。并将处理后的数据存储在数据仓库中。然而，并不是所有的大消息都适合用Kafka处理。通常，您应该使用正确的存储系统并仅利用Kafka进行编排。基于引用的消息传递（即将文件存储在存储系统中并仅发送链接和元数据）通常是更好的设计模式：了解不同的设计模式并为其选择正确的技术。有关使用Kafka处理大文件的更多详细信息和场景，请参阅以下博客文章：《使用Apache Kafka处理大型消息（CSV、XML、图像、视频、音频、文件）》。3.Kafka（通常）不作为物联网工业协议的最后一英里集成物联网设备和移动应用程序的最后一英里集成是一个棘手的问题。如上所述，Kafka无法连接到数千个客户端。然而，许多物联网和移动应用程序只有数十或数百个客户端。在这种情况下，您几乎可以使用世界上任何一种编程语言来为各种Kafka客户端提供支持，直接连接到Kafka实例。如果在TCP协议层面出现无法与Kafka服务器建立连接的情况。一个非常流行的解决方案是通过REST代理充当客户端和Kafka集群之间的代理。客户端通过同步HTTP(S)协议与REST代理通信。ApacheKafka的HTTP和RESTAPI场景包括控制平面（=管理）、数据平面（=生产和消费消息）和DevOps自动化任务。不幸的是，许多物联网项目需要更复杂的集成。此处无法讨论通过MQTT或OPC-UA连接器进行的相对简单的集成。IIoT项目面临的挑战包括：自动化行业通常不使用开放标准，而是使用缓慢、不安全且不可扩展的专有标准。产品的生命周期很长（几十年），没有简单的方法可以更改或升级。物联网经常使用不兼容的协议，这些协议通常是某个特定供应商专有的。不可扩展和不可扩展的、专有的和昂贵的整体。因此，许多IoT项目通过专门构建的IoT平台来补充Kafka。大多数物联网产品和云服务都是专有的，但提供开放的接口和架构。这个行业的开源项目相对较少。一个好的解决方案（对于某些场景）是ApachePLC4X。该框架集成了许多传统的专有协议，例如SiemensS7、Modbus、AllenBradley、BeckhoffADS等。PLC4X还提供了一个KafkaConnect连接器，用于本地和可扩展的Kafka集成。现代数据记录系统是开放和灵活的。许多基于混合云的现代物联网项目都是由事件流驱动的：4.Kafka和区块链Kafka不是区块链（但与web3、加密交易、NFT、off-chain、sidechain、oracle相关）。Kafka是一个分布式日志提交系统。这些概念和基础与区块链非常相似。对于大多数企业项目，区块链增加了不必要的复杂性。在这种情况下，分布式提交日志（=Kafka）或防篡改分布式分类帐（=增强型Kafka）就足够了。仅当不同的不受信任方需要协作时才应使用区块链。有趣的是，越来越多的公司在他们的加密货币交易平台、市场交易所和代币交易市场中使用Kafka。需要明确的是：Kafka不用于在这些平台上形成区块链。区块链是一种像比特币这样的加密货币，或者像以太坊这样提供智能合约的平台，人们可以在其中为游戏或艺术行业构建新的分布式应用程序(dApp)，例如NFT。Kafka是将这些区块链与其他预言机（=非区块链应用程序）连接起来的流媒体平台，例如CRM、数据湖、数据仓库等。TokenAnalyst是一个典型的例子，它使用Kafka将比特币/以太坊区块链数据与他们的分析工具。KafkaStreams提供了一个有状态的流应用程序，以防止在下游聚合计算中使用无效块。例如，TokenAnalyst开发了一个块验证器组件，它通过临时保留块并仅在达到大量确认（挖掘该块的子块）阈值时传播来解决重组场景。在一些高级场景下，由于原有区块链的可扩展性不够好（区块链称为链上数据），所以使用Kafka来实现侧链或链下平台。比特币并不是唯一一个每秒处理个位数交易的问题（！）。大多数现代区块链解决方案的性能无法扩展到Kafka的处理速度。测量分布式网络中区块链基础设施和物联网组件的健康状况，避免停机，保护基础设施，并使区块链数据可访问，无论是去中心化的自治组织还是蓝筹公司都必不可少。Kafka提供了一种无代理且可扩展的方式来向相关方呈现数据，并确保在节点丢失之前将相关数据暴露给正确的团队。这与Helium等尖端Web3IoT项目或R3Corda等更简单的封闭式分布式账本(DLT)相关。我最近发表了一篇关于事件流和Kafka改变零售虚拟世界中的实时商务的文章，展示了零售和游戏行业如何连接虚拟和物理事物。零售业务流程和客户沟通实时发生；无论您想为收藏品或视频游戏出售衣服、智能手机还是基于区块链的NFT代币。写在最后的总结中，Kafka不能替代数据库或数据仓库，也不适合完全实时的安全关键嵌入式服务、不稳定网络中成千上万客户端的代理、API管理解决方案、物联网网关，更不用说区块链了.对于某些场景和需求，很容易排除Kafka。但是，几乎所有行业都使用Kafka进行分析和业务工作。它是无处不在的事件流的事实标准。因此，Kafka经常与其他技术结合使用。原文链接：https://dzone.com/articles/when-not-to-use-apache-kafka译者介绍季凯，51CTO社区编辑，18年软件开发经验。现为阿里云全球培训中心讲师，负责云计算、云原生、数字化转型等领域的课程设计与授课。曾就职于富士通、联想集团、欢乐时光、搜狗，手机YY第一架构师。2014年开始从事专业技术培训和咨询工作。
