在使用dubbo时，消费者调用服务者，居然走了http请求！大吃一惊。
项目的配置是consumer(消费者)没有指定protocol，provider（服务者） 同时支持rest和dubbo协议，结果consumer会间歇性走rest协议，服务器端的tomcat收到了http请求，由于服务端做了验签爆出一场，最后将consumer协议指定为dubbo就好了。
但是内部原理不懂，推测消费者生成了两个代理，一个rest协议的代理，一个dubbo协议的代理，这两个代理随机使用。

我终于明白了，如果消费者没有指定协议，那么如果走了rest协议，dubbo会将消费者调用的方法，底层转为http请求，所以服务器端收到的是http请求，这个一点与dubbox官方文档列举的，dubbo客户端调用非dubbo服务应用场景，完全吻合。

场景3：dubbo的消费端调用非dubbo的REST服务

这种场景下，可以直接用场景1中描述的Java的方式来调用REST服务。但其实也可以采用场景2中描述的方式，即更透明的调用REST服务，即使这个服务并不是dubbo提供的。

如果用场景2的方式，由于这里REST服务并非dubbo提供，一般也就没有前述的共享的Java服务接口，所以在此我们需要根据外部REST服务的情况，自己来编写Java接口以及相应参数类，并添加JAX-RS、JAXB、Jackson等的annotation，dubbo的REST底层实现会据此去自动生成请求消息，自动解析响应消息等等，从而透明的做远程调用。或者这种方式也可以理解为，我们尝试用JAX-RS的方式去仿造实现一遍外部的REST服务提供端，然后把写成服务接口放到客户端来直接使用，dubbo的REST底层实现就能像调用dubbo的REST服务一样调用其他REST服务。