前言
- 接触dubbo分布式框架的开发也有一段时间了，其中为了解决我的项目中遇到的一些杂症，还特意学习了一下Dubbo服务裸露和服务引入的一些源码知识点。最近在我的项目开发的过程中，有应用到了dubbo的隐式参数技术点，但发现了几个在应用上非常容易出错并且一出错就是生产事变的坑，当初记录一下。
一、理解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();
二、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在应用上的几个特点：
1、key名称不能以小驼峰命名，上游服务序列化后，会将key名称变成全小写（Dubbo 2.6.x版本，在2.7.x版本被修复了）
2、隐式参数设置后，仅在第一次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的参数了。 |
三、筛选出最优的解决方案
针对谬误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框架自带的。
四、总结
- 避坑指南：有波及到隐式参数的代码改变时，肯定要多测试。若某个环节被疏忽，很容易造成生产事变
- 如果你感觉我的文章有用的话，欢送点赞和关注。
- I'm a slow walker, but I never walk backwards