SpringCloud和Dubbo都是当下流行的RPC框架，各自都集成了服务发现和治理组件。SpringCloud用Eureka做注册中心，Dubbo用Zookeeper注册中心。
注册服务
Dubbo是基于java接口及Hession2序列化的来实现传输的，Provider对外暴露接口，Consumer根据接口的规则调用。也就是Provider向Zookeeper注册的是接口信息，Consumer从Zookeeper发现的是接口的信息，通过接口的name，group，version来匹配调用。Consumer只关注接口是否匹配，而对此接口属于什么应用不关心。当然接口的注册信息里会包含应用的ip，hostname等。
SpringCloud的服务发现是基于Http协议来实现的，Provider对外暴露的是应用信息，比如应用名称，ip地址等等，Consumer发现的是应用的信息，当调用的时候随机选择一个Provider的IP地址，应用名称，然后依据Http协议发送请求。Consumer关注的是应用名称，根据应用名称来决定调用的是哪个服务集群，然后对此名称对应的服务集群做负载均衡。Provider接受到请求后，根据内置的SpringMVC来匹配路由处理请求。
SpringCloud是一套目前比较网站微服务框架了，整合了分布式常用解决方案遇到了问题注册中心Eureka、负载均衡器Ribbon ，客户端调用工具Rest和Feign，分布式配置中心Config，服务保护Hystrix，网关Zuul Gateway，服务链路Zipkin，消息总线Bus等。
从架构上分析
Dubbo内部实现功能没有SpringCloud强大，只是实现服务治理，缺少分布式配置中心、网关、链路、总线等，如果需要用到这些组件，需要整合其他框架。
从更新迭代速度分析
Dubbo目前更新速度没有SpringCloud快，到SpringCloud2.0后SpringCloud会越来完善和稳定。
从开发背景角度分析
Dubbo的开发背景是阿里巴巴， 在中国也推出了非常多的优秀的开源框架
但是在SpringCloud的背景是Spring家族，Spring是专注于企业级开源框架开发，在中国，或者在整个世界上Spring框架都应用的非常广泛。所有相对来说SpringCloud的背景比Dubbo更加强大。
最后总结下：如果学习Dubbo的话，学习其他的分布式解决方案需要自己组装，反而如果学习SpringCloud，它已经把整个常用分布式解决都整合好了。
Server集群服务信息同步的区别
Dubbo使用Zookeeper做服务发现和治理，Zookeeper是一个分布式协调框架，其有很多很实用的功能，服务发现仅仅是其中的一个。Zookeeper基于著名的CAP理论中的C(一致性)，P(分区可用性)实现，它的ZAB（zookeeper atomic broadcast protocol）协议，保证了集群里状态的一致性。Client的每一个事务操作都由Leader广播给所有Follower，当超过半数的Follower都返回执行成功后，才执行事务的ack。对于因网络崩溃或者宕机等问题而执行失败的zookeeper节点，zookeeper会基于zab的崩溃恢复机制来处理，这里不再讲述。每一个操作都需要过半数的zookeeper节点执行成功才确认成功，那么当zookeeper集群过半数节点出现问题时，服务发现功能就不可用。
SpringCloud使用Eureka做服务发现和治理，它是一个专门用于服务发现和治理的框架，其基于CAP理论中的A(可用性)，P(分区可用性)实现。EurekaServer节点间的服务信息同步是基于异步Http实现的。每隔Server节点在接收Client的服务请求时，立即处理请求，然后将此次请求的信息拷贝，封装成一个Task，存入Queue中。Server初始化时会启动一个线程定期的从TaskQueue中批量提取Task，然后执行。服务同步不保证一定成功，虽然有失败重试，但超过一定时限后就放弃同步。当然其有一个特性，当服务丢失后，同步的操作返回400，404后会立即将最新的服务信息同步过去，因此即使中途同步失败，不会对后续的同步有影响。
服务更新机制的区别
Dubbo使用Zookeeper做服务发现和治理，订阅Zookeeper下相应的znode。当节点发生变化，比如有新的元素增加，或者旧的元素移除，Zookeeper会通知所有订阅此节点的Client，将当前的全量数据同步给各Client，Dubbo里根据最新的数据来做相应处理，移除下线的，初始化新增的。每次更新都同步全量数据。
Eureka在启动时向Server进行一次全量拉取，获取所有的可用服务信息，之后默认情况下都是进行增量拉取。Server会将有变化的服务信息放在一个Queue里，Client每次同步时仅获取增量信息，根据信息里的操作类型，服务信息来对当前持有的服务做相应的处理，移除下线的，初始化新增的等。每次更新仅同步增量数据，也就是更新的数据。
服务更新反馈机制的区别
Dubbo订阅Zookeeper下相应的节点，当节点的状态发生改变时，Zookeeper会立即反馈订阅的Client，实时性很高。
Eureka Server在接收到Client的更新操作，或者移除服务信息时，仅仅会将更新消息存放入recentlyChangedQueue中，不会主动的反馈其他Client。其他Client只有在拉取服务增量信息时才会感知到某个服务的更新，延时最大为30S，也就是拉取周期。
服务信息回收机制的区别
Dubbo Provider初始化时会创建一个Zookeeper Client，专门用于与Zookeeper集群交互。维持与集群间的长连接，定时发送心跳，维护Zookeeper上自身节点的存在。节点类型是临时节点，也就是当心跳超时或者长连接断开时，会立即移除Provider对应的节点。
Dubbo Consumer初始化时也会创建一个Zookeeper Client，专门用于与Zookeeper集群交互。维持长连接，创建EvenetListener，监听Provider节点的变动情况。当Provider节点新增或者移除时，Zookeeper会广播这个事件，然后将此节点的当前值(剩下的所有接口信息)发送给那些注册了此节点监听器的Client。Consumer获取到对应Provider节点下的所有接口信息后，移除已下线的，创建新增的。
Zookeeper对服务信息的维护实时性和一致性比较高，但也可能因为网络问题或者集群问题导致服务不可用。
SpringCloud的服务信息回收仅基于心跳超时，与长连接无关。当心跳超时后，EurekaServer回收服务信息，然后将此动作同步给其他Server节点。当然可能一个服务信息会存在多个Server上，多次回收操作的同步具备幂等性。也就是说服务回收只需要通知一个Server节点就可以了，回收动作会通过Server节点传播开来。EurekaServer能够回收服务信息由个重要前提：上一分钟内正常发送心跳的服务的比列超过总数的85%，如果因为网络波动等原因造成大量服务的心跳超时，那么EurekaServer会触发自我保护机制，放弃回收那些心跳超时的服务信息。服务发现组件应该优先保证可用性，Consumer能够发现Provider，即使发现的是非可用的Provider，但因为Conusmer一般具备容错机制，不会对服务的正常调用有太多影响。从这点上看Eureka的服务发现机制要比Zookeeper稍微合理一点的。
节点性质的区别
Dubbo只有Consumer订阅Provider节点，也就是Consumer发现Provider节点信息
Eureka不区分Consumer或者Provider，两者都统称为Client，一个Client内可能同时含有Provider，Consumer，通过服务发现组件获取的是其他所有的Client节点信息，在调用时根据应用名称来筛选节点
使用方式的区别
Dubbo使用Zookeeper作为服务发现和治理的组件，所以需要搭建Zookeeper集群作为依赖。
SpringCloud使用Eureka作为服务发现和治理组件，在Spring应用中整合Eureka还是很简单的，引入依赖，加个注解，指定集群Server的serviceUrl，其他的都可以使用默认配置即可，启动应用，Eureka集群就搭建好了。同时配合SpringCloudConfg，能够统一管理Eureka的集群配置信息，可以动态的增加或减少EurekaServer的集群节点。Eurerka会每隔15分钟根据配置上的集群信息重新生成集群节点，覆盖之前的。这种机制比Zookeeper要更优秀一些，毕竟Eureka算是Spring生态里的一环，已经被整合的非常好了，能够以很多匪夷所思的方式来使用。
来源：CSDN
作者：程序员杂谈
链接：https://blog.csdn.net/q947448283/article/details/103592662