dubbo微服务之间流水号的隐式传递

做开发的人都知道流水号这个概念，有业务流水号，交易流水号，请求流水号等等，各种流水号。

无论是啥名字的流水号，目的都是为了在某个维度，让一系列动作有一个唯一的标识。后面方便查日志，查问题。系统间交互可以防止扯皮。

比如交易流水号，唯一标识一笔交易，这边所说的交易可以是无业务含义的请求，也可以是账务交易。如果是标识无业务含义的请求。一般会在交易开始时生成一个32位或者64位的唯一编码。这个编码会在交易的纵向流程中传递，可以用参数传递，也可以放到上下文 Context 中，还可以放到 ThreadLocal 中。

在单体应用 Singleton Application 中，对流水号的处理比较简单，无论是参数传递还是 ThreadLocal 都没有什么难度。

在微服务环境下，一笔交易会经过多次微服务之间的交互，并且需要把流水号传递下去，它的传递链路可能是这样的（服务A） --> （服务B --> ）（服务C） --> （服务D） -->（服务E），使用 dubbo 作为 RPC 框架。有2种传递流水号的方式（当然这只是我自己觉得，可能还有更好的处理方式），下面详细说说。

参数传递法

这种方式很容易理解，就是把流水号作为接口的一个参数 (String jnl) 。这种方式结构简单，实现起来也很简单。但是有诸多问题。

1.几乎所有暴露的接口服务都会有这么个参数。不好看。

2.交易流水号，实际与业务本身相关性比较低。微服务之间的参数应该尽量与业务强相关，而不是占用单独的参数位置来