Kafka中Topic的元数据是在zookeeper中的，大量topic确实会造成性能瓶颈，不仅在磁盘读写上。虽然目前还没有发布的Kafka 3.0计划去掉ZK的依赖自组Raft集群，未来或许能缓解这个问题。但当前，是不是可以尝试解决单个Kafka集群topic过多这个根本问题呢？

第一个最简单粗暴的人工Sharding方法： 部署多个Kafka集群 。给接入的服务分组，互相之间 没有发布订阅关系 的业务服务，配置用不同的Kafka连接信息。对于题主提到的日志服务这样的N个服务发布，1个服务订阅的场景，应该是实用的。

第二个有代码侵入的方法， 合并Topic，业务封装一层SubTopic 。比如每个服务的N个统计项，封装到一个自定义的消息类，加一个subTopic的字段用于区分，订阅消费时根据该字段决定消息如何处理。

第二个方法，可能是在“ 消费到无关的消息 ”和“ 创建大量topic ”之间的一个折衷方案。毕竟Kafka本身没有subtopic的支持，星号通配符订阅其实也是在ZK遍历和创建多个元数据，不能解决性能问题。

个人对Kafka了解比较浅，目前想到的只有这两个笨办法了。