卡夫卡分布图
发布者：:Bilgin Ibryam inDevOps June 15th, 2022 0 Views
Apache Kafka有一个方面使其优于其他事件流项目，这不是它的技术特点和性能特征，而是围绕它的生态系统。构成Kafka版图的书籍、课程、会议讲座、Kafka服务提供商、咨询公司、独立专业人士、第三方工具和开发者库的数量是其他竞争项目无法比拟的。
虽然这使得Kafka成为事件流的事实标准，并为其在未来很长一段时间内的存在提供了保证，但与此同时，Kafka本身只是一个齿轮，并不能独立解决业务问题。这就提出了一个问题：哪种Kafka发行版最适合我们的用例，哪种生态系统能使我们的开发团队和组织约束获得最高的生产力。在这篇文章中，我们将尝试浏览不断增长的Kafka发行版的生态系统，并给你一些关于行业发展方向的想法。
用于本地开发的Kafka
如果你是Kafka的新手，你可能会认为你只需要一个Kafka集群，就可以了。虽然这种说法对于Kafka应用水平较低的组织来说可能是正确的，因为Kafka是一种通用的消息传递基础设施，但对于事件流应用水平较高的组织来说，这并不代表他们的情况，因为Kafka被多个团队在多个复杂场景中大量使用。后者需要开发者生产力工具，在事件驱动的应用开发过程中提供快速反馈，高水平的自动化，以及在较低环境中的可重复性，并根据业务专家的要求，在生产中提供从边缘到多个云的各种混合部署机制。
一个大量使用流处理应用程序的开发团队最希望的是能够在他们的笔记本电脑上快速启动一个短暂的Kafka。不管你是实行测试驱动开发和模拟所有的外部依赖，还是采用快速原型技术，都是如此。作为一个开发者，我想快速验证我的应用程序与内存数据库或消息传递系统的连接和运行是否正常。然后，我希望能够与真正的Kafka代理进行可重复的集成测试。有了这种快速的反馈周期，开发人员就可以更快地迭代和交付功能，并适应不断变化的需求。好消息是，有一些项目正在解决这一需求。我最熟悉的是Kafka的Quarkus扩展和Java生态系统中Spring的EmbeddedKafka。对Kafka应用进行单元测试的最简单方法是使用smallrye-messaging，它用内存连接取代了通道的实现。这与Kafka无关，但说明了使用正确的流媒体抽象库可以帮助你快速进行单元测试。另一个选择是通过EmbeddedKafkaCluster在与测试资源相同的进程中启动一个内存中的Kafka集群，用它来进行快速的集成测试。如果你想启动一个真正的Kafka代理作为资源的一部分的独立进程，Quarkus可以通过Dev Services for Kafka做到这一点。通过这个机制，Quarkus会在一秒钟之内使用容器启动一个Kafka集群。这个机制可以验证你的应用程序的Kafka特定方面，并确保它在本地机器上按预期工作。Dev Services最酷的地方在于它还可以启动模式注册表（如Apicurio）、关系型数据库、缓存和其他许多第三方服务依赖。一旦你完成了 "内循环 "的开发步骤，你要把你的应用程序提交给源码控制系统，并在中央构建系统上运行一些集成测试。你可以使用测试容器从Java DSL（或C语言的librdkafka mock）启动Kafka代理，并允许你挑选特定的Kafka发行版和版本。如果你的应用程序通过了所有的关卡，那么它就可以部署到与其他服务共享的环境中，在那里需要一个持续运行的Kafka集群。
在这篇文章中，我们只关注Kafka代理发行版，而不是完整的Kafka生态系统的工具和附加组件。还有其他的监控和管理工具，以及帮助开发者和运营团队进行日常活动的服务，这些我们留到另一篇文章中讨论。
自我管理的Kafka
由于我们的应用程序还没有达到生产或性能测试环境，需要类似生产的特性，我们想要的是有一个足够可靠的Kafka安装，让不同的团队整合和运行一些测试，而不涉及大量的管理努力。这种环境的另一个特点是成本低，没有数据复制和多AZ部署的成本开销。许多组织都有Kubernetes环境，每个开发团队都有自己的隔离命名空间和共享命名空间，用于CI/CD目的，并部署所有共享的依赖。Strimzi项目--最初由Red Hat创建，拥有为开发和生产目的在Kubernetes上自动运行Kafka集群所需的一切。在下层环境中使用Strimzi的好处是，它可以通过声明式的Kubernetes API进行管理，开发人员可以用它来管理他们开发的应用程序和其他第3方依赖。这允许开发人员使用相同的Kubernetes基础设施，快速创建一个Kafka集群，供个人或团队使用，一个临时的项目集群，或一个更长久的共享集群，反复通过自动化管道和流程，而不去依赖其他团队来批准和提供新的服务。
Apache Kafka分布和使用案例列表
自我管理的Kafka集群不仅用于开发目的，而且也用于生产。一旦你接近生产环境，对Kafka部署的特性要求就会发生巨大的变化。你希望能够为应用性能测试和DR测试场景提供类似生产的Kafka集群。生产环境通常也不是一个单一的Kafka集群，它可以是多个为不同目的优化的集群。你可能想要一个自我管理的Kafka集群来部署在你的边缘集群上，这些集群是离线运行的，内部基础设施可能需要一个非标准的拓扑结构或公共云，具有相当标准的多AZ部署。而且有很多来自Red Hat、Confluent、Cloudera、TIBCO的自管理Kafka平台，仅举几例。自主管理集群的主要特点是，管理和运行Kafka集群的责任在拥有该集群的组织内。有了这个，自我管理的集群还允许对Kafka集群进行定制和配置，定制调整以适应你的部署需求。对于这些以及其他任何Kafka作为服务模式无法实现的奇怪用例，自我管理的Kafka仍然是一条成熟的道路。
Kafka作为一种服务
每个组织都是不同的，但生产型Kafka集群的一些共同标准是：能够在多个AZ上部署、按需扩展、合规性和认证、可预测的成本模式、对第三方工具和服务的集成开放等等。今天，Kafka已经有十多年的历史了，有多种成熟的Kafka即服务的产品能够满足许多生产需求。虽然这些产品在尺寸选择、用户界面的丰富性、Kafka生态系统组件等方面有所不同，但一个关键的区别是，Kafka是被当作一个基础设施组件，还是被当作自己的事件流类别及其事件流的抽象。
Apache Kafka分布图
基于抽象标准，我们可以看到一些SaaS供应商（如AWS MSK、Heroku、Instaclustr、Aiven）关注基础设施细节，如虚拟机大小、核心和内存数量、存储类型、经纪人、Zookeeper、Kafka连接细节等等。关于基础设施的选择、与Kafka的容量匹配、Kafka集群配置、Zookeeper拓扑结构等许多关键决定都留给了用户来决定。这些服务类似于在上面运行Kafka的基础设施服务，这反映在基于虚拟机的大小和定价模型中。这些服务有更多的规模选择，并且可以被那些有基础设施倾向和偏好的团队所青睐，以了解和控制服务的所有方面（甚至是管理服务）。
其他Kafka即服务的供应商（如Confluent Cloud、AWS MSK Serverless、Red Hat Openshift Streams for Apache Kafka、Upstash）走的是 "Kafka优先 "的相反方向，其中的基础设施、管理层（通常基于Kubernetes）和Kafka集群的细节都得到了处理，而且是隐藏的。有了这些服务，用户面对的是更高层次的、以Kafka为中心的抽象概念，如类似于流/Kafka/主题的计量单位（代表规范化的多维Kafka容量）而不是基础设施容量；可用性保证而不是经纪人和Zookeeper的部署拓扑；作为API的外部系统连接器（无论实施技术如何）而不是Kafka Connect集群部署和连接器部署。这种方法暴露了对Kafka用户来说重要的东西，而不是构成Kafka服务的底层基础设施或实施选择。此外，这些Kafka优先的服务提供了一个基于消费的以Kafka为中心的定价模型，用户为使用的Kafka容量和服务质量付费，而不是用额外的Kafka保证金来配置基础设施。这些服务更适合专注于业务领域的业务线团队，并将Kafka作为解决业务挑战的商品工具。
接下来，我们将看到为什么Kafka优先的管理服务正在模糊界限，越来越接近于无服务器的Kafka体验，在这种情况下，用户正在与Kafka API进行交互，其他一切都被照顾到了。
"无服务器 "的Kafka
无服务器技术是一类SaaS，具有为用户提供额外好处的具体特点，如按使用付费的定价模式，以及完全消除对容量管理和扩展的需求。这是通过诸如不必配置和管理服务器、内置高可用性、内置再平衡、自动扩容和缩减到零来实现的。
我们可以从两个相反的角度来看待 "无服务器Kafka "这个类别。从正面看，我们可以说，除了价格方面，"Kafka优先 "的服务已经相当接近于无服务器的用户体验了。通过这些Kafka-first服务，用户不需要配置基础设施，Kafka集群已经预先配置了高可用性，有分区再平衡、存储扩展和自动扩展（在一定范围内）。
在消极方面，无论Kafka服务是否被称为无服务器，这些产品仍然有很大的技术和价格限制，它们还不够成熟。这些服务在消息大小、分区数量、分区限制、网络限制、存储限制方面都受到限制。这些约束限制了所谓的无服务器Kafka的使用案例。除了Upstash按消息收费外，其余的无服务器Kafka服务都是按集群时间收费的，这与无服务器定义中的scale-to-zero/pay-per-use精神相悖。
这就是为什么今天我认为无服务器Kafka类别仍然是一种激励，而不是现实。尽管如此，这些趋势为管理型Kafka产品指明了方向：即向用户隐藏完整的基础设施和部署抽象；以Kafka为基础的容量、使用和服务质量；不需要用户干预的自主服务生命周期；以及真正的按使用量付费的定价模式。
总结
你需要多少种Kafka？答案是多于一种。你需要能够在本地模拟Kafka的开发者框架，并实现快速迭代开发。你想要一个声明性的、自动化的方式来反复部署和更新开发环境。根据你的业务需求，你可能需要在边缘高度定制的Kafka实现，或者在多个云端都连接的标准实现。当你的组织的事件流采用和Kafka成熟度增长时，你将需要更多的Kafka。但是有一个悖论。如果你不从事Kafka业务，你应该减少对Kafka本身的工作，而将Kafka用于更多的任务，使你的业务与众不同。如果你通过像Strimzi这样的更高层次的框架来使用Kafka，将许多操作环节自动化，或者通过Kafka优先的服务来处理低层次的决策，将你从运行Kafka的责任中解脱出来，这都是可能的。这样一来，你的团队就不会再考虑Kafka的问题，而是开始考虑如何将Kafka用于对你的客户来说重要的事情。
由我们JCG项目的合伙人Bilgin Ibryam授权发表在Java Code Geeks上。点击这里查看原文。Kafka分布图 Java Code Geeks撰稿人所表达的观点仅代表其本人。 |
2022-06-15
