kamon文档翻译（五）--考虑线程模型

考虑线程模型

如trace context manipulation 一节中所描述的，我们总是使用Tracer 伴随对象存储和接收当前trace的 TracerContext 。反过来，Tracer 也会结束存储局部线程变量的TraceContext.。目前为止，这是最简单和最可预测的方式存储TraceContext，也是第三方库交互TraceContext的方式。为了使得=这种方式能够发挥作用，你需要完全明白你的应用程序线程模型的工作方式。一些情况下，模型很简单而且是单线程的，但是，当你以基于事件的方式时，就会变得很复杂。
下面我们描述三种常见的线程模型，并提供指导，让你知道应该如何操作和跨线程使用TraceContext。

传统模型

传统的模型，尤其是使用servlets时，在于将所有与请求有关的代码都绑定到一个单线程上。上图中，后面的小箭头代表了一个线程，上麦呢的方块代表了线程被阻塞，直到接收到数据库的响应。如果你使用一个阻塞的客户端向外部服务发送一个HTTP请求，你的线程也会因为等待外部服务的响应而被阻塞。当所有的都在一个线程上发生时，你就不需要特殊考虑，只要使用traceing API就可以了。

增强传统模型

有时候，按顺序等待所有请求返回不是一个选择，或者为了使延迟达到最小，需要并发的执行其他任务。这是，常用的方式是在传统的顺序流上增加一个分裂点，允许部分代码并发执行，最后将所有结果汇总。这仍然阻塞了线程，事实上，与传统模型相比，这阻塞了更多的线程。但是这时应用程序会执行得快一线。我们称其为增强传统模型。模型图如图所示：

当你的应用程序在这个模式下工作时，当你还在主线程中时，你可以将TraceContext传送给其他线程。如果需要这么做，则依赖tracing API 获得当前的TraceContext，当你还在主线程中时，将其传递给支撑线程将要执行的任务。当你完成的时候，清理好所有的支撑线程很重要，因为当你释放一个线程，它可能会被立即用于另一个trace。

基于事件的模型

当你采用基于事件的模型时，你需要特别谨慎对待TraceContext 的传播，因为当你处理一个请求时很可能会同时引发几个不同线程处理的不同异步事件，直到完成请求。基于事件的模型如下图：

从图中可以看出，一个请求流的处理过程被分为几个步骤，当有了需要的返回时在将来的某个时间点结束。请求流的某些部分需要阻塞线程，像JDBC连接数据库，但是大部分的代码都是在不同的线程中异步执行。
这个模型中另一个重要的是，在不可预见的时间点，不同的线程发生了不同事件，对与一个trace有关的第一个事件的处理会引发其他事件，并且，仅仅跟这个特定的trace和循环重复有关。这个模型中，线程不那么重要，你需要关心的是TraceContext 是如何与你应用程序中的事件关联的。
现在，基于事件的模型很常见，我们已经为Scala和Akka提供了基于事件的组件，但是，这种情况下，你需要新的工具，tracing API 会帮助你。