采坑经验：Dubbo 2.6.x版本中隐式参数attachment的错误使用方式，稍不注意就会出现生产事故

前言

• 接触dubbo分布式框架的开发也有一段时间了，其中为了解决项目中遇到的一些杂症，还特地学习了一下Dubbo服务暴露和服务引入的一些源码知识点。最近在项目开发的过程当中，有使用到了dubbo的隐式参数技术点，但发现了几个在使用上很是容易出错而且一出错就是生产事故的坑，如今记录一下。

1、了解Dubbo隐式参数以前先了解下Dubbo的上下文信息

• 什么是Dubbo的上下文信息？这里总结下本身的理解：

  上下文中存放的是当前 调用过程中所需的环境信息。全部的配置信息都将转换成URL的参数。RpcContext类就是Dubbo的上下文，可是它仅仅是一个ThreadLocal级别的 临时状态记录器，当接收到RPC请求或发起RPC请求时，RpcContext的状态都会变化。好比：A调用B、B再调用C的状况下。 B机器的RpcContext会有以下的状况发生：在B调用C以前，RpcContext记录的是A调B的信息，在B调用C以后，RpcContext记录的是B调C的信息。

• 好比：咱们想要获取到服务调用者的host相关信息，那么咱们能够在服务提供者中获取当前消费此服务的消费者的host信息，其代码以下所示：

  // 获取调用方的host信息
  String serverIP = RpcContext.getContext().getRemoteHost();

2、Dubbo上下文携带的隐式参数attachment

• 不知道各位在开发的时候，有没有遇到一种须要额外传递给下游服务的参数（好比标识当前用户请求的jwt、记录分布式系统全链路跟踪的全局traceId）。当有这方面的需求时，咱们不可能修改方法的参数签名，这与业务耦合了。此时，可能就须要使用Dubbo的隐式参数attachment了。什么是attachment？能够把它认定为Dubbo协议中的一个扩展点。就有点相似于Http协议，咱们能够自定义请求头信息。而在Dubbo中，咱们也能够自定义RPC请求中的参数。

• 举个例子：用户在执行下单这个业务，最终确定会通过后台的订单服务、库存服务等服务。如今有个需求：在订单服务中，要明确知道这个订单是哪一个用户建立的。在库存服务中，要明确知道这个商品最终是用户的哪一个操做致使减小的。整个需求里面有个核心：就是要知道操做者是谁！假设项目用的是jwt技术来记录用户的状态，那么订单服务和库存服务就必需要知道这个jwt字符串，将jwt解码后，就能知道当前请求是由哪一个用户发起的。在这样的一个场景中，使用dubbo的隐式参数能够达到上述的目的。实现的伪代码以下所示：

  RpcContext.getContext().setAttachment("jwt", "xxxxxxxxxxjwt字符串xxxxxxxx");
  // dubbo rpc 调用库存服务：减小库存
  warehouseService.decrement();
  // dubbo rpc 调用订单服务：建立订单
  orderService.create();

这里先总结下attachment在使用上的几个特色：

一、key名称不能以小驼峰命名，下游服务序列化后，会将key名称变成全小写（Dubbo 2.6.x版本，在2.7.x版本被修复了）

二、隐式参数设置后，仅在第一次RPC请求生效，后续的RPC请求将没法获取到隐式参数

由于attachment有上述的两个特色，所以咱们很容易以下的两个错误：

易犯错误1	易犯错误2
咱们在warehouseService.decrement()的下游服务中能顺利的从attachment中获取jwt参数，而在orderService.create()的下游服务中已经没法顺利的从attachment中获取jwt参数了	在本例中，添加到attachment中的key为jwt，是ok的。但若是咱们把key设置成大驼峰的命名方式，好比：userJwt。在通过Dubbo的一系列处理后，在warehouseService.decrement()下游服务中的rpcContext对象中的attachment中的key已经变成了userjwt，已经没法获取到key为jwt的参数了。

3、筛选出最优的解决方案

• 针对错误1，咱们有三个实现方案，其对应的方案策略以下所示：

  方案	优势	缺点
  方案1：在每一次发起RPC以前，都手动执行一次RpcContext.getContext().setAttachment("jwt", "xxxxxxxxxxjwt字符串xxxxxxxx");代码	能解决问题，但不是最优方案	增长编码的复杂度和代码的重复度。
  方案2：使用spring的aop 的before机制，在执行rpc发起远程服务以前，先把jwt放入到attachment中	能解决问题	dubbo的远程调用对象自己就很重量，如今再添加一层代理，不利于定位问题。
  方案3：使用Dubbo的filter机制，在对指定远程服务添加一层filter，filter的逻辑就是将jwt放入到attachment中去	比较好的一种解决方案，充分利用到了Dubbo框架自身提供的filter扩展。这也是比较通用的解决方案，全链路追踪的traceId也是这么玩的。（推荐）	代码阅读性不高，filter同aop同样，都是解耦的，不利于定位问题。

• 针对错误2，在不对源码进行扩展的状况下，最简单的方式就是修改key的命名方式，这里可使用两种方式：

  方式1	参考Dubbo源码的org.apache.dubbo.common.constants.CommonConstants类中对添加到URL中的key的命令方式，多个单词用.作区分
  方式2	单词与单词间使用自定义的符号作分隔，好比_，#等符号。这种方式也能够区分于key是本身添加的仍是Dubbo框架自带的。

4、总结

• 避坑指南：有涉及到隐式参数的代码改动时，必定要多测试。若某个环节被忽略，很容易形成生产事故
• 若是你以为个人文章有用的话，欢迎点赞和关注。
• I'm a slow walker, but I never walk backwards