微服务框架——SpringCloud—RabbitMQ—Dubbo面试题

目录

SpringCloud

什么是springcloud

微服务架构的优点

微服务架构体系 

微服务监控用的是什么技术

CAP理论，BASE理论

Ribbon负载均衡算法、类型，如何配置

分布式架构下，Session 共享有什么方案

简述你对RPC、RMI的理解

分布式id生成方案

分布式锁解决方案

分布式事务解决方案

zk和eureka的区别

高并发场景下如何实现系统限流 

springcloud核心组件及其作用

RabbitMQ

简述RabbitMQ架构设计

RabbitMQ如何确保消息发送 ？ 消息接收？

kafka如何保证消息消费的顺序性

RabbitMQ如何保证消息消费的顺序性

在RabbitMQ中常见的工作模式？

RabbitMQ死信队列、延时队列

简述RabbitMq的交换机类型

rabbitmq可以直连队列么？

简述rabbitmq的持久化机制

简述rabbitmq的普通集群模式

rabbitmq的镜像集群

幂等性

Dubbo

Dubbo是什么？能做什么？

Dubbo 的整体架构设计及分层

Spring Cloud和Dubbo的区别

dubbo中Zk集群挂掉，发布者和订阅者还能通信么

zk实际如何存储dubbo生产者和消费者信息

Dubbo支持的注册中心有哪些

dubbo为什么推荐zookeeper做注册中⼼ 

dubbo集群容错策略有哪些

dubbo支持的协议有哪些

dubbo负载均衡

dubbo服务降级怎么实现

---

SpringCloud

什么是springcloud

        是微服务系统架构的解决方案；提供了各种组件，解决了微服务系统架构在开发过程中遇到的所有问题；组建有：注册中心（nacos、eureka、consul）、远程调用（feign、dubbo）、网关（SpringCloudGateway、zuul）、配置中心（nacos、SpringCloudConfig）、服务监控和保护（sentinel、hystrix）；springcloud中大多数组件都不是springcloud自己开发的，而是将各个公司成熟的技术组合起来，这些技术主要来自两家公司：SpringCloudNetflix和Alibaba。

        Spring Cloud 是一个基于 Spring 框架的分布式应用开发工具包，它提供了一系列开箱即用的工具，使开发人员可以更加轻松地实现分布式架构中的常见模式，包括配置管理、服务发现、负载均衡、断路器、API 网关等。通过 Spring Cloud，开发人员可以快速构建和连通具有弹性和可扩展性的微服务架构。

        Spring Cloud 工具包包括以下主要组件：

        1. Spring Cloud Config：基于Git或者SVN等管理配置文件的配置中心。

        2. Spring Cloud Netflix：对 Netflix OSS 的封装，包含了对服务发现、智能路由、负载均衡、断路器、API 网关等组件的支持。比如 Eureka (服务发现), Hystrix (断路器)，Zuul (API 网关)，Ribbon (负载均衡器)等。

        3. Spring Cloud Bus：消息总线，用于在分布式系统之间传播状态的变化。

        4. Spring Cloud Sleuth：分布式追踪工具，可用于跟踪请求链路以及使用 Zipkin 进行分布式跟踪。

        5. Spring Cloud Stream：基于Spring Boot的Binder抽象封装, 支持多种消息中间件实现。

        6. Spring Cloud Security：基于Spring Security的安全工具包，提供了OAuth2安全控制和服务安全等功能。

        总之，Spring Cloud 提供了丰富的工具和组件，使得分布式系统的开发人员能够更加方便快捷地构建和管理分布式系统，将开发人员从细枝末节的实现细节中解放出来，将更多的注意力集中在核心业务逻辑的开发上。

微服务架构的优点

        每个服务中只包含一种业务，降低了业务之间的耦合；如果某个用户服务访问的压力很大，就可以针对这个服务搭建集群解决访问压力的问题，其他服务可以不动，这样便于服务的拓展。

        微服务架构是一种以服务为中心、强调独立部署和运行的软件架构，相对于传统的单体应用架构，它具有以下优点：

        1. 高度解耦：微服务架构中的服务通过接口进行通信，从而实现了高度解耦，每个服务都具有单一职责，可以独立部署和更新，当一个服务出现故障或需要更新时，不会影响其它服务的正常运行。

        2. 高可扩展性：由于每个服务都是独立的，可以根据具体的需求对每个服务进行水平或垂直的扩展，从而提高整体系统的吞吐量和性能。

        3. 更快速的部署和交付：微服务架构中的服务可以独立部署和更新，从而使得整个系统的部署和交付更加快速和可靠，这对于不断变化的市场需求和快速创新的业务是非常重要的。

        4. 更好的可维护性：微服务架构中的服务每个都相对较小，因此更容易维护和管理，可以更快地识别和解决故障。

        5. 更好的技术选型：由于每个服务都是独立运行的，因此可以根据服务的特性和要求选择最适合的技术栈，更好地实现服务的特性，提高整体系统的性能和响应能力。

        6. 更好的团队协作：在微服务架构中，每个服务都由小团队独立维护和开发，从而使得服务的开发和维护分工更加明确，协作更加高效，并且开发和部署速度更快，效率更高。

        总之，微服务架构具有高度解耦、高可扩展性、更快速的部署和交付、更好的可维护性、更好的技术选型和更好的团队协作等优点，能够提高整体系统的稳定性、可靠性、可伸缩性和可扩展性，已成为当今软件架构领域的主流趋势。

微服务架构体系 

        服务注册和发现；服务远程调用；服务链路监控；统一配置管理；统一网关路由；流控、降级、维护。

微服务监控用的是什么技术

        微服务架构的监控通常使用的就是链路追踪，目前主流的链路追踪技术有：SkyWalking 、Zipkin+Sleuth；这些链路技术都实现了opentrace标准。 

        在微服务架构中，为了保证系统的稳定性，必须对服务的运行状态进行监控。常用的微服务监控技术有以下几种：

        1. 日志监控：通过日志监控，可以收集并记录服务的关键信息，例如错误日志、请求日志、访问日志等。常用的日志监控技术包括 ELK（Elasticsearch、Logstash 和 Kibana）、Log4j、Logback 等。

        2. 指标监控：指标监控可以对微服务架构中的各种资源进行实时监控，以确定资源的可用性和性能状况。指标监控通常涉及 CPU 使用率、内存占用、收到的请求量、响应时间等指标。常用的指标监控技术包括 Prometheus、Graphite、Grafana 等。

        3. 分布式跟踪：分布式跟踪可以监控微服务间的请求，并在请求的整个生命周期中跟踪请求记录。常用的分布式跟踪技术包括 Zipkin、Jaeger 等。

        4. 监控告警：在监控系统中，可以定义规则和阈值来触发告警，以快速响应对系统的潜在威胁。常用的监控告警技术包括 Nagios、Zabbix、Prometheus Alertmanager 等。

        5. 容器监控：容器监控可以帮助管理员实时监控容器内部的状态，例如每个容器的 CPU 和内存使用情况、网络带宽、储存使用情况。常用的容器监控技术包括 cAdvisor、Docker Stats 等。

        总之，微服务监控技术主要包括日志监控、指标监控、分布式跟踪、监控告警和容器监控等。使用这些技术可以快速识别和解决各种故障和性能问题，从而确保微服务架构的稳定性和可靠性。 

CAP理论，BASE理论

CAP理论：

        Availability (可用性)：即服务一直可用，而且是正常响应时间。系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况；

        Partition Tolerance (分区容错性)：即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

        CP和AP：分区容错是必须保证的，当发生网络分区的时候，如果要继续服务，那么强一致性和可用性只能 2 选 1

BASE理论：

        BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

        基本可用：响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的部分非核心功能无法使用。

        软状态：数据同步允许一定的延迟。

        最终一致性：系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，不要求实时一致

        CAP 理论是分布式系统设计中常用的理论，它可以帮助我们理解分布式系统中的三个主要指标：一致性、可用性和分区容忍性。

        CAP 理论指出，在分布式系统的设计中，无法同时满足：

        1. 一致性（Consistency）：对于分布式系统中的一项数据更新操作，最终所有数据副本的状态保持一致。

        2. 可用性（Availability）：分布式系统在遇到故障时，仍能保持对外服务的可用性。

        3. 分区容忍性（Partition Tolerance）：即使出现网络分区（节点之间的通信出现故障）的情况，系统仍能正常运行。

        因此，根据 CAP 理论，分布式系统只能保证其中任意两个属性的完整性，无法同时满足三个属性。

        而 BASE 理论是针对分布式系统中可用性问题的扩展，它将传统 ACID（原子性、一致性、隔离性、持久性）事务模型打破，提出了基于最终一致性的思想。BASE 是：

        1. 基本可用（Basically Available）：分布式系统出现故障时，系统仍能保证对外服务的可用性。

        2. 软状态（Soft State）：分布式系统中，数据状态并不需要实时同步，允许存在一段时间的不一致状态。

        3. 最终一致性（Eventually Consistent）：在一定时间内，系统数据状态最终会达到一个一致的状态。

        前两项是对 CAP 中可用性和分区容忍性属性的扩展和强调，第三项则是对一致性保证的松弛，允许在给定时间内数据状态的不一致。

        在实际的分布式系统设计中，根据不同的业务需求、资源限制以及技术栈选择，可以选取 CAP 或 BASE 的不同子集，以更好地符合需求。

Ribbon负载均衡算法、类型，如何配置

        Ribbon负载均衡算法的类型：RoundRobinRule：轮询；RandomRule：随机；

        AvailabilityFilteringRule：会先过滤掉由于多次访问故障而处于断路器状态的服务，还有并发的连接数量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问；

        WeightedResponseTimeRule：根据平均响应时间计算所有服务的权重，响应时间越快的服务权重越大被选中的概率越大。刚启动时如果统计信息不足，则使用RoundRobinRule（轮询）策略，等统计信息足够，会切换到WeightedResponseTimeRule；

        RetryRule：先按照RoundRobinRule（轮询）策略获取服务，如果获取服务失败则在指定时间内进行重试，获取可用的服务；

        BestAvailableRule：会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务；

        ZoneAvoidanceRule：复合判断Server所在区域的性能和Server的可用性选择服务器；

如何配置：定义方法，加@Bean注解交由Spring管理，返回值IRule。

        Ribbon 是一个基于 HTTP 和 TCP 协议的客户端负载均衡器，常用于微服务架构中的服务消费方。在 Ribbon 中，请求会先被路由到一个负载均衡器，然后由负载均衡器选择一台合适的服务提供方来处理请求。Ribbon 提供了多种负载均衡算法和配置方式，下面是详细介绍：

        1. 负载均衡算法：

        - RoundRobinRule（轮询）：按照轮询方式选择服务提供方，均衡地分配请求到每台机器；

        - RandomRule（随机）：随机选择一台服务提供方来处理请求；

        - WeightedResponseTimeRule（加权平均响应时间）：根据每个服务提供方的平均响应时间和权重计算每台机器的权重，响应时间越长权重越小；

        - BestAvailableRule（选择并发较小的机器）：选取并发请求比较小的一台服务提供方来处理请求，以避免负载集中；

        - RetryRule（重试）：选择一个可用的服务提供方，如果请求超时或者失败，会重新选择一台服务提供方。

        2. 配置方式：

        Ribbon 配置有两种方式：静态和动态。静态方式需要在配置文件中直接配置负载均衡器的行为、提供方列表和负载均衡算法等参数，而动态方式需要在服务启动后从注册中心动态获取可用的服务提供方列表。

        静态方式下，可以使用以下配置来指定负载均衡算法：

# 定义一个名为 {服务名}.ribbon.NFLoadBalancerRuleClassName 的属性
# 使用其中一个负载均衡规则的全名（全路径名）来覆盖应用的默认负载均衡规则
{服务名}.ribbon.NFLoadBalancerRuleClassName=com.netflix.loadbalancer.RandomRule

        动态方式下，可以使用以下注解来指定负载均衡算法：

@RibbonClient(
  name = "服务名",
  configuration = RibbonConfig.class
)
public class MyServiceConsumer {
  // ...
}

         `RibbonConfig` 类需要继承自 `IRule` 类（即负载均衡算法的父类），并覆盖 `RibbonLoadBalancerClientConfiguration` 中的 `loadBalancerRule` 方法：

@Configuration
public class RibbonConfig {

  @Bean
  public IRule loadBalanceRule() {
    return new RandomRule(); // 指定相应的负载均衡算法
  }

}

        以上是 Ribbon 负载均衡算法和配置方式的介绍，具体使用应根据业务需要和实际情况进行选择配置。

分布式架构下，Session 共享有什么方案

        分布式环境中HttpSession不能共享；

        1.可以使用cookie来完成，用户登录成功后，将用户信息存储到cookie中，下次客户端访问服务器，通过判断是否有cookie从而判断是否登录；

        2.使用Nginx中的ip绑定策略，同一个ip只能在指定的同一个机器访问（不支持负载均衡）

        3.使用数据库同步session（效率不高） 用户登录成功后，将用户信息存储到session,然将session存储到数据库。下次客户端访问服务器，从数据库中获取用户session；判断用户是否登录。

        4.使用tomcat内置的session同步（同步可能会产生延迟）

        5.使用token代替session（推荐）

        6.使用Spring-Session+Redis实现

        在分布式架构下，由于用户请求可以被多台服务器处理，因此传统的 Session 共享会面临一些问题。为了解决这些问题，可以采用以下几种 Session 共享方案：

        1. 基于数据库的共享方案：在该方案下，Session 数据将被保存在数据库中，多台服务器都可以访问同一个数据库，并且使用同一个 Session ID。例如，Tomcat 提供了一个 JdbcStore 插件，可以将 Tomcat Session 存储到数据库中，从而实现 Session 共享。

        2. 基于缓存的共享方案：在该方案下，Session 数据被存储在缓存中，因此所有服务器都可以访问和更新相同的 Session 数据。例如，使用 Redis 提供的分布式缓存方案，将 Session 数据存储在 Redis 中，从而实现集群中多台服务器之间的 Session 共享。

        3. 基于统一认证的共享方案：在该方案下，Session 数据存储在认证服务器中，多个应用程序可以通过调用认证服务器的接口获取或更改相同的 Session 数据。例如，可以使用集成了 OAuth2.0 的 Spring Security 实现该方案，从而实现多个应用程序的 Session 共享。

        4. 基于反向代理的共享方案：在该方案下，多台服务器使用反向代理服务器来处理请求，并将 Session 数据存储在反向代理服务器中。反向代理服务器可以根据请求相应地转发到不同的服务器，从而实现 Session 共享。例如，可以使用 Nginx 的 Session Sticky Module 实现该方案。

        总之，在分布式架构中，为了实现 Session 共享，可以采用基于数据库、缓存、统一认证以及反向代理等方案，根据不同的业务需求和应用场景进行选择。

简述你对RPC、RMI的理解

        RPC：在本地调用远程的函数，远程过程调用，可以跨语言实现httpClient；

        RMI：远程方法调用，java中用于实现RPC的一种机制，RPC的java版本，是J2EE网络调用机制，跨JVM调用对象的方法，面向对象的思维方式。

        RPC （Remote Procedure Call，远程过程调用）是一种跨计算机网络的通信协议，它允许一个计算机程序调用另一个计算机程序的子程序或服务，而不需要了解底层网络细节。RPC 是现代分布式系统的基础之一，可以用于实现分布式应用程序中的各个组件之间的通信。

        RMI（Remote Method Invocation，远程方法调用）是 Java 语言中实现 RPC 的一种方式，它允许在不同的 Java 虚拟机上执行 Java 对象的方法调用。在 RMI 中，客户端和服务器之间通过 Java 序列化将 Java 对象发送到远程机器上，并在那里被重新复制和反序列化。

        RMI 在 Java 分布式系统中应用广泛，因为它提供了对 Java 对象的透明访问，并以 Java 对象和 Java 数据类型作为其基本交互单位。相比于一些需要手动序列化和反序列化数据的 RPC 框架，RMI 更加高效、易于使用和维护。

        总之，RPC 和 RMI 都是分布式系统中实现远程通信的核心技术，RPC 是一个通用的远程过程调用协议，而 RMI 是 Java 语言中实现 RPC 的一种方式。

分布式id生成方案

        UUID：UUID长度过长，不适用于存储，耗费数据库性能。 ID无一定业务含义，可读性差；

        基于redis、mongodb、zk等中间件生成；

        雪花算法。

分布式锁解决方案

        需要这个锁独立于所有微服务之外，而不是在服务里面；

        数据库：利用主键冲突控制一次只有一个线程能获取锁，非阻塞、不可重入、单点、失效时间；

        可以使用Zookeeper分布式锁、和Redis分布式锁；

        在分布式系统中，分布式锁是实现分布式协调的常用方式之一，可以用来保证分布式环境下对资源的独占访问。下面是几种常见的分布式锁解决方案：

        1. 基于数据库的锁方案：在该方案下，利用数据库的唯一性约束来实现锁的功能。例如，可以在数据库中创建一个表，通过该表中的行记录来实现锁的操作。缺点是锁的性能会受到数据库并发操作的影响。

        2. 基于缓存的锁方案：在该方案下，使用缓存来存储锁信息。例如，可以使用 Redis 的 SETNX 命令来实现锁的功能。优点是锁的性能较高，缺点是可能存在死锁和锁失效的问题。

        3. 基于 ZooKeeper 的锁方案：在该方案下，使用 ZooKeeper 的有序节点来实现锁的功能。多个节点通过申请 ZNode 的方式来获取锁，在释放锁时删除对应的 ZNode。优点是锁的安全性和可靠性较高，缺点是锁的性能较差。

        4. 基于 Redisson 的分布式锁方案：在该方案下，使用 Redisson 的分布式锁组件来实现分布式锁。Redisson 的分布式锁组件使用 Redis 的单线程模式来保证锁的安全性，同时提供了多种分布式锁算法。优点是性能高、功能强，缺点是需要使用额外的库。

        总之，在分布式环境下实现分布式锁是一项复杂的任务，需要根据具体的业务需求和实际情况选择合适的分布式锁解决方案，以保证分布式环境下的数据一致性和可靠性。

分布式事务解决方案

        两阶段协议、三阶段协议、TCC（补偿事务）、消息队列的事务消息

        在分布式系统中，由于事务可能涉及到多个节点或数据库，因此分布式事务处理是一个比较复杂的问题。下面是几种常见的分布式事务解决方案：

        1. 两阶段提交（Two-phase Commit，2PC）：在该方案下，事务协调者（Transaction Coordinator）首先向参与者（Participant）发送 prepare 确认请求，等到所有参与者都响应已准备完成后，协调者再发送 commit 或 rollback 请求。优点是支持跨服务器的事务处理，缺点是协调者称为单点故障，并且可能存在阻塞和数据不一致等问题。

        2. 基于消息的事务（Message-oriented Middleware，MOM）：在该方案下，生产者（Producer）将消息发送给消息队列（Message Queue），消息队列保证消息的幂等性和顺序性，并将消息发送到消费者（Consumer）。优点是支持异步处理和数据可靠性，缺点是需要考虑顺序和幂等性问题。

        3. TCC（Try-Confirm-Cancel，尝试-确认-取消）：在该方案下，事务被分成三个阶段，首先尝试执行事务，然后进行确认操作，最后如果确认通过，就执行事务提交操作，否则执行事务回滚操作。优点是解决了阻塞问题和单点故障问题，缺点是实现比较复杂，需要对业务代码进行修改。

        4. Saga：在该方案下，事务被拆分成多个子事务，在每个子事务执行前都将事务状态保存到数据库中，可以根据事务状态来执行回滚或者提交操作。优点是结构清晰，易于实现，缺点是事务的执行过程比较复杂。

        总之，在分布式环境下实现分布式事务处理是一个复杂的任务，需要根据具体的业务需求和实际情况选择合适的解决方案。

zk和eureka的区别

        zk：CP设计(强一致性)，目标是一个分布式的协调系统，用于进行资源的统一管理。当节点crash后，需要进行leader的选举，在这个期间内，zk服务是不可用的。

        eureka：AP设计（高可用），目标是一个服务注册发现系统，专门用于微服务的服务发现注册。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）

        Zookeeper（简称 ZK）和 Eureka 都是用于构建分布式系统的服务注册和发现组件，它们的作用都是为了管理分布式环境下的服务。下面是两者的主要区别：

        1. 一致性模型不同：Zookeeper 的一致性模型采用的是 ZAB（ZooKeeper Atomic Broadcast）协议，可以保证数据的强一致性和可靠性；而 Eureka 的一致性模型采用的是 AP（响应可用性），允许在网络分区故障时服务实例继续对外提供服务，但会导致服务信息不一致。

        2. 服务健康检查方式不同：Zookeeper 使用 Watcher 机制来实现服务健康检查，当服务实例状态发生变化时，会触发 Watcher 事件通知客户端；而 Eureka 使用心跳机制来实现服务健康检查，定期发送心跳包来确认服务状态。

        3. 技术架构不同：Zookeeper 支持一个具有高可用性的 Zookeeper 集群，Zookeeper 的客户端和服务器端都可以使用 Java 或 C/C++ 编写；而 Eureka 是基于 Servlet 和 REST 的，可以直接嵌入到 Spring Cloud 中使用。

        4. 应用场景不同：Zookeeper 适用于实施 CP（一致性和分区容忍性），要求有严格一致性和数据可靠性的场景，例如 Hadoop 集群、Kafka 等；而 Eureka 适用于实施 AP（响应性和分区容忍性），对服务发现的响应速度和可用性有更高要求的场景，例如微服务架构。

        总的来说，Zookeeper 适用于需要强一致性和数据可靠性的场景，Eureka 适用于需要高可用性和可扩展性的场景。

高并发场景下如何实现系统限流 

        Nginx限流、OpenResty限流、Sentinel限流、Redis+Lua限流、Spring Cloud Gateway限流

        在高并发场景下，系统限流是一种常见的保护机制，它可以有效地控制系统的请求流量，避免系统因为流量超出负载容量而导致崩溃。以下是几种实现系统限流的方式：

        1. 服务降级：当系统出现高并发时，可以通过服务降级的方式来减少系统压力。例如，可以将一些核心服务降级为全网服务，或者关闭一些不必要或临时不可用的接口。

        2. 令牌桶算法：在该算法中，系统将每个请求看作一个令牌，并将请求放入令牌桶中。当系统的处理能力达到上限时，系统将不再产生新的令牌，而只是等待已存在的令牌被请求并处理。如果在规定时间内没有被处理，则会被丢弃。

        3. 漏桶算法：在该算法中，系统将所有请求看作水滴，并将水滴放入一个固定大小的漏桶中。当请求过多时，水滴会开始从漏桶中滴落。如果漏桶已满，则新的请求被丢弃。

        4. 熔断器：熔断器是一种容错机制，用于在系统达到一定负载时自动关闭服务。在该机制中，当某个服务的错误率达到一定阈值时，熔断器将自动打开，并拒绝所有新的请求，从而保证系统的可靠性和稳定性。

        总之，在高并发场景下实现系统限流是一项关键的任务，可以使用多种方式来避免系统出现大量请求而导致的崩溃。需要根据具体的业务需求和实际情况选择合适的限流方式，以保证系统的稳定性和可靠性。

springcloud核心组件及其作用

        注册中心（nacos,eureka）：用于服务注册与发现；（硬编码服务提供者地址的方式有不少问题。要想解决这些问题，服务消费者需要一个强大的服务发现机制，服务消费者使用这种机制获取服务提供者的网络信息。不仅如此，即使服务提供者的网络地址发生变化，服务消费者也无须修改配置文件。）

        客户端负载均衡(ribbon)：Ribbon 的作用是负载均衡；（服务进行远程调用的时候，如果服务提供方搭建了集群。Ribbon通过负载均衡算法选择其中一个）

        远程调用( Feign Dubbo)：以优雅的方式完成服务之间的通信。

        服务保护(Hystrix Sentinel)：服务链上，因为某个微服务的异常，而导致雪崩效应，整条服务链宕机的问题。

        网关（zuul，gateway）：负责网络路由（可以做统一的认证、限流、认证授权、安全，等等。）

        Spring Cloud 是一个开源的微服务应用开发框架，它提供了一系列分布式系统开发所需的核心组件，以下列举了一些常用的核心组件及其作用：

        1. 服务注册与发现：Eureka、Consul、Zookeeper 等。它们可以帮助服务自动注册和发现，将服务自动注册到注册中心，方便其他服务进行调用，避免硬编码调用地址的问题。

        2. 服务消费：Ribbon、Feign 等。它们可以帮助服务消费者设计负载均衡、调用远程服务等功能，让服务消费者更加轻松地调用远程服务。

        3. 服务容错：Hystrix、Resilience4j 等。它们可以帮助服务解决调用服务的错误、延迟、超时等问题，从而提高服务的可用性和稳定性。

        4. 服务网关：Zuul、Spring Cloud Gateway 等。它们可以提供路由转发、限流、认证、鉴权等功能，是服务的入口和出口，可以实现各种复杂的服务调用场景。

        5. 分布式配置：Spring Cloud Config。它可以将应用程序的配置集中管理，并将其安全地分布式到各个环境中。

        6. 服务编排与管理：Spring Cloud Kubernetes、Istio 等。它们可以帮助开发人员更方便地使用 Kubernetes 管理和编排服务。

        总之，Spring Cloud 的核心组件可以帮助我们更高效地构建分布式应用，提高应用的可靠性和可扩展性。需要根据具体的业务需求和实际情况选择合适的 Spring Cloud 组件，来构建自己的分布式应用。

        

RabbitMQ

简述RabbitMQ架构设计

     

        RabbitMQ 是一种开源的消息队列系统，采用的是 AMQP（Advanced Message Queuing Protocol）协议，以实现可靠的消息传递。其架构设计主要由以下几个组件构成：

        1. Exchange：交换机，用于将消息路由到队列中。它接收生产者发送的消息，并根据消息的路由键将消息路由到一个或多个队列中。Exchange 的类型有 direct、fanout、topic、headers 四种。

        2. Queue：消息队列，用于存储消息。每个队列都有一个名称，用于标识队列。消费者会从队列中读取消息并进行处理。

        3. Binding：用于将 Exchange 和 Queue 关联起来。Binding 定义了 Exchange 如何将消息路由到该队列中，并可以绑定多个 Queue。

        4. Connection：连接，用于在生产者和消费者之间建立连接。每个连接都有一个唯一的标识 ID，用于区分不同的连接。

        5. Channel：通道，用于在连接中传递消息。每个连接可以有多个 Channel，通过 Channel 可以进行 Exchange 和 Queue 的声明、绑定和删除等操作。并且在 Channel 中可以设置一些属性，如消息持久化、消息超时等。

        6. Virtual host：虚拟主机，用于隔离不同的应用程序。RabbitMQ 可以在同一个物理服务器上运行多个虚拟主机，每个虚拟主机都有自己的 Exchange、Queue、Binding 和限流等设置。

        总之，RabbitMQ 架构设计采用了 AMQP（Advanced Message Queuing Protocol）协议，通过 Exchange（交换机）、Queue（消息队列）、Binding、Connection（连接）、Channel（频道）、Virtual host（虚拟主机） 这些组件来实现消息的可靠传递，可以满足各种复杂的消息传递需求。

RabbitMQ如何确保消息发送 ？ 消息接收？

导致生产者消息丢失有哪些原因：

        生产者发送的消息没有到达交换机；

        生产者发送的消息到达交换机，但是交换机没有将消息转发到消息队列；

        

        队列中的消息未被消费MQ宕机了 

        首先要清楚导致生产者消息丢失的原因，有三种：1.生产者发送的消息没有到达交换机； 2. 生产者发送的消息到达交换机，但是交换机没有将消息转发到消息队列；3. 队列中的消息未被消费MQ宕机了 ；

        解决生产者消息丢失问题：前2个问题可以利用消息的确认机制，后1个问题可以利用消息持久化。

        什么是消息确认机制：生产者发送消息到rabbitmq，rabbitmq会给生产者返回结果;

        消息确认机制的作用：通过消息确认机制，生产者可以根据mq返回结果知道消息是否成功发送到了rabbitmq；

        消息确认机制分类：通过消息确认机制，生产者可以根据mq返回结果知道消息是否成功发送到了rabbitmq；publish-comfirm（生产者发送消息到交换机消息确认，成功:ack，失败:nack）；publish-return（交换机转发消息队列的消息确认，失败:nack）

        消费者消息确认机制：消费者确认消息的三种模式：1.none，消费者从MQ中获取消息，无论是否出现异常，rabbitmq都会将消息从消息队列中删除；2.manual（通过手动编码方式，告诉rabbitmq消息已经进行了消费，rabbitmq会自动将消息删除）；3.auto(默认),根据消费者是否有抛出异常，自动告诉rabbitmq，消费者是否成功消费了消息；

        消费者确认模式的配置方式是什么?：消费者的application.yml

spring:
  rabbitmq:
    listener:
      simple:
        acknowledge-mode: auto

        RabbitMQ 作为一个可靠的消息队列系统，通过多种方式保证消息的可靠发送和接收。

        1. 消息的可靠发送：在消息发送时，生产者可以设置消息的持久化模式，将消息持久化到磁盘中，以确保消息在 RabbitMQ 宕机或者网络故障的情况下不会丢失。此外，RabbitMQ 还提供了事务和发布确认两种机制，可以确保消息在发送成功后才被确认，避免消息丢失或重复发送。

        2. 消息的可靠接收：在消费者接收消息时，可以设置消息的自动确认或者手动确认模式。自动确认模式下 RabbitMQ 会立刻将消息从队列中删除，但如果出现异常情况会导致消息丢失；手动确认模式下需要消费者手动实现消息的确认，可以确保消息传输的可靠性。此外，消费者还可以设置消息的预取值、队列的优先级等，以保证消费者的负载均衡和性能优化。

        总之，RabbitMQ 通过提供消息持久化、事务和发布确认等机制来确保消息的可靠发送，通过设置消息确认模式、消息预取值和队列优先级等机制来确保消息的可靠接收。这些机制可以满足各类复杂的消息传输需求，保证了 RabbitMQ 的可靠性和稳定性，广泛应用于分布式系统和云计算中。

kafka如何保证消息消费的顺序性

        Kafka 通过分区（Partition）和偏移量（Offset）来保证消息的顺序性。

        首先，Kafka 将每个 Topic 的消息分为多个 Partition，每个 Partition 中的消息有序且不可修改，因此，相同 Partition 中的消息是有序的。

        其次，每个消息都有一个相应的偏移量（Offset），可以精确地标识一个消息在 Partition 中的位置。消费者可以通过指定要消费的 Partition 和 Offset 来读取消息。消费者可以指定将要消费的 Partition 和 Offset，消费者从一个 Offset 开始读取消息，一旦一个 Partition 中的 Offset 被消费者读取，该 Offset 将会被记录并且不会再次被读取。

        基于这种机制，Kafka 能够保证消息在一个 Partition 中的顺序性，但是不同 Partition 的消息可能会乱序。为了保证每个 Partition 中的消息按顺序被消费，可以将消息发送到同一个 Partition 中，或者使用如下方式：

        1. 将消息发送到同一分区中（即同一 Key），这样 Kafka 就能够保证这些消息的顺序。

        2. 使用单消费者模式来消费同一分区中的消息，因为在单消费者模式中，Kafka 只会将消息发送到一个消费者，因此可以得到正确的消息顺序。

        3. 如果使用多消费者模式，则要注意消费者的数量不能超过 Topic Partition 的数量（即每个消费者消费单独的 Partition，不可重复），否则可能导致重复消费或者漏消费的问题。如果需要水平扩展消费者，可以增加 Topic 的 Partition 数量以及对应的消费者数量。

        总之，Kafka 通过分区和偏移量机制保证消息的顺序性，可以通过发送到同一分区、使用单消费者模式、控制消费者数量等方式来保证消息的有序性。                        

RabbitMQ如何保证消息消费的顺序性

        实际上，RabbitMQ 默认是不能保证消息的顺序性的，因为 RabbitMQ 的消息是以并发的方式处理的。但是，以下几种方法可以实现消息的有序消费。

        1. 消息发送到同一个队列：将同一类型的消息发送到同一个队列中，并限制同时只有一个消费者才能从该队列中消费消息。这种方式可以保证按照消息发送的顺序来消费消息。

        2. 消息发送到同一个 Exchange，使用 Routing Key 分发消息到不同 Queue：在这种情况下，每个 Queue 只有一个消费者，消费者之间不会造成竞争消费，这将保证按照消息的发送顺序消费。

        3. 消息发送到不同 Exchange，每个 Exchange 对应一个 Consumer：这种方式类似于第二种，但是每个消费者订阅的是不同的 Exchange，所有的 Exchange 都绑定到同一个 Queue 上，这将保证顺序。

        需要注意的是，当消费者在处理一个任务时，并发，以及需要严格按序处理的情况下，需要将相关的任务（可能是一个消息或者多个有序的消息）封装到一个队列或者一个消息组中，让消费者一次性地消费这些有序的任务。

        总结起来，RabbitMQ 并不能直接保证消息的顺序，但是可以通过将消息发送到同一队列、同一 Exchange 的不同 Queue 或者绑定不同 Exchange 的相同 Queue 等方式来保证消息的有序性。同时，为了实现需要严格按序处理的任务，需要将相关任务封装到一个队列或者一个消息组中。

在RabbitMQ中常见的工作模式？

        在 RabbitMQ 中，有四种常用的工作模式：简单模式、工作队列模式、发布/订阅模式以及路由模式。

       1. 简单模式（Simple Queue）：最基础的工作模式，生产者将消息发送到队列中，消费者从队列中读取消息并进行处理。

        2. 工作队列模式（Work Queue）：多个消费者同时消费队列中的消息，RabbitMQ 会将消息平均分配给每个消费者，消费者可以设置消息的预取值，限制每个消息队列中最多能存在的未确认的消息数量。

        3. 发布/订阅模式（Publish/Subscribe）：生产者将消息发送到交换机中，所有与该交换机绑定的队列均会收到该消息。交换机类型通常会采用 fanout 类型，同时支持多个消费者消费同一份消息。

        4. 路由模式（Routing）：交换机类型为 direct，生产者在发送消息时需要指定一个 Routing key，与该 Routing key 匹配的队列才能接收到该消息。消费者可以创建多个队列，与交换机绑定时指定不同的 Routing key，以实现对消息的筛选和处理。

        5. 主题模式（Topic）：支持生产者发送带有通配符的 Routing key，能够匹配多个 Routing key，更加灵活地进行消息路由和消费。

        6. Header 模式：根据消息头的键值对进行匹配，适用于复杂的路由规则和条件过滤。         总之，RabbitMQ 支持多种工作模式，针对不同应用场景可以选择不同的模式，以满足消息传输的不同需求。如需更高级的消息路由，可使用 Topic 模式、Headers 模式等。

RabbitMQ死信队列、延时队列

        一个消息如果出现以下三种情况就会成为死信：1.被消费者拒绝掉的消息；2.消息过期（在创建消息队列的时候，可以给消息设置存活时间x-message-ttl，如果在存活时间内，消息没有被消费，消息就成为死信）；3.消息队列堆积满了溢出的消息（创建消息队列的时候，可以给消息队列设置长度x-max-length，如果队列中的消息堆积满了，溢出的消息就成为了死信）；消息成为死信后第一种情况是被丢弃，如果队列指定了死信交换机，消息就会进入死信交换机，由死信交换机路由到死信队列；私信交换机其实就是一个普通交换机，所以可以为任何类型【Direct（路由）、Fanout（发布订阅）、Topic（通配符）】；在RabbitMQ中利用死信交换机 + 消息TTL来实现延迟队列。

        RabbitMQ 作为一个可靠的消息队列系统，支持多种特性，其中包括死信队列和延时队列。

        1. 死信队列（Dead Letter Queue，DLQ）：当消息在队列中被拒绝或者过期时，RabbitMQ 会将该消息发送到死信队列中，避免消息丢失。死信队列可以配置在 Queue 属性中，并且可以绑定到一个交换机中，从而实现消息转发和重新处理。

        2. 延时队列（Delayed Message Queue）：延时队列可以实现将消息延迟发送，即在一段时间后才能被某个消费者读取和处理。RabbitMQ 不直接支持延迟队列，但可以使用 RabbitMQ 插件或者客户端来实现该特性。其中 RabbitMQ 插件的实现方式为创建一个专门的消息队列，在队列中存储需要延迟处理的消息，然后通过设置消息的 TTL 和 DLX 属性来实现延迟队列的功能。

        总之，RabbitMQ 支持死信队列和延时队列，可以通过该特性实现消息传递的更多特性和需求。

简述RabbitMq的交换机类型

        RabbitMQ 的交换机类型指的是消息从生产者到消费者之间传输的路径和规则，常见的交换机类型包括以下四种：

        1. Direct 交换机（Direct Exchange）：生产者通过 Routing Key 发送消息到 Direct 交换机，同时在消费者中创建队列时需要指定 Routing Key，RabbitMQ 会将消息通过 Routing Key 匹配的队列发送给对应的消费者。Direct 交换机适合用于一对一的消息传输场景。

        2. Fanout 交换机（Fanout Exchange）：生产者发送消息到 Fanout 交换机，交换机会将消息发给所有绑定到该交换机的队列，无论该队列的 Routing Key 是否匹配。Fanout 交换机适合用于广播消息场景。

        3. Topic 交换机（Topic Exchange）：生产者通过 Routing Key 发送消息到 Topic 交换机，同时在消费者中创建队列时需要指定 Binding Key，Binding Key 通常是一个带有通配符 * 和 # 的字符串，RabbitMQ 会将消息通过 Binding Key 匹配的队列发送给对应的消费者。Topic 交换机适合用于消息过滤和按条件选择队列的场景。

        4. Headers 交换机（Headers Exchange）：生产者可以指定 Header 参数来指定消息，同时在消费者中创建队列时需要定义一组 Headers 参数，RabbitMQ 会将消息的 Header 参数与队列的 Headers 参数进行比较，如果匹配则发送给对应的消费者。Headers 交换机适合用于根据自定义参数进行匹配的场景，但相对较少使用。

        总之，RabbitMQ 的不同交换机类型适合不同的场景，可以满足各种消息传输需求。

rabbitmq可以直连队列么？

        不能，即使是简单工作模式，虽然我们没有定义交换机，但他底层使用的是默认交换机。

        在 RabbitMQ 中，生产者将消息发送到交换机（Exchange）中，经由交换机再路由到队列（Queue）中进行消费。因此，RabbitMQ 并不直接支持 Direct Queue，消息传递的过程中都需要通过交换机来完成路由功能。

        不过，RabbitMQ 提供了 Direct Exchange 类型，该类型的交换机将消息路由到与 Routing Key 匹配的队列中，可以理解为是直连队列。具体而言，当生产者发送消息时，需要指定一个 Routing Key，交换机会将消息根据 Routing Key 发送到与之匹配的队列中进行消费。

        因此，虽然 RabbitMQ 并没有直连队列的概念，但是可以通过使用 Direct Exchange 和指定 Routing Key 来实现相应的功能。在实际应用中，可以通过合理使用交换机和 Routing Key 的绑定关系，从而实现灵活且高效的消息传递。

简述rabbitmq的持久化机制

        在 RabbitMQ 中，消息的持久化机制可以确保在 RabbitMQ 服务宕机或者重启后消息不会丢失。RabbitMQ 的持久化机制主要包括以下几个方面：

        1. 持久化交换机和队列：将交换机和队列设置为持久化，即在 RabbitMQ 需要重启或宕机时，不会丢失这些交换机和队列的相关信息和配置。

        2. 持久化消息：生产者将消息设置为持久化，即在发送消息时需要添加 delivery mode 标志位，指定消息的持久化方式。在消费者接收到消息后，RabbitMQ 会将消息保存到磁盘中，确保消息不会在宕机或者重启后丢失。

        3. 同步刷盘：RabbitMQ 支持将消息写入内存缓存，同时定期将内存缓存清空，写回到磁盘中。这样可以减少每次写入磁盘的时间和 I/O 操作，提高消息处理效率。

        4. 持久化确认：消费者在处理消息后需要向 RabbitMQ 发送 Ack 操作，即确认消息已经被处理。当 RabbitMQ 接收到 Ack 操作后，才会将消息从磁盘中删除，确保消息不会重复投递和消费。

        总之，RabbitMQ 的持久化机制通过对交换机、队列、消息的持久化和同步刷盘等操作，确保消息在宕机或者重启后不会丢失，并通过持久化确认机制避免消息重复消费的问题，保证了 RabbitMQ 的稳定性和可靠性。

简述rabbitmq的普通集群模式

        普通集群：分布式集群，消息队列分散在集群的不同节点；消息也是分散在集群的不同节点，如果某个节点宕机，分散在这些节点上的队列不能使用。

        RabbitMQ 的普通集群模式是 RabbitMQ 最常见的集群模式之一，下面简要介绍一下：

        1. 概述：普通集群模式是指将多个 RabbitMQ 节点组成一个逻辑集群一起工作，实现消息分发的高可用性和负载均衡的功能。

        2. 架构：普通集群模式采用主从式设计，每个节点都可以同时作为生产者和消费者，每个集群内部可以有多个节点。在集群中，其中一个节点作为主节点，其他节点作为从节点，主节点负责完成集群的状态管理，包括队列、交换机、绑定关系等，并将该状态同步给从节点。当主节点失效时，从节点会自动选举出新的主节点，确保集群的正常运行。

        3. 配置：配置普通集群模式需要在每个节点上安装 RabbitMQ，并在每个节点上配置相同的用户名、密码、虚拟主机、交换机、队列等，确保节点之间的通信正常，并且实现消息的正确分发、路由和存储。同时，需要注意配置节点之间的同步策略，包括镜像队列、镜像交换机等。

        4. 优点：普通集群模式具有高可用性和负载均衡两个重要优点。当任何一个节点宕机时，消息可以自动切换到非宕机的节点上，确保消息的可靠传递。同时，普通集群模式还可以通过添加或移除节点来实现负载均衡的功能。

        总之，普通集群模式是 RabbitMQ 最常见的集群模式之一，通过高可用性和负载均衡的特性，可以有效地提高 RabbitMQ 的稳定性和性能。

rabbitmq的镜像集群

        镜像集群就是基于主从架构的集群，同一个队列可能在多个节点上都有；创建队列的节点就是主节点，备份到其他节点的节点称为镜像节点，主节点和镜像节点是相对的；备份策略有三种：1.exactly：指定镜像节点具体数字；2.all：集群中其他节点都会备份；3.nodes：指定哪些节点备份；缺点：仅仅保证主从节点的最终一致性

        RabbitMQ 的镜像集群是 RabbitMQ 中一种高可用性解决方案，具有数据自动同步和主节点选择等特点。它的基本原理是在多个节点之间同步数据，从而实现数据冗余和负载均衡。

        以下是 RabbitMQ 镜像集群的一些基本概念和特点：

        1. 镜像队列：镜像队列是 RabbitMQ 镜像集群的核心组件之一，它是普通队列的一种变体，可以使用它在多个节点之间进行消息自动同步。镜像队列通常由主队列（master）和多个镜像队列（mirror）组成，mirror 队列与主队列保持相同的 Bindings、arguments 和 policy，当消息在 master 队列中被入队或者出队时，镜像队列会与 master 队列同步。

        2. 镜像节点：为了保证 RabbitMQ 镜像集群的高可用性，通常需要在多个物理节点上运行多个 RabbitMQ Broker 实例，这样才能实现镜像同步和自动切换。在镜像集群中，主节点与多个镜像节点进行数据同步，当主节点发生宕机时，镜像节点会接管主节点的所有工作，以确保消息的高可用性和数据一致性。

        3. 同步策略：为了确保数据的一致性和可靠性，RabbitMQ 镜像集群需要设置同步策略，通常有两种策略：全部同步策略和异步同步策略。全部同步策略是指无论是从节点还是主节点，每个节点都要同时同步数据；而异步同步策略则是减少同步的时间和压力，从节点和主节点之间同步数据的时间可以有所延迟。

        4. 性能问题：RabbitMQ 镜像集群虽然提供了数据自动同步和主节点选择等特性，但同时也会带来一定的性能问题。镜像队列所带来的数据同步、消息路由的带宽开销和磁盘 I/O的增加，都会对 RabbitMQ 集群的性能产生一定的影响。因此需要综合考虑业务场景和数据量大小来决定是否采用 RabbitMQ 镜像集群。

        总之，RabbitMQ 镜像集群作为 RabbitMQ 中高可用性的解决方案之一，通过镜像队列和同步策略等方式实现数据的自动同步和主节点切换，从而确保消息的高可用性和数据的一致性。

幂等性

        幂等性是指对一个系统操作执行多次和执行一次的效果是一致的，即对同一个资源进行相同的操作，多次的结果和一次的结果是相同的。在分布式系统中，由于网络延迟和部分操作失败等原因，可能存在相同的请求，因此我们需要保证操作的幂等性。

        在实际开发中，为了保证操作的幂等性，可以采取以下几种方式：

        1. 去重：在接收到请求时，可以通过记录请求的 Id 或者其他唯一标识符，避免重复的请求操作。

        2. Token 验证：在请求中添加一个 Token，服务端在处理请求之前先判断 Token 是否有效，如果有效则说明请求没有被处理过，可以进行处理；否则说明请求已经被处理过，返回成功即可。

        3. 版本控制：在操作资源时，可以增加版本号控制，操作中对应的操作版本号和资源的版本号一致，则说明是有效的，可以进行操作；否则说明版本不匹配，返回操作失败即可。

        总之，幂等性对于分布式系统的可靠性和健壮性至关重要，特别是在高并发场景下，需要保证每个请求的唯一性和正确性。

Dubbo

Dubbo是什么？能做什么？

        Dubbo 是一种高性能的分布式服务框架，由阿里巴巴开源社区进行维护和开发，它支持面向接口的远程方法调用（RPC）和服务治理功能，被广泛应用于互联网、移动、企业级等领域。

        Dubbo 具有以下主要特点：

        1. 高性能：Dubbo 使用了多种技术手段来优化服务调用的性能，包括协议的优化、序列化的优化、线程池的优化等。

        2. 高可靠性：Dubbo 提供了丰富的服务治理功能，包括负载均衡、容错机制、服务降级、路由选择等，可以帮助用户提高服务的可靠性。

        3. 高扩展性：Dubbo 提供了丰富的扩展点，可以支持用户对框架的功能进行扩展和定制。比如它支持多种协议、多种注册中心和多种序列化协议等。

        4. 易于使用：Dubbo 的 API 设计和配置都非常简单易用，使用它可以快速搭建分布式服务。

        Dubbo 可以用于建立分布式应用和服务，它可以处理很多分布式环境下的问题，例如服务间的调用、服务发现、服务注册、服务降级等。在 Dubbo 的体系下，服务的调用者和提供者可以非常方便的进行互联互通，大大减少了企业中各种系统之间接口的繁琐管理工作，从而提高了研发效率。

        除此之外，Dubbo 还提供了其它丰富的功能，例如对服务健康监测、服务追踪、服务统计等的支持，这些功能可以帮助用户快速定位和解决分布式环境下的问题，提高服务的健壮性和可靠性。

Dubbo 的整体架构设计及分层

        Dubbo 是一款高性能的分布式服务框架，它的整体架构设计非常清晰，严格按照分层设计原则，主要分为以下几个层次：

        1. 服务接口层：该层包括服务接口和数据模型等定义，是服务的对外接口，用于定义服务的方法和参数等信息。在 Dubbo 中，服务接口层采用 Java 接口的方式来定义服务接口。

        2. 配置层：该层主要负责服务的配置和生命周期管理等工作，包括 Dubbo 中的配置中心和注册中心等。这一层对应的是 Dubbo 的配置模块，它用于对 Dubbo 的各个组件进行配置管理和生命周期的管理。

        3. 服务代理层：这一层主要负责将远程服务调用转换为本地服务调用的工作，该层会对服务接口进行代理，通过代理将服务的请求转发到远程机器上进行执行。

        4. 远程调用层：该层主要负责将本地调用的服务请求发送到远程服务提供者进行执行，并将执行结果返回给调用者。远程调用层支持多种协议的实现，包括 Dubbo 协议、HTTP 协议、RMI 协议等。

        5. 服务引入层：该层主要负责将服务引入到容器中进行管理，包括服务的发布、订阅等工作。Dubbo 提供了多种容器，例如 Spring 容器、Jetty 容器等。

        总之，Dubbo 的整体架构采用了分层设计原则，将服务接口、配置、生命周期管理、服务代理、远程调用等不同的功能进行了明确的划分，这种设计使得 Dubbo 在实际的分布式应用中具有很高的灵活性和可扩展性。

Spring Cloud和Dubbo的区别

        Spring Cloud 和 Dubbo 都是分布式服务框架，但在设计理念、架构模型以及技术实现等方面存在较大的差异。

        1. 设计理念： Spring Cloud 是基于 Spring Framework 基础上的构建，它强调基于微服务架构，为开发者提供了一系列的解决方案以快速搭建分布式系统；而 Dubbo 更强调 RPC（远程过程调用）框架的实现，提供远程调用和服务治理等支持。

        2. 架构模型： Spring Cloud 可以使用多种组件搭配完成微服务的构建，一般使用 Spring Cloud Eureka 作为服务发现以及 Spring Cloud Config 用于配置管理；而 Dubbo 是一套完整的微服务框架体系，包含服务注册中心、服务提供者、服务消费者、负载均衡、远程调用等组件。

        3. 技术实现： Spring Cloud 采用的通信协议是 HTTP/REST 以及基于 AMQP 的消息传递机制；而 Dubbo 采用的协议比较多，包括 Dubbo 协议、RMI 协议、HTTP 协议、Hessian 协议等。

        4. 开源社区： Spring Cloud 是 Spring 官方的一个子项目，享有广泛的社区支持和开发者参与；而 Dubbo 2011 年由阿里开源，社区活跃度也很高。

        总之，Spring Cloud 和 Dubbo 在设计理念、架构模型和技术实现等方面存在较大差异。Spring Cloud 更加注重微服务架构和解决方案，而 Dubbo 则更加注重 Dubbo 协议以及远程过程调用框架的实现。需要根据具体业务需求进行选择。

dubbo中Zk集群挂掉，发布者和订阅者还能通信么

        在 Dubbo 中，Zookeeper 作为服务注册中心，如果 Zk 集群挂掉，会影响 Dubbo 的服务注册和订阅功能，导致服务的提供者和消费者之间无法正常通信。

        具体地说，当 Zk 集群挂掉时，服务提供者仍然可以通过 Dubbo 的缓存机制向消费者提供服务，并不会因为注册中心的问题而出现访问异常。但是，新的服务提供者如果注册到该节点会失败，Dubbo 同时会每隔一段时间去恢复注册中心的连接，当 Zk 集群恢复之后，Dubbo 也会自动重新注册和订阅服务。

        因此，虽然 Zk 集群挂掉会短暂影响 Dubbo 的服务注册和订阅功能，但不会影响已经缓存的服务的提供，因此并不会导致服务完全不可用。

        另外，可以通过使用分布式部署、双机热备等方式，提高服务注册中心的可靠性，防止 SPOF（单点故障）造成的影响。

zk实际如何存储dubbo生产者和消费者信息

        在 Dubbo 中，Zookeeper 作为服务注册中心，主要用于 Dubbo 服务的注册和发现等功能。Zookeeper 在实际存储 Dubbo 生产者和消费者信息时，采用的是类似于文件系统的树形结构，每个节点包含了一些特定的数据信息。

        在 Dubbo 中，Zookeeper 的存储结构大致如下：

         - /dubbo：根节点，用于存放所有 Dubbo 服务的配置信息。

                - /dubbo/com.xxx.XxxService：服务接口路径，用于存放具体服务的相关信息。

                        - /dubbo/com.xxx.XxxService/providers：存放该服务的提供者信息，可以有多个。

                                - /dubbo/com.xxx.XxxService/providers/provider2：用于存放某个提供者的具体信息，例如 IP、端口等。

                        - /dubbo/com.xxx.XxxService/consumers：存放该服务的消费者信息，可以有多个。

                                - /dubbo/com.xxx.XxxService/consumers/consumer1：用于存放某个消费者的具体信息，例如 IP、端口等。

        其中，每个服务（如 com.xxx.XxxService）都有相应的提供者和消费者，这些信息都存储在 Zookeeper 的相应节点中。Dubbo 服务的发布者和订阅者各自维护一颗相同的节点树，并在树上注册自己所提供的服务或者要订阅的服务。当注册中心上服务节点信息发生变化后，订阅者节点能够获得通知，从而得以更新本地缓存。这样，订阅者就能够知道哪些服务提供者可用，并可以通过 Dubbo 框架对相应服务进行远程调用。

        总之，在 Dubbo 中，Zookeeper 作为服务注册中心，采用类似于文件系统的结构，存储 Dubbo 生产者和消费者信息，以及服务提供者和消费者之间的信息关系，进而实现 Dubbo 服务的注册和发现等功能。

Dubbo支持的注册中心有哪些

        在 Dubbo 中，服务注册中心是用于服务的发布与订阅管理、服务发现和路由等的核心组件。Dubbo 支持多种服务注册中心，包括：

        1. ZooKeeper：Apache ZooKeeper 是 Dubbo 默认的服务注册中心，用于保存 Dubbo 应用的元数据，包括服务发布者信息、服务消费者信息以及服务提供者信息等。同时支持如负载均衡、故障恢复等其他服务治理功能。

        2. Redis：Redis 作为一款快速、可靠、支持多种数据结构的数据库，可以作为 Dubbo 的服务注册中心，存储 Dubbo 应用的元数据。同时，Redis 还能够通过 Sentinel 等工具实现高可用性。

        3. Simple：Simple 注册中心是一种基于内存的简单的注册中心，适用于开发和测试环境。在 Simple 注册中心中，元数据信息被存储在当前进程内存中，当进程停止时数据也会被清空。

        4. Multicast：Multicast 注册中心是一种基于广播和组播协议实现的注册中心，具有简单、易用和高效的特点。它可以在局域网内广播注册信息，不需要单独的注册中心。

        5. etcd3：etcd3 是一个高可用的分布式键值存储，提供多语言客户端和 API，avro、HTTP 及 gRPC 等多种调用方式。Dubbo 通过 etcd3 的 API 支持服务的注册与发现，而 etcd3 自身通过分布式一致性算法保证数据的可靠性。

        总之，Dubbo 支持多种服务注册中心，使用者可以根据实际业务需求进行选择。其中，ZooKeeper 是 Dubbo 默认的服务注册中心，使用最为广泛。另外，除了上述注册中心，Dubbo 还支持 Nacos、Consul 等多种注册中心。

dubbo为什么推荐zookeeper做注册中⼼ 

        Dubbo 推荐使用 ZooKeeper 作为服务注册中心，原因如下：

        1. 轻量级：ZooKeeper 是一种轻量级的分布式数据协调服务，可以轻松地嵌入到 Dubbo 中，不需要复杂的部署和配置。

        2. 高可用性：ZooKeeper 通过提供多级数据节点来保证系统的高可用性，Zookeeper 的主节点（Leader）与备份节点（Follower）之间可以实现自动切换，一定程度上提高了系统的可靠性。

        3. 实时性：ZooKeeper 提供了监控机制和回调机制，可以实现服务的实时检测和回调通知，保证 Dubbo 服务的实时性和可靠性。

        4. 一致性：ZooKeeper 采用了过半数原则来避免分布式协调问题，只要 Zk 集群中过半数的节点正常工作，就可以保证系统的一致性。

        5. 分布式锁机制：ZooKeeper 还提供了分布式锁机制，可以解决分布式环境下的并发问题，避免重复操作和数据冲突。

        综上所述，Dubbo 推荐使用 ZooKeeper 作为服务注册中心，主要原因就是它提供了高可用性、实时性、一致性和分布式锁机制等关键特性，可以保证 Dubbo 服务的高效、稳定和可靠运行。同时，Dubbo 通过提供 ZooKeeper 同步连接和异步连接两种方式，进一步优化了系统性能和响应速度。

dubbo集群容错策略有哪些

        Dubbo 集群容错策略是 Dubbo 分布式架构中的重要组成部分，用于在面对节点故障和请求高峰等异常情况时，保证系统的高可用和容错能力。常见的 Dubbo 集群容错策略如下：

        1. Failover Cluster：重试其他机器，通常用于幂等的读操作，不推荐用于写操作。也就是当某一次服务访问失败时，自动切换其他可用节点，重试次数可配置，默认为 3 次。

        2. Failfast Cluster：快速失败，通常用于非幂等请求的读写操作。也就是当某一次服务访问失败时，立即返回错误信息，不再尝试其他节点。

        3. Failsafe Cluster：失败安全，通常用于无关紧要的非幂等读操作，出现异常时直接忽略即可。

        4. Failback Cluster：失败自动恢复，通常用于长连接场景。失败后，Dubbo 自动重试，重试成功后，恢复正常调用。

        5. Forking Cluster：并行调用多个提供者，只要一个成功即返回，用于实现容错并行操作场景。

        6. Broadcast Cluster：广播调用，同时调用所有提供者，通常用于通知所有消费者更新缓存等场景。

        总之，Dubbo 集群容错策略通过多种机制保证了 Dubbo 系统的高可用、高容错、高可靠运行。但是，不同的容错策略也有不同的适用场景，需要根据具体的业务需求和系统特点进行选择和配置。同时，在 Dubbo 中也可以自定义集群容错策略，以满足更为复杂和个性化的应用场景。

dubbo支持的协议有哪些

        Dubbo 支持多种协议，常见的 Dubbo 协议包括：

        1. Dubbo 协议：Dubbo 协议是 Dubbo 自定义的二进制传输协议，具有高效、可压缩、支持实时传输等特点，能够大幅度提升 Dubbo 服务的性能和吞吐量。

        2. RMI 协议：Dubbo 也支持使用 RMI（Remote Method Invocation）协议进行 RPC 调用，但相较于 Dubbo 协议，RMI 协议的性能和稳定性相对较差。

        3. Hessian 和 HTTP 协议：这两个协议均基于 HTTP 传输，Hessian 序列化协议传输效率较高，但仅支持 Java 语言；HTTP 协议比较通用，适合多语言环境下的调用。

        4. Thrift 协议：与 Dubbo 一样，Thrift 也是 RPC 框架，Dubbo 支持使用 Thrift 作为协议进行调用，能够实现跨语言的 RPC 调用。

        5. gRPC 协议：gRPC 是 Google 开源的高性能 RPC 框架，Dubbo 同样支持使用 gRPC 作为协议进行调用，能够实现跨语言的高性能RPC 通信。

        总之，Dubbo 支持多种协议，每一种协议都有其特殊的优点和适用场景，使用者可以根据实际业务需求进行选择和配置。与传统的 HTTP 协议相比，Dubbo 协议具有更高的效率、更低的延迟和更好的性能，因此被广泛应用于实时性要求较高的业务场景中。

dubbo负载均衡

        Dubbo 负载均衡是指根据设定的负载均衡策略，在多个服务提供者节点中选择一个节点进行请求响应，从而实现负载均衡的处理过程。 Dubbo 支持多种负载均衡算法，常见的算法包括：

        1. Random LoadBalance：随机调用，从可用的服务提供者中随机选择一个节点进行调用。

        2. Round Robin LoadBalance：轮询调用，将请求依次调度到每一个节点上，采用平均分配的方式来实现均衡负载。

        3. Least Active LoadBalance：最少活跃调用，每次调用都会统计当前可用的节点数，并选择活跃度最低的节点。

        4. Consistent Hash LoadBalance：一致性哈希调用，根据请求参数的哈希值，将请求调用到下游服务的特定节点上，达到负载均衡的目的。

        除了上述常见的负载均衡算法之外，Dubbo 还支持自定义负载均衡算法。Dubbo 在实现负载均衡时，还考虑了节点的状态和权重等因素，从而实现更为精确和高效的负载均衡策略。

        总之，Dubbo 负载均衡通过选择合适的算法和策略来实现请求的均衡分发，从而避免单点故障和请求堆积等问题，提高了 Dubbo 的系统可用性和性能。

dubbo服务降级怎么实现

        Dubbo服务降级是指在 Dubbo 服务的高峰期或者服务出现异常时，先暂停某些不太重要的服务调用，保证重要的服务能够正常运行。Dubbo 实现服务降级主要通过提供 Mock 功能和 Hystrix 模块来实现。

        1.Mock 功能

        Dubbo 提供了 Mock 功能，可用于实现服务降级。具体实现方法是：如果消费者超时或者出现异常，Dubbo 会调用 Mock 类中的 Mock 方法，返回一个预设的 Mock 数据，作为服务降级的结果输出。开发者在配置响应服务时可以通过 “mock” 属性指定对应的 Mock 类，实现代码如下：

        2.Hystrix 模块

        Hystrix 是一个开源的分布式容错框架，可以实现服务降级、服务熔断、服务限流等功能。Dubbo 通过集成 Hystrix 模块来实现服务降级，具体实现方法如下：

• 引入 Hystrix 依赖，如下：

  
      com.netflix.hystrix
      hystrix-core
      1.5.12
  

  • 实现 HystrixCommand

• 开发者需要继承 HystrixCommand 类，重写 run() 和 getFallback() 方法，在 run() 方法中调用远程服务，通过 getFallback() 方法来实现服务降级，代码如下：

  public class UserServiceHystrixCommand extends HystrixCommand {
  
      private UserService userService;
      private Long id;
  
      public UserServiceHystrixCommand(UserService userService, Long id) {
          super(HystrixCommandGroupKey.Factory.asKey("DubboGroup"));
          this.userService = userService;
          this.id = id;
      }
  
      @Override
      protected String run() throws Exception {
          return userService.getUserById(id);
      }
  
      @Override
      protected String getFallback() {
          return "服务降级，访问用户信息失败！";
      }
  }

  通过上述实现，当 Dubbo 服务在网络故障或者处理超时时，引入 Hystrix 后，系统将自动切换到 fallback() 方法，并返回 “服务降级，访问用户信息失败！” 的信息。

  总之，Dubbo 通过 Mock 和 Hystrix 两种方式来实现服务降级，最大限度地保证 Dubbo 服务运行的稳定性、可靠性和高可用性。在实际应用中，开发者可以根据业务需求和系统特点，选择合适的设定、设置服务降级策略，从而实现更为智能和高效的 Dubbo 服务管理。