SpringCloud Alibaba 工作总结

Ocean@上源码

已于 2023-11-02 09:06:23 修改

阅读量386

点赞数 8

分类专栏： SpringCloud 文章标签： springcloud

于 2023-10-30 11:15:02 首次发布

本文链接：https://blog.csdn.net/qq_34253002/article/details/133783830

版权

SpringCloud 专栏收录该内容

10 篇文章 0 订阅

订阅专栏

1.消费者启动报错

设置消费方启动时不检查提供方是否可用。

dubbo:
  consumer:
    check: false  # 关闭提供方检查，避免无法启动（还都是单体项目，提高发布效率减少停机时间）

2.spring-cloud-alibaba 升级报错

依赖版本：

spring-boot：2.3.12.RELEASE

spring-cloud-alibaba：2.2.7.RELEASE

spring-cloud：Hoxton.SR12

nacos：2.0.3

2.1ReferenceAnnotationBeanPostProcessor.setClassValuesAsString(Z)V

解决办法：升级jar包

        <dependency>
            <groupId>com.alibaba.spring</groupId>
            <artifactId>spring-context-support</artifactId>
            <version>1.0.11</version>
        </dependency>

2.2 namingService subscribe failed

解决办法：开放9848 和9849端口

3.Dubbo 负载均衡策略

一、随机策略（random 默认）
随机策略是Dubbo默认的负载均衡策略，它的原理是从提供者列表中随机选择一台服务器进行调用。由于是随机选择，因此每个提供者被调用的概率是基本相等的，这样可以达到基本的负载均衡效果。

二、轮询策略（roundrobin）
轮询策略是Dubbo使用较为广泛的负载均衡策略之一，它的原理是按照提供者列表的顺序依次调用不同的服务器。每次调用完毕后，将下一次调用的服务器序号递增，直到底部后再从头开始，这样可以实现均衡地调用每个提供者的效果。

三、最小活跃度策略（leastactive）
最小活跃度策略是Dubbo 2.5以后推出的，它的原理是记录每个提供者正在处理的请求个数，调用时选择活跃度最低的服务器进行处理。活跃度指正在处理请求的个数，越少的服务器说明拥有越多的处理能力，这样可以达到负载均衡的效果。

四、一致性哈希策略（consistanthash）
一致性哈希策略是一种基于哈希算法的负载均衡策略，它的原理是将每个服务器节点映射到一个哈希环上。根据客户端请求的哈希值，将请求调用到距离它最近的服务器节点进行处理。这样可以尽可能地减少服务器节点的变化对负载均衡的影响。

五、权重轮询策略（weightedrroundrobin）
权重轮询策略是一种基于轮询策略的负载均衡策略，它的原理是在提供者列表中，根据每个提供者设置的权重值来调整调用次数。即设置权重值较大的服务器调用次数较多，设置权重值较小的服务器调用次数较少。这样可以根据每个服务器的性能来进行负载均衡。

六、请求次数限制策略（weightedrandom）
请求次数限制策略是一种基于随机策略的负载均衡策略，它的原理是在随机调用提供者时，限制每个提供者被调用的次数，达到调用次数限制后将该提供者从列表中移除，直到列表为空后才重新随机调用并重置次数。这样可以避免请求集中于某一台服务器而导致其他服务器的负载不均衡。

3.1 配置文件配置

dubbo:
  consumer:
    # 1.random 随机 默认 2.roundrobin 轮询 3.leastactive 最小活跃度 4. consistanthash 一致性哈希 5.weightedroundrobin 权重轮询 6.weightedrandom 请求次数限制
    loadbalance: random

3.2 代码中单独指定

    @DubboReference(loadbalance = "leastactive")
    private XxxProviderService xxxProviderService;

代码中单独设置的负载均衡策略会覆盖掉配置文件中设置的负载均衡策略，即代码中指定负载均衡策略的优先级高于配置文件中设置的。

4.Dubbo 容错策略

Failover Cluster 失败自动切换，自动重试其他服务器（默认）
Failfast Cluster 快速失败，立即报错，只发起一次调用
Failsafe Cluster 失败安全，出现异常时，直接忽略
Failback Cluster 失败自动恢复，记录失败请求，定时重发
Forking Cluster 并行调用多个服务器，只要一个成功即返回
Broadcast Cluster 广播逐个调用所有提供者，任意一个报错则报错
Mock Cluster 响应失败时返回伪造的响应结果
Available Cluster 遍历查找所有服务列表，找到第一个可以返回结果的节点，并且返回结果
Mergable Cluster 将多个节点请求合并进行返回

4.1 配置文件配置

dubbo:
  consumer:
    cluster: failover   # 1.failover 失败转移 默认 2.failfast  快速失败 3.failsafe 失败忽略 4.faliback  记录定时重试 5.forking 多个一起调用，只要一个成功即可 6.broadcast 逐个调用所有
    retries: 2  # 默认 2

4.2 代码配置

4.2.1 服务提供者

@DubboService(cluster = "failover" , retries = 3)
public class XxxProvider implements XxxProviderService {

 
}

4.2.2服务消费者

    @DubboReference(cluster = "failover", retries = 3)
    private XxxProviderService xxxProviderService;

5.Dubbo vs Feign

一、Feign是什么？
Feign是Spring Cloud提供的一个声明式的伪Http客户端，它使得调用远程服务就像调用本地服务一样简单，只需要创建一个接口并添加一个注解即可。
二、Dubbo是什么？
Dubbo是阿里巴巴开源的基于Java的高性能RPC分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

Feign和Dubbo都可以实现远程调用，他们都依赖注册中心，他们都支持负载均衡，服务熔断。
Feign是基于Http协议。服务提供者需要对外暴露Http接口供消费者调用服务粒度是http接口级的。通过短连接的方式进行通信，不适合高并发的访问。Feign追求的是简洁，低入侵。
Dubbo支持多传输协议(Dubbo、Rmi、http、redis等等)，可以根据业务场景选择最佳的方式，非常灵活。默认的Dubbo协议：利用Netty，TCP传输，单一、异步、长连接，适合数据量小、高并发和服务提供者远远少于消费者的场景。
Dubbo通过TCP长连接的方式进行通信，服务粒度是方法级的。从协议层选择看，Dubbo是配置化的，更加灵活。Dubbo协议更适合小数据高并发场景。

持续更新维护中。