上线前一个小时，dubbo这个问题可把我折腾惨了

标签：序列化   def   深度   没有想到   invalid   pass   except   技术   get   

public ResponseData<String> login(UserLoginRequest loginRequest) {
    loginRequest.getAddress().stream().map(a -> a.getStatus()).collect(Collectors.toList());
    return Response.ok("xxxxxxxxx");
}

问题就出在了 map 这里，从 loginRequest 参数中获取 address 是一个 List
，Address 中有 status 字段，如果是正常的对象没有问题，错误告诉我们是 HashMap 不能转换成 Address 类，也就是说参数中的 Address 变成了 HashMap 导致的错误。
参数代码：

@Data
public class UserLoginRequest implements Serializable {
    private String username;
    private String pass;
    private List<Address> address;
}
@Data
@AllArgsConstructor
public class Address implements Serializable {
    private int status;
}

第三步：本地复现错误
找到错误后，马上本地启动相关的两个服务，我们分别叫 A 和 B 吧，现象是 A 调用 B 的某个 RPC 接口报错。
本地启动后马上复现了错误，在报错的地方打断点看参数是否变成了 HashMap，果不其然，如下图：

参数信息
到这里感觉有点懵，参数中明明是具体的对象类型，怎么突然就变成了 HashMap，匪夷所思。
然后想着是不是在上层什么地方出问题了，继续查看报错的上层代码，没有发现异常。然后决定在 PRC 的入口处打个断点看看是不是参数一过来就出问题了，最后经过验证确实如此，也就排除了 B 服务中对参数做了转换。
接着再看下 Dubbo 内部的参数解码，
org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation#decode(org.apache.dubbo.remoting.Channel, java.io.InputStream)。也就是请求到达 B 之后解码出来的已经是 HashMap 了，那么问题肯定是调用方传输的参数有问题。

Dubbo内部参数查看
第四步：排查调用方代码
在调用方这边发起请求前，查看了参数对象，发现这个时候参数已经出问题了，字段类型发生了变化，所以问题就出在这里，都是老代码，应该都没改过，而是事实却被改了，通过 Idea 的 Annotate 快速的查看了当前方法中有被修改的记录，找到了修改的代码，下面通过模拟的方式贴出有问题的代码，如下：

@Reference(version = DubboConstant.VERSION_V100, group = DubboConstant.DEFAULT_GROUP)
private UserRemoteService userRemoteService;
public void test() {
    UserLoginRequest request = new UserLoginRequest();
    request.setUsername("yjh");
    request.setPass("123456");
    List<Address> address = new ArrayList<>();
    address.add(new Address(1));
    request.setAddress(address);
    UserLoginRequest2 request2 = new UserLoginRequest2();
    request2.setUsername("yjh2");
    request2.setPass("1234562");
    List<Address2> address2 = new ArrayList<>();
    address2.add(new Address2(StatusEnum.INVALID));
    request2.setAddress(address2);

    BeanUtils.copyProperties(request2, request);

    userRemoteService.login(request);
}

出问题的就是 BeanUtils.copyProperties(request2, request); 这行代码，将一个对象复制到另一个对象，两个对象的属性都一样，唯一不一样的是 Address 中的 status 是 int 类型，Address2 中的 status 是 Enum，复制过去就出问题了。

属性复制
这种情况也只在 Dubbo 的 RPC 请求出问题，如果是 Http 请求，基本类型变成了枚举，直接就报错了，无法转换。

Http请求错误
第五步：BeanUtils 问题排查
归根到底还是 copy 的问题，我做了个小实验，如果是 Address2 copy 到 Address 是不会出问题的，只有嵌套的对象才会出问题。
特意看了下 copy 的代码，如果是 Address2 copy 到 Address，那么就是 status 到 status，在 copy 之前会进行判断 Address 的 setStatus 的第一个参数类型和 Address2 的 getStatus 的返回值是否相同，如果相同才会进行赋值操作，不同就不会，如果是单个对象在这里就会直接过滤掉了，一个是 int 一个是 Enum。

BeanUtils源码
嵌套对象之所以可以那是因为 address 的参数和返回类型都是 List，没有去判断嵌套类里面的，是整个集合直接复制赋值的，下图是目标方法：

BeanUtils源码
value 是新的集合对象，invoke 后整个 address 就变了。

嵌套对象复制后
第六步：Dubbo 解码问题排查
前面分析中，调用之前通过 BeanUtils 复制，只是将枚举赋值给了基本类型，如果 Dubbo 在接收到参数进行解码时能够识别出类型不一致，这样就直接会报错了，然而并没有，特意调试了下 Dubbo 解码的代码，默认是 Hessian 的解码，怀疑跟 Hessian 有关，于是我把序列化改成了 FastJson，在解码参数的时候就直接报错了，不能转换成 int 类型。而 Hessian 在映射不了的时候就直接变成 HashMap 了，这才有了我们前面的错误。

FastJson解码失败
结局
找到原因后解决就是分分钟的事了，通过这个问题还是说明了加任何的代码都有风险。剩下的就是开发的锅了，加了代码没有自测，好在有测试把关，否则就凉凉了。
热文推荐
Spring Boot 与微服务从0到1的实践

我在外包公司做增删改查有前途么？

那天晚上和@FeignClient注解的深度交流

如有收获，点个在看，诚挚感谢

尹吉欢

上线前一个小时，dubbo这个问题可把我折腾惨了

标签：序列化   def   深度   没有想到   invalid   pass   except   技术   get   

原文地址：https://blog.51cto.com/14888386/2515470