Dubbo中的那些坑（四）HTTP调用
Dubbo的HTTP调用
Dubbo实现了HTTP调用，但只是走了HTTP协议而已，并没有使用诸如REST的调用方式。换句话说，其他语言不能直接调用Dubbo的HTTP协议。而如今异构的系统的REST调用都比较常见，也出现了对Dubbo的REST协议的各种实现。
基于RESTEasy的REST调用实现
当当网改进的Dubbox，用了JBOSS的RESTEasy实现REST功能，比Jersey、Restlet、CXF好用。具体参见当当网开源项目：Dubbox
基于SpringMVC的REST调用实现
热心网友在GitHub上向当当网提交了基于SpringMVC的REST调用实现(Pull request地址)。互联网项目中SpringMVC用的挺多，基于SpingMVC的实现还是挺好的。（SpringCloud用的也是SpringMVC，将Dubbo作为SpringCloud服务后，可以提供服务给SpringCloud端使用。感兴趣可以参阅，Dubbo的Spring-boot化）
基于Servlet手动解析的实现
GitHub上的热心网友(好像是阿里巴巴员工)写了个Dubbo-Plus的项目，有实现Dubbo的HTTP调用(项目地址)，没用啥框架，手动解析HTTP请求。
基于RestExpress的REST调用实现
以上几种调换用都存在一个问题，并没有传入RpcContext对象，导致一些Dubbo的原生功能如Token校验等无法使用。这里用RestExpress（基于Netty，可脱离Tomcat或者Jetty等servlet容器运行，以极高的性能著称。参见Benchmark,Benchmark2）写了简单的实现。通过将HTTP请求头的值，写入RpcContext中来解决这一问题。项目地址：GitHub：xydonne/dubbo-rpc-restexpress
存在的问题
- 不支持泛型对象的序列化和反序列化，如List<T>,Map<T>等泛型类。也就是说，请求参数与返回对象都不能是泛型。这个和Java的泛型擦除机制有关，因为无法推断出Json字符串的具体类型，会把对象转换成LinkedHashMap，导致反序列化出错。
- 个人比较推崇SpringCloud，很大一部分原因是Dubbo好久没维护了。所以直接用SpringCloud是最好的，或者可以对其做些改进，让SpringCloud可以调用Dubbo的HTTP服务。那Dubbo服务协议自然选择SpringMVC，而Dubbo的消费端，可以使用Feign，这样原生支持SpringMVC的注解。方便以后迁移到SpringCloud。后面会开一个专题讲Dubbo的Spring-Boot化以及对接SpringCloud。
转载注明出处，我就不和你计较。
by Donney Young
http://www.jianshu.com/p/55cf706c6bfb
