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）：数据传输的序列化和反序列化

如有问题，欢迎加微信交流：w714771310，备注- 技术交流  。或关注微信公众号【码上遇见你】。