服务治理篇

超时时间

场景就不用说了吧，懂得都懂

实现

无论是服务提供者还是调用者都可以配置，如果都配了，基本上结果是取最小的那个

// 调用方注解 配置  
// 控制一个服务下所有方法
@DubboReference(check = false,timeout = 1000)
// 控制一个服务某些方法(方法可以指定控制多个)
@DubboReference(check = false,methods = {@Method(name = "方法名",timeout = 1000)})

// 提供方注解 配置
// 控制一个服务下所有方法
@DubboService(timeout = 2000)
// 控制一个服务某些方法(方法可以指定控制多个)
@DubboService(methods = {@Method(name = "方法名",timeout = 2000)})

效果

重试

实现

无论是服务提供者还是调用者都可以配置，如果都配了，基本上结果是取最大的那个（默认都是2）

// 调用方注解 配置
// 控制一个服务下所有方法
@DubboReference(check = false,retries = 4)
// 控制一个服务某些方法(方法可以指定控制多个)
@DubboReference(check = false,methods = {@Method(name = "方法名",retries = 4)})

// 提供方注解 配置
// 控制一个服务下所有方法
@DubboService(retries = 3)
// 控制一个服务某些方法(方法可以指定控制多个)
@DubboService(methods = {@Method(name = "方法名",retries = 3)})

并发控制

使用场景

控制某些服务的最大并发请求数，确保其他服务的资源可用性。系统过载和确保系统稳定性。

允许在需求增加时更平滑地扩展服务。

确保服务在高峰使用时间保持可靠和稳定。

实现

有两种语义的控制方法：服务端并发执行数、客户端并发执行数

服务端并发执行数：不区分客户端，总体并发数(占用线程池线程数)

// 提供方注解 配置
// 控制一个服务下所有方法
@DubboService(executes= 10)
// 控制一个服务某些方法(方法可以指定控制多个)
@DubboService(methods = {@Method(name = "方法名",executes= 10)})

客户端并发执行数：区分客户端，就是每个客户端占用连接的请求数

// 提供方注解 配置
// 控制一个服务下所有方法
@DubboService(actives= 10)
// 控制一个服务某些方法(方法可以指定控制多个)
@DubboService(methods = {@Method(name = "方法名",actives= 10)})


// 调用方注解 配置
// 控制一个服务下所有方法
@DubboReference(check = false,actives= 10)
// 控制一个服务某些方法(方法可以指定控制多个)
@DubboReference(check = false,methods = {@Method(name = "方法名",actives= 10)})

权限控制

使用场景

通过令牌验证在注册中心控制权限，以决定要不要下发令牌给消费者， 可以防止消费者绕过注册中心访问提供者， 另外通过注册中心可灵活改变授权方式，而不需修改或升级提供者

实现

// 提供方注解 配置 true代表：随机token令牌，使用UUID生成
@DubboService(token="true")
or
// 固定token令牌，相当于密码
@DubboService(token="132456")

效果

正常通过注册中心远程调用的不受影响

而直接走本机的rest调用则被拦截

服务降级

使用场景

• 某服务或接口负荷超出最大承载能力范围，需要进行降级应急处理，避免系统崩溃
• 调用的某非关键服务或接口暂时不可用时，返回模拟数据或空，业务还能继续可用
• 降级非核心业务的服务或接口，腾出系统资源，尽量保证核心业务的正常运行
• 某上游基础服务超时或不可用时，执行能快速响应的降级预案，避免服务整体雪崩

实现

在调用者配置文件中加入配置

dubbo:
  consumer:
    filter: mock

在注解上加入mock参数，有几种配置方法：

1. 全路径名

2. mock="[fail|force]return|throw xxx"

   • fail 或 force 关键字可选，表示调用失败或不调用强制执行 mock 方法，如果不指定关键字默认为 fail
   • return 表示指定返回结果，throw 表示抛出指定异常
   • xxx 根据接口的返回类型解析，可以指定返回值或抛出自定义的异常 如： return null：代表失败返回null

   throw java.lang.NullPointException ： 失败抛出指定异常

我这里采用全路径名

@DubboReference(check = false,mock = "cn.colins.api.TestServiceMock")

在API模块下新建一个实现类：

public class TestServiceMock implements TestService {
    private final static Logger log= LoggerFactory.getLogger(TestServiceMock.class);
    @Override
    public String test(String message) {
        // 返回
        return "我被降级了";
    }
}

效果：当调用发生异常

负载均衡

实现

具体实现上，Dubbo 提供的是客户端负载均衡，即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例

负载均衡策略

目前 Dubbo 内置了如下负载均衡算法，用户可直接配置使用：

算法	特性	备注
random	加权随机	默认算法，默认权重相同
roundrobin	加权轮询	借鉴于 Nginx 的平滑加权轮询算法，默认权重相同
leastactive	最少活跃优先 + 加权随机	背后是能者多劳的思想
shortestresponse	最短响应优先 + 加权随机	更加关注响应速度
consistenthash	一致性 Hash	确定的入参，确定的提供者，适用于有状态请求

注解

// 调用者通过 loadbalance 选取策略
@DubboReference(check = false,loadbalance = "consistenthash")
// 也可以控制在方法级别
@DubboReference(check = false,methods = {@Method(name = "方法名",loadbalance = "consistenthash")})

// 提供者通过 weight 设置权重
// 这个也有loadbalance 参数，但是我具体没测
@DubboService(loadbalance = "roundrobin",weight = 5)

集群容错

使用场景

多个服务器部署同一集群中，运行同一应用程序，如果一台服务器出现故障，其他服务器将接管负载，确保应用程序对用户仍然可用。

实现

集群容错常见策略有以下几种：

• failover：失败自动切换，默认值；当调用失败时，自动切换到另一个可用的服务提供者进行重试，重试次数由 retries参数指定
• failfast：快速失败；当调用失败时，立即报错，不进行任何重试操作；
• failsafe：失败安全；当调用失败时，直接忽略错误，不进行任何处理；
• failback：失败自动恢复。当调用失败时，记录失败的请求并异步重试，重试次数由 retries参数指定。
• forking：并行调用多个服务器，只要有一个成功即返回，
• broadcast：广播调用所有提供者，任意一个报错则报错

// 指定消费者端的集群容错策略
@DubboReference(check = false,cluster = "failover")

// 指定服务提供者端的集群容错策略。
@DubboService(cluster = "roundrobin")

备案号：鄂ICP备2023006484号-1浏览量: 0