我最近研究过这种建筑。
我们使用了一个api网关，它是与前端通信的webservice（在我们的例子中是reactjs）。这个api网关使用rest协议。用springboot开发的微服务在一个单独的线程中充当生产者和消费者。
1-生成消息：向kafka broker发送主题为“producer\u topic”的消息
2-消费信息：收听Kafka关于“消费主题”的信息
对于消费，有一个处理传入消息的线程池和侦听kafka流并将消息处理分配给池中的线程的执行服务。
最底层是一个dao微服务，它处理kafka消息并执行crud操作。
消息格式看起来很像你的第二种方法。

//content of messages in the consumer_topic
{
    event_type: 'delete'
    message: {
        first_name: 'John Doe'
        user_id: 'c73035d0-6dea-46d2-91b8-d557d708eeb1'
    }
}

这就是为什么我应该向你推荐第二种方法。当您仅用一个主题处理所有crud操作时，复杂性会降低。由于分区并行性，它的速度非常快，您可以添加复制以提高容错性。
从非物质化和关注点分离的Angular 来看，第一种方法听起来不错，但它并没有真正的可伸缩性。例如，假设您想添加额外的操作，这是另一个要添加的主题。还要看复制。你将有更多的复制品要做，这是相当糟糕的，我想。

kafka0.11添加了消息头，这是一种为消息体指示不同消息类型的简单方法，即使它们都使用相同的序列化程序。
https://cwiki.apache.org/confluence/display/kafka/kip-82+-+add+record+headers

按照tom的建议，请记住，即使使用单个主题，也可以选择使用多个分区来实现用户可伸缩性。kafka提供分区级别的排序，而不是主题级别的排序。这意味着您应该使用一个“键”来标识您正在创建、删除、更新的资源，以便使与此“键”相关的消息始终位于同一分区中，因此如果顺序正确，否则即使使用单个主题，您也可能会失去在不同分区上发送消息的顺序。

Kafka消息没有与之关联的类型。
对于每个事件类型一个主题，您将不得不担心从不同主题读取的同一实体的事件顺序。仅出于这个原因，我建议将所有事件放在同一个主题中。这样，客户机只需要使用一个主题就可以完全跟踪每个实体的状态。