Dubbo 为什么要迁移 Spring Cloud 服务调用?

Dubbo 迁移 Spring Cloud 服务调用 尽管 Dubbo Spring Cloud 完全地保留了原生 Spring Cloud 服务调用特性，不过 Dubbo 服务治理的能力是 Spring Cloud Open Feign 所不及的，如高性能、高可用 以及负载均衡稳定性等方面。因此，建议开发人员将 Spring Cloud Open Feign 或者 @LoadBalancedRestTemplate 迁移为 Dubbo 服务。 考虑到迁移过程并非一蹴而就，因此，Dubbo Spring Cloud 提供了方案，即 @Du bboTransported 注解。该注解能够帮助服务消费端的 Spring Cloud Open Feign 接口以及 @LoadBalanced RestTemplate Bean 底层走 Dubbo 调用（可切换 Dubbo 支持的协议），而服务提供方则只需在原有 @RestController 类上追加 Dubbo @Servce 注解（需要抽取接口）即可，换言之，在不调整 Feign 接口以及 RestTemp late URL 的前提下，实现无缝迁移。如果迁移时间充分的话，建议使用 Dubbo 服务重 构系统中的原生 Spring Cloud 服务的定义。

一、dubbo已经很久没有维护了【至少已经3-4年没有大版本更新】，据说阿里内部已不用dubbo改用HSF，求证？那么问题来了...

Java8语法支持不好，service类，用java8语法或语法糖支持不好，可能会报【Caused by: java.io.IOException: invalid constant type: 18】异常。解决办法：升级javassist到3.20.0-GA，同时升级tomcat到8.5.0+版本。
文档不清晰，例如provider中的connection占用的连接数不是针对每个consumer，而是每个reference。
dubbo很多功能模块不成熟未达到生产环境的要求，具体可以参考dubbo用户指南中的功能成熟度介绍，24个功能模块中只有7个可在生产环境中使用。
dubbo-provider端的accesslog日志信息，明显不足，连耗时，执行是否成功等信息都没有，例如：一个请求异常，也会记录一条和正常请求类似的日志记录。

二、我们参考当当dubbox，让dubbo支持rest，发现其性能比springmvc的rest至少低30%；且consumer端不支持注解方式引入。

rest方式便于开发、联调和服务升级，在dubbo中性能并不比rpc差很多，具体可以参考 dubbo用户指南 中的测试结果。而且可以通过nginx一些插件，不强制客户端也使用dubbo，易于兼容老站点和推广。

 三、dubbo不是个完善的服务治理框架，尤其是监控这块【缺少hystrix|turbine、sleuth类似的分布式跟踪与分析工具】，当然主要原因是好多年没大版本更新了，也哟开源社区对dubbo支持不够的原因，很多服务治理的模块没有或不完善， 例如：服务网关、熔断器、分布式跟踪、分布式配置、分布式事务等。