学习概要
**

1. Dubbo 调用非典型使用场景
2. 调用内部实现源码分析
3. RPC协议基本组成
4. RPC协议报文编码与实现详解
5. Dubbo中所支持RPC协议与使用

一、Dubbo调用非典型使用场景

1. 泛华提供 & 引用

泛华提供

是指不通过接口的方式直接将服务暴露出去。通常用于 Mock 框架或服务降级框架实现。

示例

public static void doExportGenericService() {
    ApplicationConfig applicationConfig = new ApplicationConfig();
    applicationConfig.setName("demo-provider");
    // 注册中心
    RegistryConfig registryConfig = new RegistryConfig();
    registryConfig.setProtocol("zookeeper");
    registryConfig.setAddress("192.168.0.147:2181");
    ProtocolConfig protocol=new ProtocolConfig();
    protocol.setPort(-1);
    protocol.setName("dubbo");
    GenericService demoService = new MyGenericService();
    ServiceConfig<GenericService> service = new ServiceConfig<GenericService>();
    // 弱类型接口名
    service.setInterface("com.tuling.teach.service.DemoService");
    // 指向一个通用服务实现
    service.setRef(demoService);
    service.setApplication(applicationConfig);
    service.setRegistry(registryConfig);
    service.setProtocol(protocol);
    // 暴露及注册服务
    service.export();

泛化引用

是指不通过常规接口的方式去引用服务，通常用于测试框架

2. 隐式传参

是指通过非常方法参数传递参数，类似于 Http 调用当中添加 cookie 值。 通常用于分布式追踪框架的实现。

使用方式如下：

//客户端隐示设置值
RpcContext.getContext().setAttachment("index", "1"); // 隐式传参，后面的远程调用都会隐
//服务端隐示获取值
String index = RpcContext.getContext().getAttachment("index");

3. 令牌验证

通过令牌验证在注册控制权限，以决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者，另外通过注册中心可灵活改变授权方式，而不需要修改 或 升级提供者。

使用：

<!--随机token令牌，使用UUID生成--><dubbo:provider interface="com.foo.BarService" token="true" />

4. 过滤器

类似于 WEB 中的Filter ，Dubbo本身提供了Filter 功能用于拦截远程方法的调用。其支持自定义过滤器与官方的过滤器使用：

TODO 演示添加日志访问过滤:

<dubbo:provider  filter="accesslog" accesslog="logs/dubbo.log"/>

以上配置 就是 为 服务提供者 添加 日志记录过滤器， 所有访问日志将会集中打印至 accesslog 当中

自定义过滤器：

1、编写过滤器

package com.tuling.dubbo;

import org.apache.dubbo.common.constants.CommonConstants;
import org.apache.dubbo.common.extension.Activate;
import org.apache.dubbo.rpc.*;

@Activate(group = {CommonConstants.PROVIDER})
public class ProviderHelloFilter implements Filter {

    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        System.out.println("hello ok====================================>>>>>");
        return invoker.invoke(invocation);
    }
}

添加扩展点：
创建文件路径如下：

# 文件路径
META-INF/dubbo/org.apache.dubbo.rpc.Filter
#内容：
helloFilter=com.tuling.dubbo.ProviderHelloFilter

二、调用内部实现源码分析

知识点

1. 分析代理类
2. 分析类结构
3. 初始化过程
4. 分析代理类

在调用服务端时，是接口的形式进行调用，该接口是Duboo 动态代理之后的实现，通过反编译工具可以查看到其具体实现：

因为类是代理生成，所以采用arthas工具来反编译，具体操作如下：

#运行 arthas
java -jar arthas-boot.jar
#扫描类
sc *.proxy0
#反编译代理类
jad com.alibaba.dubbo.common.bytecode.proxy0

反编译的代码如下：

/*
 * Decompiled with CFR.
 *
 * Could not load the following classes:
 *  com.tuling.client.User
 *  com.tuling.client.UserService
 */
package org.apache.dubbo.common.bytecode;
import com.alibaba.dubbo.rpc.service.EchoService;
import com.tuling.client.User;
import com.tuling.client.UserService;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.util.List;
import org.apache.dubbo.common.bytecode.ClassGenerator;
public class proxy0
implements ClassGenerator.DC,
EchoService,
UserService {
    public static Method[] methods;
    private InvocationHandler handler;
    public List findUser(String string, String string2) {
        Object[] arrobject = new Object[]{string, string2};
        Object object = this.handler.invoke(this, methods[0], arrobject);
        return (List)object;
    }
    public User getUser(Integer n) {
        Object[] arrobject = new Object[]{n};
        Object object = this.handler.invoke(this, methods[1], arrobject);
        return (User)object;
    }
    @Override
    public Object $echo(Object object) {
        Object[] arrobject = new Object[]{object};
        Object object2 = this.handler.invoke(this, methods[2], arrobject);
        return object2;
    }
    public proxy0() {
    }
    public proxy0(InvocationHandler invocationHandler) {
        this.handler = invocationHandler;
    }
}

可看出其代理实现了 UserService 接口。并且基于InvocationHandler 进行代理。实际类是 InvokerInvocationHandler 并且其中之属性为Invoker.。也就是说最终会调用Invoker进行远程调用。

1. Dubbo调用流程

基础流程：

1. 客户端调用
2. 透明代理
3. 负载均衡
4. 容错
5. 异步转同步
6. 获取结果
7. 服务端响应
8. 分析类结构关系

• prxoy$: 代理类
• Invoker: 执行器
• Invocation: 执行参数与环境
• Result：返回结果
• Protocol:协议

2. RPC 协议基本组成

在一个典型RPC的使用场景中，包含了服务发现、负载、容错、网络传输、序列化等组件，其中 RPC 协议就指明了 程序如何进行网络传输和序列化。 也就是说一个 RPC 协议的实现 就等于一个非透明的远程过程调用实现，如做到的呢？

协议基本组成
**

1. 地址： 服务提供者地址
2. 端口： 协议指定开放的端口
3. 报文编码： 协议报文编码，分为请求透和请求体两部分。
4. 序列化方式： 将请求体序列化成对象
   • Hessian2Serialization
   • DubboSerialization
   • JavaSerialization
   • JsonSerialization
5. 运行服务
   • netty
   • mina
   • RMI服务
   • servlet 容器（jetty、Tomcat、Jboss）

3. Dubbo 中所支持RPC协议使用

Dubbo 支持的RPC协议列表

关于 RMI 不支持防火墙穿透的补充说明：

原因在于 RMI 底层实现中会有两个端口，一个是固定的用于服务发现的注册端口，另外会生成一个 随机 端口用于网络传输。 因为这个随机端口就不能在防火墙中提前设置开放开。所以存在 防火墙穿透问题。

协议的使用与配置

Dubbo框架配置协议非常方便，用户只需要在 provider 应用中 配置**dubbo:protocol 元素即可。

 <!--
   name: 协议名称 dubbo|rmi|hessian|http|
   host:本机IP可不填，则系统自动获取
   port：端口、填-1表示系统自动选择
   server：运行服务  mina|netty|grizzy|servlet|jetty
   serialization：序列化方式 hessian2|java|compactedjava|fastjson
   详细配置参见dubbo 官网 dubbo.io
 -->
 <dubbo:protocol name="dubbo" host="192.168.0.11" port="20880" server="netty" 
  serialization=“hessian2” charset=“UTF-8” />

采用其它协议来配置Dubbo

• dubbo 协议采用 json 进行序列化 (源码参见：com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol)
• 采用RMI协议 (源码参见：com.alibaba.dubbo.rpc.protocol.rmi.RmiProtocol)
• 采用Http协议 (源码参见：com.alibaba.dubbo.rpc.protocol.http.HttpProtocol.InternalHandler)
• 采用Heason协议 (源码参见:com.alibaba.dubbo.rpc.protocol.hessian.HessianProtocol.HessianHandler)

new PrintWriter(System.out)

netstat -aon|findstr "17732"

序列化：

Hessian 序列化：

• 参数及返回值需实现 Serializable 接口
• 参数及返回值不能自定义实现 List, Map, Number, Date, Calendar 等接口，只能用 JDK 自带的实现，因为 hessian 会做特殊处理，自定义实现类中的属性值都会丢失。
• Hessian 序列化，只传成员属性值和值的类型，不传方法或静态变量，兼容情况 [1][2]：
  | 数据通讯 | 情况 | 结果 |
  |:——|:——|:——|
  | A->B | 类A多一种 属性（或者说类B少一种 属性） | 不抛异常，A多的那 个属性的值，B没有， 其他正常 |
  | A->B | 枚举A多一种 枚举（或者说B少一种 枚举），A使用多 出来的枚举进行传输 | 抛异常 |
  | A->B | 枚举A多一种 枚举（或者说B少一种 枚举），A不使用 多出来的枚举进行传输 | 不抛异常，B正常接 收数据 |
  | A->B | A和B的属性 名相同，但类型不相同 | 抛异常 |
  | A->B | serialId 不相同 | 正常传输 |

接口增加方法，对客户端无影响，如果该方法不是客户端需要的，客户端不需要重新部署。输入参数和结果集中增加属性，对客户端无影响，如果客户端并不需要新属性，不用重新部署。

输入参数和结果集属性名变化，对客户端序列化无影响，但是如果客户端不重新部署，不管输入还是输出，属性名变化的属性值是获取不到的。

总结：服务器端和客户端对领域对象并不需要完全一致，而是按照最大匹配原则。

三 、RPC协议报文编码与实现详解

RPC 传输实现：

RPC的协议的传输是基于 TCP/IP 做为基础使用Socket 或Netty、mina等网络编程组件实现。但有个问题是TCP是面向字节流的无边边界协议，其只管负责数据传输并不会区分每次请求所对应的消息，这样就会出现TCP协义传输当中的拆包与粘包问题

拆包与粘包产生的原因：

我们知道tcp是以流动的方式传输数据，传输的最小单位为一个报文段（segment）。tcp Header中有个Options标识位，常见的标识为mss(Maximum Segment Size)指的是，连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit)，一般是1500比特，超过这个量要分成多个报文段，mss则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460比特。换算成字节，也就是180多字节。

tcp为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。这时就会出现以下情况：

1. 应用程序写入的数据大于MSS大小，这将会发生拆包。
2. 应用程序写入数据小于MSS大小，这将会发生粘包。
3. 接收方法不及时读取套接字缓冲区数据，这将发生粘包。

拆包与粘包解决办法：

1. 设置定长消息，服务端每次读取既定长度的内容作为一条完整消息。
2. {“type”:”message”,”content”:”hello”}\n
3. 使用带消息头的协议、消息头存储消息开始标识及消息长度信息，服务端获取消息头的时候解析出消息长度，然后向后读取该长度的内容。

比如：Http协议 heade 中的 Content-Length 就表示消息体的大小。

(注①：http 报文编码)

Dubbo 协议报文编码：

注②Dubbo 协议报文编码：

• magic：类似java字节码文件里的魔数，用来判断是不是dubbo协议的数据包。魔数是常量0xdabb,用于判断报文的开始。
• flag：标志位, 一共8个地址位。低四位用来表示消息体数据用的序列化工具的类型（默认hessian），高四位中，第一位为1表示是request请求，第二位为1表示双向传输（即有返回response），第三位为1表示是心跳ping事件。
• status：状态位, 设置请求响应状态，dubbo定义了一些响应的类型。具体类型见 com.alibaba.dubbo.remoting.exchange.Response
• invoke id：消息id, long 类型。每一个请求的唯一识别id（由于采用异步通讯的方式，用来把请求request和返回的response对应上）
• body length：消息体 body 长度, int 类型，即记录Body Content有多少个字节。

*（注：相关源码参见 **c**om.alibaba.dubbo.rpc.protocol.dubbo.DubboCodec**）*

Dubbo协议的编解码过程：

Dubbo 协议编解码实现过程 (源码来源于*dubbo2.5.8 )

1、DubboCodec.encodeRequestData() 116L // 编码request
2、DecodeableRpcInvocation.decode()  89L   // 解码request
3、DubboCodec.encodeResponseData()   184L  // 编码response    
4、DecodeableRpcResult.decode()      73L   // 解码response