Spring Cloud和Dubbo的区别

1.SpringCloud和Dubbo

SpringCloud和Dubbo都是现在主流的微服务架构

• SpringCloud是Apache旗下的Spring体系下的微服务解决方案
• Dubbo是阿里系的分布式服务治理框架

  从技术维度上,其实SpringCloud远远的超过Dubbo,Dubbo本身只是实现了服务治理,而SpringCloud现在以及有21个子项目，以后还会更多，所以其实很多人都会说Dubbo和SpringCloud是不公平的，但是由于RPC以及注册中心元数据等原因,在技术选型的时候我们只能二者选其一,所以我们常常为用他俩来对比服务的调用方式Dubbo使用的是RPC远程调用,而SpringCloud使用的是 Rest API, 其实更符合微服务官方的定义服务的注册中心来看,Dubbo使用了第三方的ZooKeeper作为其底层的注册中心,实现服务的注册和发现,Spring Cloud使用Spring Cloud Netflix Eureka实现注册中心,当然SpringCloud也可以使用ZooKeeper实现,但一般我们不会这样做。服务网关,Dubbo并没有本身的实现,只能通过其他第三方技术的整合,而SpringCloud有Zuul路由网关,作为路由服务器,进行消费者的请求分发,SpringCloud还支持断路器,与git完美集成分布式配置文件支持版本控制,事务总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素

2.Rest和RPC对比

  其实如果仔细阅读过微服务提出者马丁福勒的论文的话可以发现其定义的服务间通信机制就是Http Rest。RPC最主要的缺陷就是服务提供方和调用方式之间依赖太强,我们需要为每一个微服务进行接口的定义,并通过持续继承发布,需要严格的版本控制才不会出现服务提供和调用之间因为版本不同而产生的冲突而REST是轻量级的接口,服务的提供和调用不存在代码之间的耦合,只是通过一个约定进行规范,但也有可能出现文档和接口不一致而导致的服务集成问题,但可以通过swagger工具整合,是代码和文档一体化解决,所以REST在分布式环境下比RPC更加灵活这也是为什么当当网的DubboX在对Dubbo的增强中增加了对REST的支持的原因

3.注册的服务的区别

  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来匹配路由处理请求。

4.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后会立即将最新的服务信息同步过去，因此即使中途同步失败，不会对后续的同步有影响。

5.服务更新机制的区别

  Dubbo使用Zookeeper做服务发现和治理，订阅Zookeeper下相应的znode。当节点发生变化，比如有新的元素增加，或者旧的元素移除，Zookeeper会通知所有订阅此节点的Client，将当前的全量数据同步给各Client，Dubbo里根据最新的数据来做相应处理，移除下线的，初始化新增的。每次更新都同步全量数据。

  Eureka在启动时向Server进行一次全量拉取，获取所有的可用服务信息，之后默认情况下都是进行增量拉取。Server会将有变化的服务信息放在一个Queue里，Client每次同步时仅获取增量信息，根据信息里的操作类型，服务信息来对当前持有的服务做相应的处理，移除下线的，初始化新增的等。每次更新仅同步增量数据，也就是更新的数据。

6.服务更新反馈机制的区别

  Dubbo订阅Zookeeper下相应的节点，当节点的状态发生改变时，Zookeeper会立即反馈订阅的Client，实时性很高。

  Eureka Server在接收到Client的更新操作，或者移除服务信息时，仅仅会将更新消息存放入recentlyChangedQueue中，不会主动的反馈其他Client。其他Client只有在拉取服务增量信息时才会感知到某个服务的更新，延时最大为30S，也就是拉取周期。

7.服务信息回收机制的区别

  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稍微合理一点的。

8.节点性质的区别

  Dubbo只有Consumer订阅Provider节点，也就是Consumer发现Provider节点信息

  Eureka不区分Consumer或者Provider，两者都统称为Client，一个Client内可能同时含有Provider，Consumer，通过服务发现组件获取的是其他所有的Client节点信息，在调用时根据应用名称来筛选节点

9.使用方式的区别

  Dubbo使用Zookeeper作为服务发现和治理的组件，所以需要搭建Zookeeper集群作为依赖。

  SpringCloud使用Eureka作为服务发现和治理组件，在Spring应用中整合Eureka还是很简单的，引入依赖，加个注解，指定集群Server的serviceUrl，其他的都可以使用默认配置即可，启动应用，Eureka集群就搭建好了。同时配合SpringCloudConfg，能够统一管理Eureka的集群配置信息，可以动态的增加或减少EurekaServer的集群节点。Eurerka会每隔15分钟根据配置上的集群信息重新生成集群节点，覆盖之前的。这种机制比Zookeeper要更优秀一些，毕竟Eureka算是Spring生态里的一环，已经被整合的非常好了，能够以很多匪夷所思的方式来使用。

10.技术选型

  目前国内的分布式系统选型主要还是Dubbo毕竟国产,而且国内工程师的技术熟练程度高,并且Dubbo在其他维度上的缺陷可以由其他第三方框架进行集成进行弥补而SpringCloud目前是国外比较流行,当然我觉得国内的市场也会慢慢的偏向SpringCloud,就连刘军作为Dubbo重启的负责人也发表过点,Dubbo的发展方向是积极适应SpringCloud生态,并不是起冲突。

11.文档质量和社区活跃度

  SpringCloud社区活跃度远高于Dubbo,毕竟由于梁飞团队的原因导致Dubbo停止更新迭代五年,而中小型公司无法承担技术开发的成本导致Dubbo社区严重低落,而SpringCloud异军突起,迅速占领了微服务的市场,背靠Spring混的风生水起，Dubbo经过多年的积累文档相当成熟,对于微服务的架构体系各个公司也有稳定的现状

二.SpringBoot和SpringCloud

  SpringBoot是Spring推出用于解决传统框架配置文件冗余,装配组件繁杂的基于Maven的解决方案,旨在快速搭建单个微服务而SpringCloud专注于解决各个微服务之间的协调与配置,服务之间的通信,熔断,负载均衡等技术维度并相同,并且SpringCloud是依赖于SpringBoot的,而SpringBoot并不是依赖与SpringCloud,甚至还可以和Dubbo进行优秀的整合开发

总结:

• SpringBoot专注于快速方便的开发单个个体的微服务
• SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,配置管理,服务发现,断路器,路由,事件总线等集成服务
• SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot,属于依赖关系
• SpringBoot专注于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架

三.Eureka和ZooKeeper都可以提供服务注册与发现的功能,两个的区别

1.ZooKeeper保证的是CP,Eureka保证的是AP

• ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的
• Eureka各个节点是平等关系,只要有一台Eureka就可以保证服务可用,而查询到的数据并不是最新的
• ZooKeeper有Leader和Follower角色,Eureka各个节点平等
• ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题
• Eureka本质上是一个工程,而ZooKeeper只是一个进程

自我保护机制会导致

• Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务
• Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点(高可用)
• 当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)
  Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper一样使得整个注册系统瘫痪

四.微服务之间是如何独立通讯的

远程过程调用（Remote Procedure Invocation）
也就是我们常说的服务的注册与发现直接通过远程过程调用来访问别的service。
优点：

• 简单，常见,因为没有中间件代理，系统更简单

缺点：

• 只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应降低了可用性，因为客户端和服务端在请求过程中必须都是可用的

消息
使用异步消息来做服务间通信。服务间通过消息管道来交换消息，从而通信。
优点:

• 把客户端和服务端解耦，更松耦合，提高可用性，因为消息中间件缓存了消息，直到消费者可以消费支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应

缺点:

• 消息中间件有额外的复杂性

微服务的优缺点分别是什么?说下你在项目开发中碰到的坑
优点

• 每一个服务足够内聚,代码容易理解
• 开发效率提高,一个服务只做一件事
• 微服务能够被小团队单独开发
• 微服务是松耦合的,是有功能意义的服务
• 可以用不同的语言开发,面向接口编程
• 易于与第三方集成
• 微服务只是业务逻辑的代码,不会和HTML,CSS或者其他界面组合
• 开发中,两种开发模式
  前后端分离
  全栈工程师
• 可以灵活搭配,连接公共库/连接独立库

缺点

• 分布式系统的负责性
• 多服务运维难度,随着服务的增加,运维的压力也在增大
• 系统部署依赖
• 服务间通信成本
• 数据一致性
• 系统集成测试
• 性能监控

你所知道的微服务技术栈有哪些?请列举一二
多种技术的集合体
我们在讨论一个分布式的微服务架构的话,需要哪些维度

维度(SpringCloud)
服务开发
SpringBoot
Spring
SpringMVC
服务配置与管理
Netfilx公司的Archaiusm,阿里的Diamond
服务注册与发现
Eureka,ZooKeeper
服务调用
Rest,RPC,gRPC
服务熔断器
Hystrix
服务负载均衡
Ribbon,Nginx
服务接口调用
Feign
消息队列
Kafka,RabbitMq,ActiveMq
服务配置中心管理
SpringCloudConfing
服务路由(API网关)
Zuul
事件消息总线
SpringCloud Bus
…

参考：
https://www.cnblogs.com/matd/articles/10549336.html
https://www.jianshu.com/p/f5bf09c0ef0b