Dubbo和springcloud对cap理论的践行：
Dubbo 实践通常以ZooKeeper 为注册中心（Dubbo 原生支持的Redis 方案需要服务器时间同步，且性能消耗过大）。针对分布式领域著名的CAP理论（C——数据一致性，A——服务可用性，P——服务对网络分区故障的容错性），Zookeeper 保证的是CP ，但对于服务发现而言，可用性比数据一致性更加重要 ，而 Eureka 设计则遵循AP原则
spring-cloud和dubbo的区别
dubbo由于是二进制的传输，占用带宽会更少（基于netty等）
springCloud是http协议传输，带宽会比较多，同时使用http协议（http+restful api）一般会使用JSON报文，消耗会更大。
http协议的通信对于应用的负载量会否真正成为瓶颈点（Spring Cloud也并不是和http+JSON强制绑定的，如有必要Thrift、protobuf等高效的RPC、序列化协议同样可以作为替代方案）
dubbo的开发难度较大，原因是dubbo的jar包依赖（存在代码级别的强依赖）问题很多大型工程无法解决
springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级
dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研
从系统结构简易程序：
.cloud程序结构简单，“springMVC+注册”=spring-cloud
.dubbo相对复杂，Url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo序列化
从性能：
dubbo网络开销略小于cloud，但是可以通过压缩、二进制、高速缓存、分段降级等方法解决
开发难易度：
dubbo的神坑是jar包依赖，开发阶段难度极大，jar升级是大问题
springcloud比较自由，但带来的问题是无法“强力约束接口规范”，建议用行政方式解决
后续改进：
dubbo的改进是通过dubbofilter，很多东西没有，需要自己继承，如监控，如日志，如限流，如追踪。
springcloud具有配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案
参考博客
1.【http://342104628.iteye.com/blog/2409218】分别谈了dubbo和springcloud的区别
