在使用dubbo时，消费者调用服务者，居然走了http请求！大吃一惊。
项目的配置是consumer(消费者)没有指定protocol，provider（服务者） 同时支持rest和dubbo协议，结果consumer会间歇性走rest协议，服务器端的tomcat收到了http请求，由于服务端做了验签爆出一场，最后将consumer协议指定为dubbo就好了。
但是内部原理不懂，推测消费者生成了两个代理，一个rest协议的代理，一个dubbo协议的代理，这两个代理随机使用。
我终于明白了，如果消费者没有指定协议，那么如果走了rest协议，dubbo会将消费者调用的方法，底层转为http请求，所以服务器端收到的是http请求，这个一点与dubbox官方文档列举的，dubbo客户端调用非dubbo服务应用场景，完全吻合。
【dubbo|dubbo消费者没有指定protocol，服务器端支持dubbo和rest，结果一会走dubbo、一会走rest】场景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服务。
推荐阅读
- Dubbo使用Hessian2序列化时针对Byte类型出现java.lang.ClassCastException
- Dubbo|【Dubbo | Zookeeper】一篇文章入门Dubbo+Zookeeper
- SpringBoot整合RPC框架Dubbo
- Spring|Spring Cloud Alibaba(四)（Spring Cloud 使用 Sentinel 实现限流）
- Spring|Spring Cloud Alibaba(三)（使用 Nacos config 实现统一配置管理）
- Spring|Spring Cloud Alibaba(二)（注解实现 Dubbo 服务调用失败时的本地伪装）
- java框架|org.apache.curator.CuratorConnectionLossException: KeeperErrorCode = ConnectLoss
- Dubbo之RpcContext原理
- Java|dubbo @EnableAsync @Configuration
- dubbo中的ExtensionLoader详解