目录
1.SpringCloud与Dubbo的区别
SpringCloud和Dubbo都是现在主流的微服务架构;
- SpringCloud是Apache旗下的Spring体系下的微服务解决方案
- Dubbo是阿里系的分布式服务治理框架
-
初始定位不同：SpringCloud定位为微服务架构下的一站式解决方案；Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用和治理
-
生态环境不同：SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。
-
调用方式：SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。但调用时采用Netty的NIO方式，性能较好。
-
组件差异比较多，例如SpringCloud注册中心一般用Eureka，而Dubbo用的是Zookeeper
两者的生态对比：
2.注册服务的区别
- 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来匹配路由处理请求。
3.Dubbo和Feign远程调用的区别
Dubbo与 Feign 都依赖注册中心、负载均衡，作用是提供远程接口调用。
常见的 实现远程调用的方式： Http接口（web接口、RestTemplate+Okhttp）、Feign、RPC调用（Dubbo、Socket编程）、Webservice...
1、协议
Dubbo：
支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式。非常灵活。
默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。
Feign：
基于Http传输协议，短连接，不适合高并发的访问。
2、负载均衡
Dubbo：
支持4种算法（随机、轮询、活跃度、Hash一致性），而且算法里面引入权重的概念。
配置的形式不仅支持代码配置，还支持Dubbo控制台灵活动态配置。
负载均衡的算法可以精准到某个服务接口的某个方法。
Feign：
只支持N种策略：轮询、随机、ResponseTime加权。
负载均衡算法是Client级别的。
Nacos注册中心很好的兼容了Feign，Feign默认集成了Ribbon，所以在Nacos下使用Fegin默认就实现了负载均衡的效果。
3、容错策略
Dubbo：
支持多种容错策略：failover、failfast、brodecast、forking等，也引入了retry次数、timeout等配置参数。
Feign：
利用熔断机制来实现容错的，处理的方式不一样。
Feign是SpringCloud中的远程调用方式，基于成熟Http协议，所有接口都采用Rest风格。因此接口规范更统一，而且只要符合规范，实现接口的微服务可以采用任意语言或技术开发。但受限于http协议本身的特点，请求和响应格式臃肿，其通信效率相对会差一些。
Dubbo框架默认采用Dubbo自定义通信协议，与Http协议一样底层都是TCP通信。但是Dubbo协议自定义了Java数据序列化和反序列化方式、数据传输格式，因此Dubbo在数据传输性能上会比Http协议要好一些。
不过这种性能差异除非是达极高的并发量级，否则无需过多考虑。
4.Rest和RPC对比
Dubbo采用自定义的Dubbo协议实现远程通信，是一种典型的RPC调用方案，而SpringCloud中使用的Feign是基于Rest风格的调用方式。
1）Rest风格
REST是一种架构风格，指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
Rest的风格可以完全通过HTTP协议实现，使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
因此请求和想要过程只要遵循http协议即可，更加灵活
SpringCloud中的Feign就是Rest风格的调用方式。
2）RPC
Remote Procedure Call，远程过程调用，就是像调用本地方法一样调用远程方法。
RPC一般要确定下面几件事情：
数据传输方式：多数RPC框架选择TCP作为传输协议，性能比较好。
数据传输内容：请求方需要告知需要调用的函数的名称、参数、等信息。
序列化方式：客户端和服务端交互时将参数或结果转化为字节流在网络中传输，那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化
因为有序列化和反序列化的需求，因此对数据传输格式有严格要求，不如Http灵活
Dubbo协议就是RPC的典型代表。
Dubbo协议和Feign的调用区别：
5.Eureka与Nacos注册中心的区别
Springcloud eureka是注册中心，负责微服务的注册与发现，起到承上启下的作用，在微服务架构中相当于人体的 大脑，很重要，nacos是阿里巴巴出的，功能类似eureka。
相同点：
-
都支持服务注册和服务拉取。
-
都支持服务提供者心跳方式做健康检测。
区别：
- Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
- Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
1：在提供者和注册中心之间。
（1）Eureka中会定时向注册中心发送心跳，如果在短期内没有发送心跳，则就会直接剔除。
（2）Nacos也会向注册中心发送心跳，但是它的频率要比Eureka快。在Nacos中又分为临时实例和非临时实例。如果是临时实例的话，短期内没有发送心跳，则会直接剔除。但是如果是非临时实例长时间宕机，不会直接剔除，并且注册中心会直接主动询问并且等待非临时实例。
2：在消费者和注册中心之间。
（1）Eureka会定时向注册中心定时拉去服务，如果不主动拉去服务，注册中心不会主动推送。
（2）Nacos中注册中心会定时向消费者主动推送信息 ，这样就会保持数据的准时性。
3、范围不同。
Nacos的阈值是针对某个具体Service的，而不是针对所有服务的；
但Eureka的自我保护阈值是针对所有服务的。nacos支持CP和AP两种；eureka只支持AP。nacos使用netty，是长连接；eureka是短连接，定时发送
4、保护方式不同。
Eureka保护方式：当在短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下，Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关（eureka.server.enable-self-preservation: false)。
Nacos保护方式：当域名健康实例（Instance)占总服务实例（Instance)的比例小于阈值时，无论实例（Instance)是否健康，都会将这个实例（Instance)返回给客户端。这样做虽然损失了一部分流量，但是保证了集群的剩余健康实例（Instance)能正常工作。
5、连接方式不同。
nacos支持动态刷新，在控制器（controller）上加＠RefreshScope注解即可，采用Netty连接，是长连接；
eureka本身不支持动态刷新，需要配合MQ完成动态刷新，且是短连接，是定时发送。
6.Nacos中的CAP模式切换
C-Consistency,一致性。A-Available,可用性。P-Partition tolerance,分区容错性。
在分布式中P是必须要有的，所以分布式有CP和AP两种模式。AP的就是可用性强，一致性弱；CP就是一致性强,可用性弱。可以把强弱理解成优缺点。
Nacos 支持 AP 和 CP 模式的切换，这意味着 Nacos 同时支持两者一致性协议。这样，Nacos能够以一个注册中心管理这些生态的服务。
AP模式为了服务的可能性而减弱了一致性，因此AP模式下只支持注册临时实例。AP 模式是在网络分区下也能够注册实例。在AP模式下也不能编辑服务的元数据等非实例级别的数据，但是允许创建一个默认配置的服务。同时注册实例前不需要进行创建服务的操作，因为这种模式下，服务其实降级成一个简单的字符创标识，不在存储任何属性，会在注册实例的时候自动创建。
CP模式下则支持注册持久化实例，此时则是以 Raft 协议为集群运行模式，因此网络分区下不能够注册实例，在网络正常情况下，可以编辑服务器别的配置。该模式下注册实例之前必须先注册服务，如果服务不存在，则会返回错误。
MIXED 模式可能是一种比较让人迷惑的模式，这种模式的设立主要是为了能够同时支持临时实例和持久化实例的注册。这种模式下，注册实例之前必须创建服务，在服务已经存在的前提下，临时实例可以在网络分区的情况下进行注册。
7.Eureka和Zookeeper注册中心的区别
SpringCloud和Dubbo都支持多种注册中心，不过目前主流来看SpringCloud用Eureka较多，Dubbo则以Zookeeper为主。两者存在较大的差异：
ZooKeeper保证的是CP,Eureka保证的是AP
- ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的
- Eureka各个节点是平等关系,只要有一台Eureka就可以保证服务可用,而查询到的数据并不是最新的
- ZooKeeper有Leader和Follower角色,Eureka各个节点平等
- ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题
- 从集群设计来看：Eureka集群各节点平等，没有主从关系，因此可能出现数据不一致情况；ZK为了满足一致性，必须包含主从关系，一主多从。集群无主时，不对外提供服务
- CAP原则来看：Eureka满足AP原则，为了保证整个服务可用性，牺牲了集群数据的一致性；而Zookeeper满足CP原则，为了保证各节点数据一致性，牺牲了整个服务的可用性。
- 服务拉取方式来看：Eureka采用的是服务主动拉取策略，消费者按照固定频率（默认30秒）去Eureka拉取服务并缓存在本地；ZK中的消费者首次启动到ZK订阅自己需要的服务信息，并缓存在本地。然后监听服务列表变化，以后服务变更ZK会推送给消费者。
自我保护机制会导致
- Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务
- Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点(高可用)
- 当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)
Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper一样使得整个注册系统瘫痪
8.微服务之间是如何独立通讯的
远程过程调用（Remote Procedure Invocation）
也就是我们常说的服务的注册与发现是直接通过远程过程调用来访问别的service。
优点：
- 简单，常见,因为没有中间件代理，系统更简单
缺点：
- 只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应降低了可用性，因为客户端和服务端在请求过程中必须都是可用的
消息机制
使用异步消息来做服务间通信。服务间通过消息管道来交换消息，从而通信。
优点:
- 把客户端和服务端解耦，更松耦合，提高可用性，因为消息中间件缓存了消息，直到消费者可以消费支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应
缺点:
- 消息中间件有额外的复杂性
9.微服务的优缺点
-
优点
- 每一个服务足够内聚,代码容易理解
- 开发效率提高,一个服务只做一件事
- 微服务能够被小团队单独开发
- 微服务是松耦合的,是有功能意义的服务
- 可以用不同的语言开发,面向接口编程
- 易于与第三方集成
- 微服务只是业务逻辑的代码,不会和HTML,CSS或者其他界面组合
- 可以灵活搭配,连接公共库/连接独立库
缺点
- 分布式系统的复杂性
- 多服务运维难度,随着服务的增加,运维的压力也在增大
- 系统部署依赖
- 服务间通信成本
- 数据一致性
- 系统集成测试
- 性能监控
10. SpringCloud中的常用组件有哪些
Spring Cloud的子项目很多，比较常见的都是Netflix开源的组件：
- Spring Cloud Config
集中配置管理工具，分布式系统中统一的外部配置管理，默认使用Git来存储配置，可以支持客户端配置的刷新及加密、解密操作。 - Spring Cloud Netflix
Netflix OSS 开源组件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。
- Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
- Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；
- Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；
- Feign：基于Ribbon和Hystrix的声明式服务调用组件；
- Zuul：API网关组件，对请求提供路由及过滤功能。
- Spring Cloud Bus
用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新集群中的服务配置。 - Spring Cloud Consul
基于Hashicorp Consul的服务治理组件。 - Spring Cloud Security
安全工具包，对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持。 - Spring Cloud Sleuth
Spring Cloud应用程序的分布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟踪。 - Spring Cloud Stream
轻量级事件驱动微服务框架，可以使用简单的声明式模型来发送及接收消息，主要实现为Apache Kafka及RabbitMQ。 - Spring Cloud Task
用于快速构建短暂、有限数据处理任务的微服务框架，用于向应用中添加功能性和非功能性的特性。 - Spring Cloud Zookeeper
基于Apache Zookeeper的服务治理组件。 - Spring Cloud Gateway
API网关组件，对请求提供路由及过滤功能。 - Spring Cloud OpenFeign
基于Ribbon和Hystrix的声明式服务调用组件，可以动态创建基于Spring MVC注解的接口实现用于服务调用，在Spring Cloud 2.0中已经取代Feign成为了一等公民。
11.总结
Dubbo支持更多功能、更灵活、支持高并发的RPC框架。
SpringCloud全家桶里面（Feign、Ribbon、Hystrix），特点是非常方便。Ribbon、Hystrix、Feign在服务治理中，配合Spring Cloud做微服务，使用上有很多优势，社区也比较活跃，看将来更新发展。
业务发展影响着架构的选型，当服务数量不是很大时，使用普通的分布式RPC架构即可，当服务数量增长到一定数据，需要进行服务治理时，就需要考虑使用流式计算架构。Dubbo可以方便的做更精细化的流量调度，服务结构治理的方案成熟，适合生产上使用，虽然Dubbo是尘封后重新开启，但这并不影响其技术价值。
如果项目对性能要求不是很严格，可以选择使用Feign，它使用起来更方便。
如果需要提高性能，避开基于Http方式的性能瓶颈，可以使用Dubbo。
Dubbo Spring Cloud的出现，使得Dubbo既能够完全整合到Spring Cloud的技术栈中，享受Spring Cloud生态中的技术支持和标准化输出，又能够弥补Spring Cloud中服务治理这方面的短板