Spring Cloud Stream会生成不必要的复杂Kafka拓扑，为什么？

Question

我有一个带有一系列KStreams，联接和其他操作的KStream应用程序。我启用了logging.level.org.springframework.kafka.config=debug来验证正在生成的拓扑，并发现了许多根本没有意义的节点。

然后我将应用程序简化为：

interface ShippingKStreamProcessor {

    @Input("input")
    fun input(): KStream<Int, Customer>

}

@Suppress("UNCHECKED_CAST")
@Configuration
class ShippingKStreamConfiguration {

    @StreamListener
    fun process(@Input("input") input: KStream<Int, Customer> {}

}

奇怪的是，如此简单的KStream声明会生成这种复杂的拓扑：

2019-04-30 23:47:03.881 DEBUG 2944 --- [           main] o.s.k.config.StreamsBuilderFactoryBean   : Topologies:
   Sub-topology: 0
    Source: KSTREAM-SOURCE-0000000000 (topics: [customer])
      --> KSTREAM-MAPVALUES-0000000001
    Processor: KSTREAM-MAPVALUES-0000000001 (stores: [])
      --> KSTREAM-BRANCH-0000000003, KSTREAM-PROCESSOR-0000000002
      <-- KSTREAM-SOURCE-0000000000
    Processor: KSTREAM-BRANCH-0000000003 (stores: [])
      --> KSTREAM-BRANCHCHILD-0000000004, KSTREAM-BRANCHCHILD-0000000005
      <-- KSTREAM-MAPVALUES-0000000001
    Processor: KSTREAM-BRANCHCHILD-0000000004 (stores: [])
      --> KSTREAM-MAPVALUES-0000000007
      <-- KSTREAM-BRANCH-0000000003
    Processor: KSTREAM-BRANCHCHILD-0000000005 (stores: [])
      --> KSTREAM-PROCESSOR-0000000006
      <-- KSTREAM-BRANCH-0000000003
    Processor: KSTREAM-MAPVALUES-0000000007 (stores: [])
      --> none
      <-- KSTREAM-BRANCHCHILD-0000000004
    Processor: KSTREAM-PROCESSOR-0000000002 (stores: [])
      --> none
      <-- KSTREAM-MAPVALUES-0000000001
    Processor: KSTREAM-PROCESSOR-0000000006 (stores: [])
      --> none
      <-- KSTREAM-BRANCHCHILD-0000000005

本机Kafka应用程序中的相同简单流产生了更合理的拓扑：

fun main(args: Array<String>) {

    val builder = StreamsBuilder()

    val streamsConfiguration = Properties()
    streamsConfiguration[StreamsConfig.APPLICATION_ID_CONFIG] = "kafka-shipping-service"
    streamsConfiguration[StreamsConfig.BOOTSTRAP_SERVERS_CONFIG] = "http://localhost:9092"
    streamsConfiguration[AbstractKafkaAvroSerDeConfig.SCHEMA_REGISTRY_URL_CONFIG] = "http://localhost:8081"

    val serdeConfig = mapOf(
        AbstractKafkaAvroSerDeConfig.SCHEMA_REGISTRY_URL_CONFIG to "http://localhost:8081",
        AbstractKafkaAvroSerDeConfig.VALUE_SUBJECT_NAME_STRATEGY to TopicRecordNameStrategy::class.java.name
    )

    //val byteArraySerde = Serdes.ByteArray()
    val intSerde = Serdes.IntegerSerde()
    val customerSerde = SpecificAvroSerde<Customer>()
    customerSerde.configure(serdeConfig, false)

    val customerStream = builder.stream<Int, Customer>("customer",
        Consumed.with(intSerde, customerSerde)) as KStream<Int, Customer>

    val topology = builder.build()
    println(topology.describe())

    val streams = KafkaStreams(topology, streamsConfiguration)
    streams.start()
}

拓扑：

Topologies:
   Sub-topology: 0
    Source: KSTREAM-SOURCE-0000000000 (topics: [customer])
      --> none

Spring Cloud Stream生成如此复杂的拓扑的原因是什么？

Answer 1

@codependent之所以在拓扑中具有这些额外的处理器，是因为您正在使用框架提供的de / serailzers（本机解码和编码默认为false）。基本上，我们以byte[]的形式接收来自Kafka主题的数据，然后在内部进行转换。对于这些转换，我们将使用一些额外的处理器，因此您将获得更深的拓扑。

这是Java中的基本StreamListener（您所拥有的差不多，但是使用了更简单的值类型）：

@StreamListener
public void process(@Input("input") KStream<Integer, String> input ) {

}

有了活页夹中标准的开箱即用设置，我能够获得与您观察到的相同的更深拓扑。但是，当我如下图所示修改应用程序的配置时，

spring.cloud.stream.kafka.streams:
  binder.configuration:
    default.key.serde: org.apache.kafka.common.serialization.Serdes$IntegerSerde
    default.value.serde: org.apache.kafka.common.serialization.Serdes$StringSerde
spring.cloud.stream.bindings.input.consumer.useNativeDecoding: true

我的拓扑结构如下：

2019-05-01 18:02:12.705 DEBUG 67539 --- [           main] o.s.k.config.StreamsBuilderFactoryBean   : Topologies:
   Sub-topology: 0
    Source: KSTREAM-SOURCE-0000000000 (topics: [hello-1])
      --> KSTREAM-MAPVALUES-0000000001
    Processor: KSTREAM-MAPVALUES-0000000001 (stores: [])
      --> none
      <-- KSTREAM-SOURCE-0000000000

这仍然与您从普通的Kafka Streams应用程序中获得的拓扑结构不同，但是事实证明，这是我们可以在活页夹中避免的问题。简而言之，通过切换到Kafka Streams提供的本机解码和编码，可以避免由绑定器构建的所有这些额外级别的拓扑。

在某些情况下，您别无选择，而是依赖于Spring Cloud Stream提供的反序列化，例如，您从基于使用某些特殊序列化器的Spring Cloud Stream的生产者那里接收数据。我认为您的情况是对的，因为据我所记得，您的生产者基于Spring Cloud Stream，并且使用框架提供的Avro序列化程序。在这种情况下，由于这些串行器不兼容，因此无法在处理器中使用Kafka Stream的Avro Serde。所以这是您的一些选择。

Approcah＃1：

1. 让生产者使用Kafka提供的本机序列化器。
2. 然后使用Serde，在您的Kafka Streams应用程序中使用相同的序列化器/反序列化器。

方法2：

1. 使用SCSt提供的消息序列化器。
2. 然后使用Kafka Streams绑定程序提供的默认反序列化功能。

＃2的缺点很明显是您在上面提到的，即更深的拓扑。根据您的用例和吞吐量，这可能没问题。如果这成为真正的性能问题，当框架完成转换时，我们可以尝试简化此过程。

话虽如此，我在Kafka活页夹中创建了一个issue，以在下一个发行版中进行更改。在那里欢迎您的反馈，建议，上/下投票。