事务型Kafka生产者场景下Sleuth链路追踪失效及适配方案咨询

• 现有TraceProducerPostProcessor的触发锚点，从设计之初就只绑定在普通非事务生产者的创建流程上：它的回调触发完全依赖DefaultKafkaProducerFactory针对普通生产者开放的扩展点，和事务生产者的创建逻辑没有任何关联。本质上Spring Kafka里普通生产者、事务生产者的创建是两条平行的代码路径，埋点逻辑只挂了其中一条，自然漏了另一条。
• 事务生产者本身是独立的生命周期管理域：Spring Kafka的事务生产者不走普通生产者的复用池逻辑，是由事务管理器托管、在事务上下文中动态创建/回收的独立资源，对应的创建逻辑doCreateTxProducer从一开始就设计成了无扩展入口的私有方法，相当于把事务生产者的创建流程完全封闭，不对外暴露任何可挂钩的回调点。
• 早期链路追踪组件的场景覆盖盲区：Sleuth（后续的Micrometer Tracing）最初做Spring Kafka埋点适配时，默认认为事务生产者是框架内部托管的底层资源，不会被业务代码直接持有和调用，因此没有把这块场景纳入最初的埋点范围，属于设计时的遗漏，不是刻意的功能限制。
• 两类生产者的资源池是物理隔离的：后置处理器只挂载在普通生产者的资源池创建流程上，自然感知不到独立事务资源池里创建的实例。

• 方案1：自定义扩展DefaultKafkaProducerFactory，在事务生产者创建的出口处手动包装追踪代理
  继承默认的生产者工厂类，重写事务场景下的生产者创建分支，在拿到原生事务生产者实例后，手动调用Micrometer Tracing提供的TracingProducer构造逻辑完成代理包装。实现时要注意保留原有事务生产者的资源池复用逻辑，仅在实例创建的最后一步追加包装逻辑，不要破坏原有事务管理的语义。
• 方案2：调整后置处理器的挂载范围
  通过自定义BeanPostProcessor拦截Spring容器中注入的DefaultKafkaProducerFactory实例，拿到工厂内部维护的生产者后置处理器列表，通过反射的方式把后置处理器的调用逻辑注入到doCreateTxProducer的执行链中。实现时需要注意不同Spring Kafka版本的私有方法命名、内部结构差异，做好版本兼容。
• 方案3：升级到已完成原生适配的版本组合
  Spring Kafka 2.8.x 之后的版本，已经在DefaultKafkaProducerFactory中开放了针对事务生产者的后置处理扩展接口，同时新版本的Micrometer Tracing也已经适配了这个扩展点，直接引入对应版本的依赖即可自动完成事务生产者的埋点，不需要写自定义适配逻辑。
• 验证注意点：适配完成后需要确认跨线程场景下（比如事务异步执行）链路上下文和事务上下文的绑定关系，避免出现b3请求头因为上下文透传问题丢失的情况。

内容的提问来源于stack exchange，提问作者wasiter