Spring Cloud is http transmission protocol, the bandwidth will be more while using the http protocol typically use JSON messages, consumption will be greater
dubbo of development more difficult, because the jar package dependencies dubbo many large projects can not be solved
springcloud interface agreement relatively free and loose, requires strong administrative measures to restrict the interface disorderly upgrade
dubbo registries can choose a variety zk, redis, etc., springcloud the registry can only be used eureka or self-study
But if I choose, I will use Spring Cloud.
From the company's overall plan: I would not choose long unmaintained dubbo, then restart it may not be the same team
From a programmer recruitment difficulty: Dr. springcloud recruit programmers will be better, because fancier update
From the system configuration summary: springcloud simpler system configuration, "registration + springmvc = springcloud", and the complex Dubbo Url, protocol, register, invocation, dubbofilter, dubboSPI, dubbo serialization ........ .. virtuoso composition of some more
From a performance: dubbo network consumes less than springcloud, but in 95% of the domestic companies, network overhead is not a big problem, if it became a problem, through compression, binary, cache, segmentation demotion and other methods, it is easy to solution
From the development of difficulty: dubbo God pit is dependent jar package, the development stage is extremely difficult, I once took a team of thirty people, because the jar package upgrade issues, to everyone's computers are operated, especially everybody computer library path, commands, shortcuts, keyboard, mouse speed is not the same, I had never been seen silently in the hearts of the dubbo Lv inventor whole family one hundred and twenty times.
springcloud more freedom, but the problem is not caused by "strong constraint Interface Specification," suggesting solved by administrative means, and we have a strong team of administrative constraints do still better, more powerful interface control level, with no administrative organization the ability of the IT team is really a waste, what is not so that frame.
From the subsequent improvement: dubbo improvement is through dubbofilter, a lot of things do not need their own inheritance, such as monitoring, such as log, such as current limiting, such as tracking. springcloud himself with a lot of monitoring, limiting measures, but European and American habits and may function the same, the need for appropriate domestic reform, but more simple, that is ServletFilter it, but it is always better than something more than dubbo
From supporting measures: springcloud has always claimed that he is "a set all aspects of the solution." . . . . . I initially believed, but later found fooled, to be honest: Yes, but not very sound, 100 points playing like 50, you still need a lot of renovation.
Focus on micro-channel public number: Java technology stack in the background reply: cloud, I can sort of get the latest articles N Spring Cloud tutorials are dry.
And contrary DUBBO, has been claimed to be "a full-service aspects of the scheme." . . . . .
Pure service of the top bird with any supporting systems are complementary, a complete system, have a front, middle, back, front including front-end and interactive, including trading in Taiwan, tasks, data, including financial background, account management ........... purely as a service can not solve "any problem", the only system to resolve.
At this level, springcloud toward a "system" of development programs, and dubbo only a tool only, compared to the difference between the two is like than Archeopteryx and paramecium.
From the technical strength levels: the contrast between the two sides source, authors have to say dubbo technical capabilities than springCloud, and the author of the technical capacity springBoot than dubbo.
Namely: springboot> dubbo> springcloud. I like springboot this Road to Jane style, keep it simple and stupid.
The dubbo Okay ...... you look dubboSPI, look at Protocol $ Adpative there that a group of around a few blind stuff going around, you'll quickly determine: Cock wire in these virtuoso .
Although dubbo divided into ten layers forty to fifty components from below, the first sense is good Wase comprehensive look so great, but after that you will find in-depth, this technology is stunning, the design is indeed very comprehensive, but with less than, for example: the god please explain to me, in the zookeeper addresses, separated by commas and semicolons using the difference between separate addresses. . . . .
Not use, but the code for this comes to an "entirely different" from a branch. Use this proverb evaluation is "bloated and too many useless code in the document also have to say this to 123456 to."
Having dubbo say springCloud ........ it no technical content, no, that is a bunch of simple components assembled together, such as configserver, eurekaserver, robin, feignClient, htstrix, etc., each of which is particularly simple, no technical content, but I like this, just like the Road to Jane's simple.
Finally say springBoot, I use "pure" word to evaluate this framework, it is really pure, and its purity, neat specific module of the general idea of the consistency of the code architecture, objectives, and indeed is a good framework, worth a read.
From the system application level: in the eyes of the technical strength of 85 points out of one hundred play the humble servant, dubbo and springcloud, not that the two frame it? We are going to save the world's people, and maybe a round piece of block cobblestone square, to the foot pad on the line, there is no difference.
In short, Dubbo indeed similar to a subset of the Spring Cloud, improve function and Dubbo document, in the country there are a lot of mature users, however, in view of the current situation Dubbo community (who maintain long-term suspension, July 31, 2017 and the team Declaring maintenance), or to use a certain threshold.
Dubbo has scheduling, discovery, monitoring, management and other functions, support a rich service management capabilities. Under Dubbo architecture, registry peer cluster, and caching service will continue to provide the list has been found to function when the database fails, the service found that the structure itself has a strong availability and robustness, enough to support high-traffic sites.
Although short Dubbo support large data connection service delivery model, but in most cases are the usage patterns long connection small amount of data used to provide services.
所以，对于类似于电商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言，Dubbo 确实是一个可以考虑的选择。
但如果产品业务中由于后台业务逻辑复杂、时间长而导致异步逻辑比较多的话，可能Dubbo 并不合适。同时，对于人手不足的初创产品而言，这么重的架构维护起来也不是很方便。
Spring Cloud由众多子项目组成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系统及微服务常用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案。
比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现（Eureka）、智能路由（Zuul）、客户端负载均衡（Ribbon）。
但它并没有重复造轮子，而是选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架（我们需要特别感谢Netflix ，这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡献给了社区，Spring Cloud主要是对Netflix开源组件的进一步封装），通过Spring Boot 进行封装集成并简化其使用方式。
基于Spring Boot，意味着其使用方式如Spring Boot 简单易用；能够与Spring Framework、Spring Boot、Spring Data 等其他Spring 项目完美融合，意味着能从Spring获得巨大的便利，意味着能减少已有项目的迁移成本。
关注微信公众号：Java技术栈，在后台回复：boot，可以获取我整理的 N 篇最新Spring Boot 教程，都是干货。
其实，从社区活跃度和功能完整度，再对照业务需求和团队状况，基本可以确定如何选型。这里分享网易考拉海购实践以及团队选型的心声：
当前开源上可选用的微服务框架主要有Dubbo、Spring Cloud等，鉴于Dubbo完备的功能和文档且在国内被众多大型互联网公司选用，考拉自然也选择了Dubbo作为服务化的基础框架。
提起Spring Cloud，一些开发的第一印象是http+JSON的rest通信，性能上难堪重用，其实这也是一种误读。
微服务选型要评估以下几点：内部是否存在异构系统集成的问题；备选框架功能特性是否满足需求；http协议的通信对于应用的负载量会否真正成为瓶颈点（Spring Cloud也并不是和http+JSON强制绑定的，如有必要Thrift、protobuf等高效的RPC、序列化协议同样可以作为替代方案）；社区活跃度、团队技术储备等。
作为已经没有团队持续维护的开源项目，选择Dubbo框架内部就必须要组建一个维护团队，先不论你要准备要集成多少功能做多少改造，作为一个支撑所有工程正常运转的基础组件，问题的及时响应与解答、重大缺陷的及时修复能力就已足够重要。
鉴于服务发现对服务化架构的重要性，再补充一点：Dubbo 实践通常以ZooKeeper 为注册中心（Dubbo 原生支持的Redis 方案需要服务器时间同步，且性能消耗过大）。
针对分布式领域著名的CAP理论（C——数据一致性，A——服务可用性，P——服务对网络分区故障的容错性），Zookeeper 保证的是CP ，但对于服务发现而言，可用性比数据一致性更加重要 ，而 Eureka 设计则遵循AP原则 。
为什么选择使用Spring Cloud而放弃了Dubbo？
可能大家会问，为什么选择了使用Dubbo之后，而又选择全面使用Spring Cloud呢？其中有几个原因：
1）从两个公司的背景来谈：Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；Spring Cloud是大名鼎鼎的Spring家族的产品。
阿里巴巴是一个商业公司，虽然也开源了很多的顶级的项目，但从整体战略上来讲，仍然是服务于自身的业务为主。Spring专注于企业级开源框架的研发，不论是在中国还是在世界上使用都非常广泛，开发出通用、开源、稳健的开源框架就是他们的主业。
2）从社区活跃度这个角度来对比，Dubbo虽然也是一个非常优秀的服务治理框架，并且在服务治理、灰度发布、流量分发这方面做的比Spring Cloud还好，除过当当网在基础上增加了rest支持外，已有两年多的时间几乎都没有任何更新了。在使用过程中出现问题，提交到github的Issue也少有回复。
相反Spring Cloud自从发展到现在，仍然在不断的高速发展，从github上提交代码的频度和发布版本的时间间隔就可以看出，现在Spring Cloud即将发布2.0版本，到了后期会更加完善和稳定。
3) 从整个大的平台架构来讲，dubbo框架只是专注于服务之间的治理，如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中使用dubbo的难度就会增加。Spring Cloud几乎考虑了服务治理的方方面面，更有Spring Boot这个大将的支持，开发起来非常的便利和简单。
4）从技术发展的角度来讲，Dubbo刚出来的那会技术理念还是非常先进，解决了各大互联网公司服务治理的问题，中国的各中小公司也从中受益不少。
经过了这么多年的发展，互联网行业也是涌现了更多先进的技术和理念，Dubbo一直停滞不前，自然有些掉队，有时候我个人也会感到有点可惜，如果Dubbo一直沿着当初的那个路线发展，并且延伸到周边，今天可能又是另一番景象了。
Spring 推出Spring Boot/Cloud也是因为自身的很多原因。Spring最初推崇的轻量级框架，随着不断的发展也越来越庞大，随着集成项目越来越多，配置文件也越来越混乱，慢慢的背离最初的理念。
With so many years of development, micro-services, the emergence of more new technology concepts of distributed link tracking, Spring urgent need to improve the framework of a previous development model, so Spring Boot / Cloud projects to appear, we now have access to Spring's official website, you will find Spring Boot and Spring Cloud has been put before the two, we can see the degree of attention Spring framework of these two projects home three most focused in.
To summarize, dubbo ever really fast hardware, but Spring Cloud is standing on top of technological developments in recent years to develop, so the more technical representative.
spring cloud machine, dubbo need to assemble their own; overall performance is guaranteed, the assembly of the machine more freely.