Dubbo 与springcloud的区别？

服务调用方式的区别（最大区别）：

• dubbo是RPC框架下的通信
• springcloud 是HTTP协议的Rest Api

Dubbo框架相比Rest Api服务调用的缺点：

① 服务提供方和调用方耦合性太高。
Dubbo框架下一个服务大致需要经历：服务---->对应的抽象接口---->项目仓库 的过程，然后才能被调用方所调用，因此整个项目对版本控制比较严格。
Rest接口相比RPC更为轻量化，服务提供方和调用方只需一个Api即可，没有代码的高耦合。当然REST接口也有缺点，因为接口定义过轻，很容易导致接口文档与实际所展现功能不一致导致服务集成时的问题，但是该问题可以通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。
② 服务的复用性
Rest接口提供对外服务时，以REST的方式提供出去，这样便可以实现跨平台的特点，提高服务的复用性。
Dubbo中要提供Rest接口时，需要实现一层代理，用来将RPC接口转换成Rest接口进行对外发布。

服务注册中心的区别：

• dubbo 是zookeeper
• springcloud是eureka（也可以是zookeeper）

其他功能实现的区别：

Eureka和ZooKeeper的区别？

Eureka保证AP(高可用、分区容错性)

Eureka的各个节点都是平等的，即挂掉几个节点是不会影响整个服务的功能。当Eureka客户端向某个节点发送连接请求失败时，会自动切换到其他节点，即只要一台Eureka节点正常工作，就可以保证注册服务可用，但查询到的服务信息可能不是最新的（不保证强一致性）。
Eureka的自我保护机制：
15分钟内超过85%的节点没有正常心跳时，Eureka会认为客户端与注册中心出现了网络故障，此时情况可能是：

• Eureka不再移除过期的服务（长时间没有收到心跳的服务）
• Eureka仍然可以接受新服务的注册和查询请求，但不会同步到其他节点上（保证当前节点的可用性）
• 故障消除后，当前新服务的注册信息会被同步到其他节点上

Zookeeper保证CP（一致性、分区容错性）

当master节点因为网络故障等情况与其他节点失去联系时，剩余的节点会重新进行leader选举。整个选举过程在30-120s，且整个选举期间整个Zookeeper集群是不可用的，即选举期间注册服务瘫痪。