Dubbo上下文信息、隐匿参数附件（六）

1、参考

上下文信息：http://dubbo.apache.org/en-us/docs/user/demos/context.html

隐匿参数：http://dubbo.apache.org/en-us/docs/user/demos/attachment.html

我觉得这两个功能与监控、跟踪、路径分析有关。

2、上下文信息

Dubbo里边的上下文为RpcContext。

首先RpcContext是线程级的，每个线程一份。

RpcContext主要记录调用关系，当Consumer调用别人或者Provider被别人调用后，RpcContext的内容就会更新。比如：A 调 B，B 再调 C，则 B 机器上，在 B 调 C 之前，RpcContext 记录的是 A 调 B 的信息，在 B 调 C 之后，RpcContext 记录的是 B 调 C 的信息。

另外调用发生时，所有的配置信息都会转换成URL，也就是配置信息没有记录在上下文中。

2.1、Consumer端

// 远程调用
xxxService.xxx();
// 本端是否为消费端，这里会返回true
boolean isConsumerSide = RpcContext.getContext().isConsumerSide();
// 获取最后一次调用的提供方IP地址
String serverIP = RpcContext.getContext().getRemoteHost();
// 获取当前服务配置信息，所有配置信息都将转换为URL的参数
String application = RpcContext.getContext().getUrl().getParameter("application");
// 注意：每发起RPC调用，上下文状态会变化
yyyService.yyy();

2.2、Provider端

public class XxxServiceImpl implements XxxService {
 
    public void xxx() {
        // 本端是否为提供端，这里会返回true
        boolean isProviderSide = RpcContext.getContext().isProviderSide();
        // 获取调用方IP地址
        String clientIP = RpcContext.getContext().getRemoteHost();
        // 获取当前服务配置信息，所有配置信息都将转换为URL的参数
        String application = RpcContext.getContext().getUrl().getParameter("application");
        // 注意：每发起RPC调用，上下文状态会变化
        yyyService.yyy();
        // 此时本端变成消费端，这里会返回false
        boolean isProviderSide = RpcContext.getContext().isProviderSide();
    } 
}

很明显上下文是用来明确调用关系的。如果配合上记录配置信息的URL、下边介绍的“隐匿参数”，然后每当上下文发生变化时，将这些信息打印出来，这样关于调用的信息就会被完整的记录，通过分析这些日志，似乎可以达到性能分析、调用路径分析等功能。

3、附件或者隐匿参数

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-MFsYJb5d-1648771321731)(http://dubbo.apache.org/docs/en-us/user/sources/images/context.png)]

从功能上看，这个东西有点像HTTP请求或者应答中的请求头部或者应答头部。如果没有，不影响业务逻辑的正常执行，如果有，则相当于向对方提供了额外的附加信息，往往能够得到更好的效果或者额外附加的功能。

HTTP中这种额外信息通过“头部”交换，在Dubbo中这种东西放在RpcContext中，它是键值对，每次调用都会清空，所以调用一次要分配一次。

在Consumer端设置：

RpcContext.getContext().setAttachment("index", "1"); // implicitly pass parameters,behind the remote call will implicitly send these parameters to the server side, similar to the cookie, for the framework of integration, not recommended for regular business use
xxxService.xxx(); // remote call
// ...

在Provider端提取：

public class XxxServiceImpl implements XxxService {

    public void xxx() {
        // get parameters which passed by the consumer side,for the framework of integration, not recommended for regular business use
        String index = RpcContext.getContext().getAttachment("index");
    }
}

假如调用路径比较复杂，像A->B->C->D->E，并且每个服务都是多实例。对于某一个具体的调用，如果想跟踪具体调用路径、响应时间等。可以在A调用B时分配一个唯一ID，结合上边的上下文记录下来A到底调用了那个B，什么时候调用的，并且唯一ID标识。然后B也做同样的动作，依次是后边的C、D、E等。然后通过分析这些记录，就可以知道这次调用具体经过的路径是什么、经过每个节点都花了多少时间等。

。