基于Rainbond实现服务熔断和全局限流

概述

本文档讲述基于Rainbond⽹络治理插件,实现服务熔断,全局限流的原理、思路、及具体方式。

一. ⽹络治理插件

5.1.5版本后,Rainbond默认提供了综合网络治理插件(同时处理入站和出站网络)和出站网络治理插件两个插件可用。

Rainbond⽹络治理插件界面

1.1 服务网络治理插件-出站治理

UI服务安装了服务⽹络治理插件,该插件作⽤于流量的出⼝,即通向API服务的⼀端。出站治理插件会接⼿管理流向API服务的流量,并可以配置条件,实现熔断。

1.2 服务综合网络治理插件-出⼊站共治

服务综合⽹络治理插件,是出站治理插件的升级版本。兼容原有功能之余,新增了⼊站治理功能;同时实现了入站方向的治理和出站方向的治理。

更多关于网络治理插件说明请参阅 SERVICEMESH网络治理插件说明

二. 服务熔断

服务熔断,是⼀种保护下游服务(UI服务)的机制。

当来⾃UI的请求堆积于上游服务(API服务),超越了API服务的处理能⼒的时候。 熔断机制会发⽣作⽤,让UI服务去请求其他可⽤的API服务。总之不要在已经被熔断 的API服务这⾥等待回应。

作用

可以避免UI服务中其他进程,因为请求API服务没有响应,⽽发⽣堆积,最终撑爆UI服务本身。服务熔断只作⽤于指定的下游服务

服务熔断实践

实验目的:对todoshow出站方向实现服务熔断

实验环境:

实验配置:

 关键参数:
• MaxConnections #最⼤连接数,Http协议时仅适⽤于http1.1,TCP协议时设置最⼤TCP连接数。
• MaxRequests    #并发请求数,适⽤于HTTP协议
• MaxPendingRequests #最⼤等待请求数,适⽤于HTTP协议
• MaxActiveRetries   #最⼤重试次数,适⽤于HTTP协议
• MaxRequestsPerConnection #单连接最⼤请求数,适⽤于HTTP协议,⽀持http1.1 和http2 

在入站出站都可以做熔断策略;不同点是在入站做熔断时,所有外部请求访问时都会受到限制,具有全局性特性;而在出站做熔断时,只针对下游应用,适合拥有很多下游应用去针对不同应用做不同配置。

实验原理:

  1. 在todoshow应用中配置服务综合网络治理插件;
  2. 使用Apache JMeter测试工具向todoshowUI应用发起并发性请求;触发熔断,返回503状态码(由网络综合治理插件返回)。
  • 查看返回503状态码

  • 可以看出来熔断机制生效,60%的请求被熔断掉。

三. 全局限流

全局限流,是⼀种保护上游服务(API服务)的机制;是基于服务综合网络治理插件实现,作用在入站治理。

当来⾃UI服务的请求,超越API服务的处理能⼒。限流机制会发⽣作⽤,全局限流可以对访问到API服务的所有流量进⾏限制。

作用

可以保证进⼊到API服务的流量始终保持⼀个合适的值,防⽌了API服务因为请求过量⽽被撑爆。限流时可以⽤IP作为限流条件,从⽽实现⿊/⽩名单功能。需要借助第三⽅服务实现。

全局限流实践

使用第三方服务Ratelimit,构建镜像,底层依赖的redis,可直接从应用市场安装。

  • ratelimit环境配置

Rate-limit需持久化挂载目录,方便在持久化目录里写规则

进入rate-limit容器里查看配置

开启限流

关键参数:
• OPEN_LIMIT  #开启全局限流功能,全局限流功能依赖于第三⽅的限流服务,⽐如ratelimit, 当前服务需要依赖ratelimit服务,并设置RATE_LIMIT_SERVER_HOST和RATE_LIMIT_SERVER_PORT环境变量
• LIMIT_DOMAIN  #限流链路的domain key,与全局限流服务的配置对应
  • 使用Apache JMeter测试工具向todoshowUI应用发起并发性请求;触发限流,返回429状态码,说明限流生效。

高阶实现

当前架构缺点

配置了服务网络综合治理插件以后,当前服务就不再支持websocket,这也是我们下一步更新的突破点,如果有用户实现了这种优化,欢迎将其分享到应用市场中,供更多的人来使用。