SpringCloud和Dubbo的区别SpringCloud和Dubbo的区别是什么？
这两个都是当前主流的微服务框架，但存在许多差异：
初始定位不同： SpringCloud被定位为微服务体系结构下的一站式解决方案； Dubbo是SOA时代的产物，其关注点主要在于服务调用和管理生态环境的差异。 SpringCloud依托Spring平台，具备更完善的生态体系； 另一方面，Dubbo最初只是远程调用RPC，生态比较匮乏，现在变得富裕了。 呼叫方式： SpringCloud采用Http协议进行远程呼叫，接口一般为rest风格，比较灵活； Dubbo采用了Dubbo协议，接口一般是Java的服务接口，格式是固定的。 但是，如果采用Netty的NIO方式，性能会很好。 组件差异很多。 例如，SpringCloud注册中心一般使用Eureka，而dubbo zookeeper spring cloud生态丰富，功能齐全，像品牌机。 Dubbo比较灵活，定制性强，像组装机。
相关资料：
http://www.Sina.com/:在spring公司的开源微服务框架中，SpirngCloud被定位为微服务体系结构下的一站式解决方案。
SpringCloud:阿里巴巴开源RPC框架。 Dubbo是SOA时代的产物，主要关注服务调用、流量分发、流量监控和熔断
SpringCloudAlibaba
两者的生态对比：
功能DubboSpringCloud服务注册中心ZookeeperEureka (主流)、控制台、 zookeeper服务调用方式RPC基于Dubbo协议REST API基于Http协议服务监视Dubbo-MonitorSpring Boot Admin保险丝的不完整的spring cloud Netflix hy striris 云Netflix zuul，网关分布式配置Spring Cloud Config无服务跟踪Spring Cloud Sleuth Zipkin (常规) 无数据流Spring Cloud Stream无批量任务Spring Cloud Task无信息总线Spring Cloud BusSpring Cloud的功能明显强于Dubbo、覆盖面广、Spring标志还可以与其他Spring项目(如Spring框架、Spring Boot、Spring Data和Spring Batch )完美融合，它们对微服务至关重要。
使用Dubbo构建的微服务架构就像组装电脑一样，每个阶段的选择自由度都很高，但最终一个内存的质量差很可能就消失，总是让人不安，只要用户是pbdts，这些都不是问题
另一方面，Spring Cloud就像一台品牌机器，在Spring Source集成下进行了大量的兼容性测试，确保了机器的稳定性，但要使用非原始组件以外的其他组件，必须充分理解其基础原理
Dubbo和Feign远程调用的区别Feign是一种SpringCloud远程调用方法，基于成熟的Http协议，所有接口都采用rest风格。 因此，接口的规格更加统一，只要符合规格，实现接口的微服务就可以使用任意语言和技术进行开发。 但受http协议自身特点的限制，要求和响应格式不断增加，其通信效率相对较差。
Dubbo框架默认采用Dubbo定制通信协议，与Http协议一样，基础是TCP通信。 但是，由于Dubbo协议自定义了Java的数据序列化、反序列化和数据传输格式，因此Dubbo的数据传输性能稍优于Http协议。
但是，除非是非常高的并发级别，否则这种性能差异不需要考虑太多。
Dubbo
Dubbo是使用自定义的Dubbo协议实现远程通信的典型的RPC调用方式，SpringCloud中使用的Feign是基于rest风格的调用方式。
1 ) rest风格
REST是一种架构样式，指一组架构约束和原则。 符合这些约束和原则的APP应用程序或设计就是rest风格。
Rest的样式完全可以通过HTTP协议实现，使用HTTP协议处理数据通信。 REST架构中对资源的操作包括获取、创建、修改和删除资源。 这正好对应于HTTP协议提供的GET、POST、PUT和DELETE方法。
因此，请求和期望过程只需遵循http协议，就更灵活了
SpringCloud的Feign是rest风格的调用方法。
2 ) RPC
远程过程调用、远程过程调用是指调用远程方法，就像调用本地方法一样。
RPC一般需要确保：
数据传输方式：很多RPC框架选择TCP作为传输协议，性能较好。 数据传输内容：请求方需要知道应调用函数的名称、参数等信息。 序列化方案：在客户端和服务端交互时将参数或结果转换为字节流并通过网络传输，然后将数据转换为字节流或字节流
换成能读取的固定格式时就需要进行序列化和反序列化因为有序列化和反序列化的需求，因此对数据传输格式有严格要求，不如Http灵活
Dubbo协议就是RPC的典型代表。
我们看看Dubbo协议和Feign的调用区别：
DubboFeign（Http调用）传输协议TCPTCP开发语言java不限性能好一般灵活性一般好Eureka和Zookeeper注册中心的区别
SpringCloud和Dubbo都支持多种注册中心，不过目前主流来看SpringCloud用Eureka较多，Dubbo则以Zookeeper为主。两者存在较大的差异：
从集群设计来看：Eureka集群各节点平等，没有主从关系，因此可能出现数据不一致情况；ZK为了满足一致性，必须包含主从关系，一主多从。集群无主时，不对外提供服务CAP原则来看：Eureka满足AP原则，为了保证整个服务可用性，牺牲了集群数据的一致性；而Zookeeper满足CP原则，为了保证各节点数据一致性，牺牲了整个服务的可用性。服务拉取方式来看：Eureka采用的是服务主动拉取策略，消费者按照固定频率（默认30秒）去Eureka拉取服务并缓存在本地；ZK中的消费者首次启动到ZK订阅自己需要的服务信息，并缓存在本地。然后监听服务列表变化，以后服务变更ZK会推送给消费者。相关资料：
首先，Eureka和Zookeeper都是服务治理框架，但是设计上有一定的差别。
先看下CAP原则：C-数据一致性；A-服务可用性；P-服务对网络分区故障的容错性，这三个特性在任何分布式系统中不能同时满足，最多同时满足两个。
Eureka满足AP，Zookeeper满足CP
当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是Zookeeper和Eureka在一致性与可用性间做出了不同的选择。
Zookeeper：Zookeeper的设计追求数据的一致性，不保证服务的可用性。当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。
Eureka：Eureka追求的是服务的可用性，从而牺牲了数据的一致性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况。
Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)当网络稳定时，当前实例新的注册信息会被同步到其它节点中因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。
Eureka集群各节点平等，Zookeeper中有主从之分
如果Zookeeper集群中部分宕机，可能会导致整个集群因为选主而阻塞，服务不可用eureka集群宕机部分，不会对其它机器产生影响Eureka的服务发现需要主动去拉取，Zookeeper服务发现是监听机制
eureka中获取服务列表后会缓存起来，每隔30秒重新拉取服务列表zookeeper则是监听节点信息变化，当服务节点信息变化时，客户端立即就得到通知