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

什么是流水号?

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

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

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

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

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

参数传递法

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

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

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

3.这样的方式，维护起来麻烦，写啥服务都得加这么个参数，移植性也很差。

我个人不喜欢这样的做法。

利用dubbo的Attachment做隐式传递

还是模拟刚刚的传递过程，把一个32位的Jnl在服务间传递。（服务A） --> （服务B --> ）（服务C）

1.A服务是入口，生成32位流水号Jnl

2.A服务把Jnl放到ThreadLocal中

3.在调用B系统之前，把Jnl从ThreadLocal取出并且放入Invocation Attachment中（这个过程由Dubbo Filter做）

4.B系统接收Invocation信息，并且反序列化。从Attacment中取出Jnl放入ThreadLocal中（这个过程由Dubbo Filter做）

5.B系统调用C系统时重复刚刚的几步操作。

简单理解：在运行过程中，<