版权声明：本文为博主原创文章，未经博主允许不得转载。        https://blog.csdn.net/wangjun5159/article/details/52718643
在使用dubbo时，消费者调用服务者，居然走了http请求！大吃一惊。
项目的配置是consumer(消费者)没有指定protocol，provider（服务者） 同时支持rest和dubbo协议，结果consumer会间歇性走rest协议，服务器端的tomcat收到了http请求，由于服务端做了验签爆出一场，最后将consumer协议指定为dubbo就好了。
但是内部原理不懂，推测消费者生成了两个代理，一个rest协议的代理，一个dubbo协议的代理，这两个代理随机使用。

我终于明白了，如果消费者没有指定协议，那么如果走了rest协议，dubbo会将消费者调用的方法，底层转为http请求，所以服务器端收到的是http请求，这个一点与dubbox官方文档列举的，dubbo客户端调用非dubbo服务应用场景，完全吻合。
---------------------
作者：干净的句号
来源：CSDN
原文：https://blog.csdn.net/wangjun5159/article/details/52718643
版权声明：本文为博主原创文章，转载请附上博文链接！

版权声明：本文为博主原创文章，未经博主允许不得转载。        https://blog.csdn.net/wangjun5159/article/details/52718643
在使用dubbo时，消费者调用服务者，居然走了http请求！大吃一惊。
项目的配置是consumer(消费者)没有指定protocol，provider（服务者） 同时支持rest和dubbo协议，结果consumer会间歇性走rest协议，服务器端的tomcat收到了http请求，由于服务端做了验签爆出一场，最后将consumer协议指定为dubbo就好了。
但是内部原理不懂，推测消费者生成了两个代理，一个rest协议的代理，一个dubbo协议的代理，这两个代理随机使用。

我终于明白了，如果消费者没有指定协议，那么如果走了rest协议，dubbo会将消费者调用的方法，底层转为http请求，所以服务器端收到的是http请求，这个一点与dubbox官方文档列举的，dubbo客户端调用非dubbo服务应用场景，完全吻合。
---------------------
作者：干净的句号
来源：CSDN
原文：https://blog.csdn.net/wangjun5159/article/details/52718643
版权声明：本文为博主原创文章，转载请附上博文链接！