Java基础面试题【分布式】组件

Spring Cloud和Dubbo的区别

• 底层协议：springcloud基于http协议，dubbo基于Tcp协议，决定了dubbo的性能相对会比较好
• 注册中心：Spring Cloud使用的eureka，dubbo推荐使用zookeeper
• 模型定义：dubbo将一个接口定义为一个服务，SpringCloud则是将一个应用定义为一个服务

Spring Cloud是一个生态，而Dubbo是Spring Cloud生态中关于服务调用一种解决方案（服务治理）

什么是Hystrix？简述实现机制

分布式容错框架

• 阻止故障的连锁反应，实现熔断
• 快速失败，实现优雅降级
• 提供实时的监控和告警

资源隔离：线程隔离，信号量隔离

• 线程隔离：Hystrix会给每一个Command分配一个单独的线程池，这样在进行单个服务调用的时候，就可以在独立的线程池里面进行，而不会对其他线程池造成影响
• 信号量隔离：客户端需向依赖服务发起请求时，首先要获取一个信号量才能真正发起调用，由于信号量的数量有限，当并发请求量超过信号量个数时，后续的请求都会直接拒绝，进入fallback流程。信号量隔离主要是通过控制并发请求量，防止请求线程大面积阻塞，从而达到限流和防止雪崩的目的。

熔断和降级：

调用服务失败后快速失败

• 熔断是为了防止异常不扩散，保证系统的稳定性
• 降级：编写好调用失败的补救逻辑，然后对服务直接停止运行，这样这些接口就无法正常调用，但又不至于直接报错，只是服务水平下降

实现机制

• 通过HystrixCommand或者HystrixObservableCommand将所有的外部系统（或者称为依赖）包装起来，整个包装对象是单独运行在一个线程之中（这是典型的命令模式）。
• 超时请求应该超过你定义的阈值
• 为每个依赖关系维护一个小的线程池（或信号量）;如果它变满了，那么依赖关系的请求将立即被拒绝，而不是排队等待。
• 统计成功，失败（由客户端抛出的异常），超时和线程拒绝。
• 打开断路器可以在一段时间内停止对特定服务的所有请求，如果服务的错误百分比通过阈值，手动或自动的关闭断路器。
• 当请求被拒绝、连接超时或者断路器打开，直接执行fallback逻辑。
• 近乎实时监控指标和配置变化。

Spring Coud核心组件及其作用

Eureka：

服务注册与发现

• 注册：每个服务都向Eureka登记自己提供服务的元数据，包括服务的ip地址、端口号、版本号、通信协议等。eureka将各个服务维护在了一个服务清单中（双层Map，第一层key是服务名，第二层key是实例名，value是服务地址加端口）。同时对服务维持心跳，剔除不可用的服务，eureka集群各节点相互注册每个实例中都有一样的服务清单。
• 发现：eureka注册的服务之间调用不需要指定服务地址，而是通过服务名向注册中心咨询，并获取所有服务实例清单(缓存到本地)，然后实现服务的请求访问。

Ribbon：

服务间发起请求的时候，基于Ribbon做负载均衡，从⼀个服务的多台机器中选择⼀台（被调用方的服务地址有多个），Ribbon也是通过发起http请求，来进行的调用，只不过是通过调用服务名的地址来实现的。虽然说Ribbon不用去具体请求服务实例的ip地址或域名了，但是每调用一个接口都还要手动去发起Http请求

Feign

基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求，简化服务间的调用，在Ribbon的基础上进行了进一步的封装。单独抽出了一个组件，就是Spring Cloud Feign。在引入Spring Cloud Feign后，我们只需要创建一个接口并用注解的方式来配置它，即可完成对服务提供方的接口绑定。

调用远程就像调用本地服务一样

Hystrix：

发起请求是通过Hystrix的线程池来⾛的，不同的服务⾛不同的线程池，实现了不同服务调⽤的隔离，通过统计接口超时次数返回默认值，实现服务熔断和降级

Zuul：

如果前端、移动端要调⽤后端系统，统⼀从Zuul⽹关进⼊，由Zuul⽹关转发请求给对应的服务，通过与Eureka进行整合，将自身注册为Eureka下的应用，从Eureka下获取所有服务的实例，来进行服务的路由。Zuul还提供了一套过滤器机制，开发者可以自己指定哪些规则的请求需要执行校验逻辑，只有通过校验逻辑的请求才会被路由到具体服务实例上，否则返回错误提示。

如图所示：

Dubbo的整体架构设计及分层

五个角色：

• 注册中心registry：服务注册与发现
• 服务提供者provider：暴露服务服务
• 消费者consumer：调用远程服务
• 监控中心monitor：统计服务的调用次数和调用时间
• 容器container：服务允许容器

调用流程：

1. container容器负责启动、加载、运行provider
2. provider在启动时，向regisitry中心注册自己提供的服务
3. consumer在启动时，向regisitry中心订阅自己所需的服务
4. regisitry返回服务提供者列表给consumer，如果有变更，registry将基于长连接推送变更数据给consumer
5. consumer调用provider服务，基于负载均衡算法进行调用
6. consumer调用provider的统计，基于短链接定时每分钟一次统计到monitor

分层：

• 接口服务层（Service）：面向开发者，业务代码、接口、实现等
• 配置层（Config）：对外配置接口，以ServiceConfig和ReferenceConfig为中心
• 服务代理层（Proxy）：对生产者和消费者、dubbo都会产生一个代理类封装调用细节，业务层对远程调用无感
• 服务注册层（Registry）：封装服务地址的注册和发现，以服务URL为中心
• 路由层（Cluster）：封装多个提供者的路由和负载均衡，并桥接注册中心
• 监控层（Monitor）：RPC调用次数和调用时间监控
• 远程调用层（Protocal）：封装RPC调用
• 信息交换层（Exchange）：封装请求响应模式，同步转异步
• 网络传输层（Transport）：抽象mina和netty为统一接口，统一网络传输接口数据
• 序列化层（Serialize）：数据传输的序列化和反序列化