什么是流水号?
做开发的人都知道流水号这个概念，有业务流水号，交易流水号，请求流水号等等，各种流水号。
无论是啥名字的流水号，目的都是为了在某个维度，让一系列动作有一个唯一的标识。后面方便查日志，查问题。系统间交互可以防止扯皮。
比如交易流水号，唯一标识一笔交易，这边所说的交易可以是无业务含义的请求，也可以是账务交易。如果是标识无业务含义的请求。一般会在交易开始时生成一个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系统时重复刚刚的几步操作。
简单理解：在运行过程中，Jnl始终从一个系统的ThreadLocal转移到另一个系统的ThreadLocal中。转移过程通过取和放都通过Dubbo Filter来完成。
这个过程涉及到3个角色。
① ThreadLocal
② Consumer一方的Filter，作用是读取ThreadLocal中的Jnl放入Invocation Attachment中
③ Privoder一方Filter，作用是读取Invocation Attachment中的Jnl放入ThreadLocal中
下面看代码实现
public class AccessJnlUtil {
// 获取
public static String getAccessJnl() {
return (String) RpcContext.getContext().get("AccessJnl");
}
// 放入
public static void setAccessJnl(String accessJnl) {
RpcContext.getContext().set("AccessJnl", accessJnl);
}
public static void deleteAccessJnl() {
RpcContext.getContext().remove("AccessJnl");
}
}
AccessJnlUtil是用来对AccessJnl做put和set操作的。利用了Dubbo RpcContext，RpcContext本身就是 ThreadLocal的封装，不熟悉的话可以追踪下源码，这边不再赘述。
public class AccessJnlConsumerFilter implements Filter {
@Override
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
invocation.getAttachments().put("AccessJnl", AccessJnlUtil.getAccessJnl());
return invoker.invoke(invocation);
}
}
AccessJnlConsumerFilter是消费方的Filter，在实际调用invoke之前，把AccessJnl从ThreadLocal中取出，放到Invocation Attachment中。
public class AccessJnlProviderFilter implements Filter {
@Override
public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
AccessJnlUtil.setAccessJnl(RpcContext.getContext().getAttachment("AccessJnl"));
return invoker.invoke(invocation);
}
}
AccessJnlProviderFilter是消费方的Filter，在实际调用invoke之前，把AccessJnl从Invocation Attachment中取出，放到ThreadLocal中。
然后就是把两个Filter配置到系统中，具体配置方式可以参考Dubbo文档
总结
利用dubbo的Attachment做隐式传递。我个人比较喜欢这样的处理方式。相对优雅。
