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一样直接集群瘫痪