1.Dubbo 负载均衡策略？
Dubbo 是一个分布式服务框架，它提供了多种负载均衡策略来分发服务调用。在 Dubbo 中，负载均衡的实现是基于客户端的，即由服务消费者（Consumer）端决定如何选择服务提供者（Provider）。以下是 Dubbo 支持的一些常见的负载均衡策略：
Random LoadBalance (随机)
默认情况下，Dubbo 使用的是加权随机算法。所谓加权随机，就是根据每个服务提供者的权重配置，按照比例随机选取服务提供者。
RoundRobin LoadBalance (轮询)
按照顺序循环调用，当有多个提供者时，每次请求会按序轮流调用不同的提供者，如果某个提供者不可用，则跳过。
LeastActive LoadBalance (最少活跃调用)
这个策略会选择当前活跃调用数最小的服务提供者。这里的“活跃调用”是指未完成的调用数量。对于权重较高的服务提供者，会有更高的几率被选中。
ConsistentHash LoadBalance (一致性哈希)
根据参数进行哈希，保证相同参数的请求总是发送到同一个提供者上。这对于需要保持会话状态的应用非常有用。可以通过指定hash.arguments参数来设置参与哈希计算的方法参数位置。
ShortestResponse LoadBalance (最短响应时间)
选择历史平均响应时间最短的服务提供者。这个策略不是默认提供的，可能需要通过扩展点机制自行实现。
使用这些策略时，可以在服务消费者的配置文件或代码中指定想要使用的负载均衡策略。例如，在 XML 配置文件中，可以通过 < dubbo:reference > 标签的loadbalance属性来设置。
<dubbo:reference id="demoService" interface="com.alibaba.demoservice.DemoService" loadbalance="leastactive"/>
此外，Dubbo 的负载均衡策略是可插拔的，这意味着你可以通过实现自己的负载均衡算法并注册为 Dubbo 的 SPI 扩展来添加自定义的负载均衡策略。
2. Dubbo 容错策略
Dubbo 提供了多种容错策略（Fault Tolerance Strategy）来确保服务调用的高可用性和稳定性。这些策略决定了当服务调用失败时，Dubbo 将如何处理。以下是 Dubbo 支持的主要容错策略：
Failover Cluster (重试)
这是默认的容错策略。如果调用失败，则会从注册中心获取的服务列表中选择其他服务提供者进行重试，直到达到最大重试次数（默认为2次）。对于幂等性操作来说，这是一个不错的选择。
Failfast Cluster (快速失败)
只发起一次调用，如果调用失败立即报错。适用于非幂等性的操作，如新增记录，避免重复执行带来的问题。
Failsafe Cluster (安全失败)
即使出现异常也不会抛出，而是直接忽略异常。适用于写入审计日志等操作，即使失败也不影响主流程。
Failback Cluster (失败自动恢复)
如果调用失败，它不会立刻抛出异常，而是在后台定时重试。通常用于消息通知、日志收集等场景，允许一定程度上的延迟处理。
Forking Cluster (并行调用多个服务器)
同时调用多个服务提供者，并发数可以指定（默认为2），只要一个成功即返回。适用于对响应时间敏感但又要求高可用性的场景。
Broadcast Cluster (广播调用所有服务器)
调用所有提供者，逐个调用，任意一台报错则报错。常用于需要将数据同步到所有节点的情况，例如缓存更新或配置更新。
这些策略可以在服务消费者的配置文件或代码中通过dubbo:reference标签的cluster属性来设置。例如：
< dubbo:reference id="demoService" interface="com.alibaba.demoservice.DemoService" cluster="failover"/>
除了上述内置策略外，Dubbo 还支持自定义集群容错策略。你可以通过实现com.alibaba.dubbo.rpc.cluster.Cluster接口，并通过 SPI 机制注册你的自定义策略。
选择合适的容错策略对于构建稳定可靠的服务非常重要，应根据具体的业务需求和场景来决定采用哪种策略。
3. Dubbo 动态代理策略有哪些？
Dubbo 支持多种动态代理策略，允许开发者根据需求选择最适合的代理方式。动态代理机制在 Dubbo 中主要用于创建服务接口的代理实例，以便在调用这些接口时可以透明地执行远程过程调用（RPC）。以下是 Dubbo 支持的一些主要动态代理策略：
Javassist 动态字节码生成
这是 Dubbo 默认使用的动态代理方式。Javassist 是一个用于编辑 Java 字节码的库，它可以在运行时生成新的类和方法，因此非常适合用来创建动态代理。
JDK 动态代理
JDK 自带的动态代理机制依赖于接口，通过反射机制为接口生成代理对象。如果服务提供者实现了接口，则可以使用此方式来创建代理。
CGLIB 动态代理
CGLIB（Code Generation Library）是一个强大的高性能代码生成库，它可以在运行时扩展 Java 类和实现接口。与 JDK 动态代理不同的是，CGLIB 不需要目标类实现接口即可生成代理。
ByteBuddy 动态代理
ByteBuddy 是另一个流行的字节码操作库，它可以用来生成、转换和加载 Java 类。它比 Javassist 和 CGLIB 更加现代，并且提供了更简洁的 API。
基于 SPI 的动态代理
Dubbo 通过 SPI（Service Provider Interface）机制支持自定义动态代理策略。用户可以通过实现 ProxyFactory 接口来自定义代理逻辑，并将其注册到 Dubbo 的扩展点中。
Spring AOP 动态代理
虽然这不是 Dubbo 内置的功能，但可以通过集成 Spring 框架利用 Spring AOP 来进行动态代理。这使得可以在不修改原有代码的情况下，通过拦截方法调用来实现额外功能。
基于注解的动态代理
Dubbo 支持通过注解指定代理方式。例如，可以使用特定注解如 @ProxyBean 或 @Service 来指示 Dubbo 使用 JDK 或 CGLIB 等方式进行代理。
选择哪种动态代理策略取决于具体的应用场景和技术要求。默认情况下，Dubbo 使用 Javassist 进行动态代理，因为它通常能提供较好的性能和灵活性。然而，在某些情况下，比如当项目已经广泛使用了 CGLIB 或者想要避免引入额外依赖时，可能会选择其他的代理方式。此外，通过 SPI 扩展机制，还可以轻松添加或切换不同的代理实现。
4.说说 Dubbo 与 Spring Cloud 的区别？
Dubbo 和 Spring Cloud 都是用于构建分布式系统和服务治理的框架，但它们在设计理念、架构背景、通信协议、服务调用方式、注册中心支持以及适用场景等方面存在显著差异。以下是两者的主要区别：
架构背景和定位
- Dubbo：起源于 SOA（面向服务的架构）时代，主要聚焦于服务的调用、流量管理和监控等功能。它旨在提供高效的 RPC（远程过程调用）解决方案。
- Spring Cloud：诞生于微服务架构时代，涵盖了微服务治理的方方面面，关注服务注册与发现、配置管理、断路器、路由等。它建立在 Spring 和 Spring Boot 的生态之上，提供了更全面的微服务解决方案。
通信协议和服务调用
- Dubbo：使用 Netty 等 NIO 框架，基于 TCP 协议进行通信，配合 Hessian 序列化实现高效的二进制传输。RPC 调用方式意味着服务消费者和提供者之间存在较强的代码依赖关系。
- Spring Cloud：通常基于 HTTP 协议和 REST 接口进行通信，虽然 HTTP 请求的带宽占用较大，但 REST 的灵活性使得服务提供者和消费者之间的依赖关系相对松散，依赖契约而非代码，这在强调快速演化的微服务环境下更为合适。
注册中心和支持
- Dubbo：最初仅支持 ZooKeeper 作为注册中心，后来扩展支持了 Nacos 等其他注册中心。它的设计更专注于服务治理功能。
- Spring Cloud：支持多种注册中心，如 Eureka, Consul, Zookeeper 等，并且通过 Spring Boot 提供了一套简化配置和使用的工具集。
生态系统
- Dubbo：由于其高性能和轻量级特性，适合对性能有高要求的应用场景，特别是在电商领域有着广泛的应用。
- Spring Cloud：拥有更加丰富的生态系统，包括但不限于配置管理、熔断机制、智能路由、微代理、控制总线、一次性 token、全局锁、选主、分布式会话和集群状态等，适用于广泛的微服务架构需求。
监控和管理
- Dubbo：提供了 Dubbo Monitor 等工具用于监控和管理微服务。
- Spring Cloud：除了上述提到的各种子项目外，还提供了 Spring Boot Admin 等工具用于监控和管理微服务。
总结
选择 Dubbo 还是 Spring Cloud 取决于具体的业务需求和技术栈偏好。如果项目需要高性能的远程调用并且对服务间的耦合度较高，Dubbo 是一个很好的选择；而对于那些追求灵活的服务定义、解耦的服务间通信以及完整的微服务治理方案，则 Spring Cloud 更具优势。在实际应用中，也可以根据项目的不同部分选择不同的框架组合使用，以达到最佳效果。
5.Zookeeper 和 Dubbo 的关系？
ZooKeeper 和 Dubbo 之间的关系主要体现在服务注册与发现上。Dubbo 是一个高性能的 Java RPC 框架，而 ZooKeeper 则是一个分布式协调服务，通常被用作 Dubbo 的服务注册中心。以下是它们之间关系的具体说明：
服务注册与发现
- 服务提供者注册：当一个服务启动时，它会将自己提供的服务接口信息（如服务名、版本号、地址等）注册到 ZooKeeper 中。这些信息会被存储为 ZooKeeper 中的节点（znode），并且可以设置为临时节点，以便在服务不可用或宕机时自动从注册表中移除。
- 服务消费者订阅：服务消费者启动后，会向 ZooKeeper 订阅它感兴趣的服务接口。一旦有新的服务提供者加入或已有提供者下线，ZooKeeper 会通知订阅了该服务的所有消费者，从而保证服务列表的实时更新。
动态路由和负载均衡
- 使用 ZooKeeper 作为注册中心，可以帮助实现动态路由规则和服务权重配置等功能。例如，可以根据不同的条件（如地理位置、服务器性能等）来调整流量分配策略，或者对某些服务提供者设置更高的权重以增加其被选中的概率。
配置管理
- ZooKeeper 还可以用来集中化管理配置信息。Dubbo 的一些配置项可以通过 ZooKeeper 来进行动态调整，比如超时时间、重试次数等，而无需重启应用。
高可用性
- ZooKeeper 自身具有高可用性和一致性保障，通过复制日志、选举机制等手段确保集群内所有节点的数据一致。这使得即使单个 ZooKeeper 节点出现故障，整个注册中心仍然能够正常工作，进而提高了基于 ZooKeeper 的 Dubbo 服务调用的可靠性。
版本控制
- 在某些情况下，ZooKeeper 可用于维护不同版本的服务定义，帮助实现平滑升级和回滚。例如，在新版本服务上线前，可以在 ZooKeeper 中预先发布新版本的服务信息，并逐步引导流量到新版本上来。
综上所述，ZooKeeper 在 Dubbo 架构中扮演着至关重要的角色，不仅实现了高效的服务注册与发现，还支持了诸如配置管理、动态路由等高级特性，增强了系统的灵活性和可扩展性。不过值得注意的是，虽然 ZooKeeper 是 Dubbo 默认的服务注册中心之一，但并不是唯一选择。随着技术的发展，Nacos、Consul 等其他注册中心也逐渐成为 Dubbo 生态的一部分，提供了更多的选择和功能。
