TTL是否支持调用中包含多种协议场景情况下的上下文传递

[xucw]

在微服务架构中，假如有这的链路：网关->A->B->C->D->E。其中，网关到A服务是http调用，A服务到B服务是通过RocketMQ协议，即A是生产者，B是消费者。B服务到C服务是http调用，C服务到D服务也是通过RocketMQ协议，即C是生产者，D是消费者。D服务到E服务是http调用。
TTL在类似这种场景下，从网关传递的上下文是否支持全链路传递？

[oldratlee]

@xucw 你提到的「从网关传递的上下文是否支持全链路传递」是 分布式追踪方案/领域所关注与解决的问题，很重要。 👍 ♥️

分布式追踪，业界已经有很多很好的实现。下文有些介绍：

• 分布式服务调用链路追踪——方案选型

分布式追踪关注的内容 比TTL复杂得多大得多；实现上可以用到TTL。

对于TTL的使用场景，分布式追踪（包含涉及的各个设施/中间件集成）相比其它场景，大家讨论得比较多。下面的内容有些说明与讨论：

• 自实现分布式链路追踪 方案&实践
• 分布式追踪系统场景下，如何使用TTL #53

其它的TTL使用场景（如DB的事务管理，看起来场景和分布式追踪相去很远），下面的issue中有一些说明：

• 小伙伴同学们写的 TTL实际业务使用场景 与 设计实现解析的文章（写得都很好！ ）❤️ #123

---

TTL在类似这种场景下，从网关传递的上下文是否支持全链路传递？

@xucw 回到你提的问题上：

TTL的功能/职责/定位 只是个 简单的ThreadLocal库，不会扩展到（成熟繁荣的）「分布式追踪」上。

a missing Java std lib(simple & 0-dependency) for framework/middleware, provide an enhanced InheritableThreadLocal that transmits values between threads even using thread pooling components.

关于TTL的功能/职责，在下面这个Issue中，也有一些讨论与说明：

• TTL是否不支持rocketMQ的上下文传递 #509