在云原生的场景下，整个请求的链路会不变的变长。 例如，当一个请求发送后，后端可能会有数十个模块相互访问请求转发后才能得到最终的响应结果。

    而随着链路的不断增加，问题定位的成本也不断增加，例如，对于一个请求异常的场景而言，我们可能需要从数十个模块中定位问题的发生点；
    同时，对于一个耗时很长的请求而言，我们也需要从数十个模块中依次定位才可能找到性能的瓶颈。

    为了能够保持随着链路的不断增长，问题定位和分析的成本保持可控，我们需要对整个访问链路进行追踪。

    常用的分布式追踪方案包括 Zipkin, Jaegar, OpenTracing 等方案，它们可以记录整个链路请求的耗时，可以在链路之间透传 headers 等信息。

    而在我们之前讲到的 KT-env 环境复用能力之中，一个前提的条件就是各个模块之间可以透传指定的 headers 。

    除了强大的整体分布式追踪方案 Zipkin, Jaegar, OpenTracing 之外，如果仅仅是想要实现 headers 透传方案的话，可以有一些更加轻量化的方案。

    在本系列的文章中，我们除了会介绍 Zipkin, Jaegar, OpenTracing 等方案外，也会介绍一些常用框架的简单的 headers 透传方案。

    参考资料