SpringCloud 和 dubbo的区别

SpringCloud 和 dubbo的区别

• 初始定位不同：SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA
  时代的产物，它的关注点主要在于服务的调用和治理
• 生态环境不同：SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
• 调用方式：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。
• 组件差异比较多，例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper

1.SpringCloud和DUbbo ，从别人做的实现来看，dubbo的性能大约是SpringCloud的3倍

1.Spring Cloud 的功能很明显比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的旗舰项目，它也能够与 Spring Framework、Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合，这些对于微服务而言是至关重要的。

使用 Dubbo 构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果使用者是一名高手，那这些都不是问题。

而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。

2.Feign是SpringCloud中的远程调用方式，基于成熟Http协议，所有接口都采用Rest风格。因此接口规范更统一，而且只要符合规范，实现接口的微服务可以采用任意语言或技术开发。但受限于http协议本身的特点，请求和响应格式臃肿，其通信效率相对会差一些。

Dubbo框架默认采用Dubbo自定义通信协议，与Http协议一样底层都是TCP通信。但是Dubbo协议自定义了Java数据序列化和反序列化方式、数据传输格式，因此Dubbo在数据传输性能上会比Http协议要好一些。

不过这种性能差异除非是达极高的并发量级，否则无需过多考虑。

2.底层实现的协议不同

由于Spring Cloud与Dubbo天生使用的协议层面不一样，前者是HTTP，后者是TCP(使用的是Netty NIO框架，序列化使用的阿里定制版Hessian2)，导致两个框架的性能差距略大

3.两者使用的注册中心不同

Spring Cloud 使用的 eureka dubbo推荐使用zookeeperZooKeeper：

zookeeper保证了cp(一致性、分区容错性)，但是作为服务注册中心，我们可以容忍注册中心返回的是几分钟以前的注册信息。但是服务中心却必须保证可用性，
即服务注册中心对于高可用性的需求高于一致性。对于可用性，zookeeper有一个leader选举方案。当master主节点宕机与其他节点失去联系时，其他节点会重
新进行Leader选举，选出新的master节点。然而选举耗时过长，一般为30~120S，并且整个选举期间，整个zookeeper集群是无法使用的。

Eureka：
eureka保证了ap(可用性、分区容错性)，eureka每一个节点都是平等的，几个节点宕机不会影响正常节点的工作。剩余的正常节点依旧可以提供服务注册和查询。
并且，当客户端向某节点注册服务时，注册失败或者超时，则会自动切换到其他节点。只要有一台eureka节点还正常工作，就能保证注册服务的可用。但是对于服
务信息的同步则不能保证一致性(不能保证强一致性，但是最终一致)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内85%的节点都没有正常心跳(不可用)
那么Eureka就认为客户端与注册中心之间出现了网络故障，此时会出现以下几种情况：
1、Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2、Eureka仍然能够接收新服务的注册和查询请求，但是不会被同步到其他节点上(保证当前节点的可用性)
3、当网络稳定后，当前实例新注册的服务会被同步到其他节点

因此,Eureka能够保证注册中心的高可用性，而不会像zookeeper一样直接集群瘫痪