微服务保护是指在微服务架构中为了确保服务的稳定性和安全性而采取的一系列保护措施。这些保护措施包括:
以上措施可以提升微服务架构的可用性、稳定性和安全性,同时也能够减少应用程序出现故障的概率,保障业务的正常运行。
线程隔离和熔断降级是常见的应对高并发和系统异常情况的策略,具体实现方式和目的略有不同。
线程隔离:
线程隔离是将不同的请求或任务分配到不同的线程中执行,以避免线程间的资源争用和影响。例如,在Web应用中,可以通过线程池来管理请求的处理线程,将每个请求放到一个独立的线程中执行,从而避免线程间的干扰和影响。
线程隔离的目的是提高系统的并发性和稳定性,防止线程间的竞争和阻塞,在高并发的情况下,可以更好地利用服务器资源,提高系统的处理能力和响应速度。
熔断降级:
熔断降级是在系统出现异常或过载情况下,通过关闭或降低某些服务或功能,保证系统的可用性和稳定性。例如,在微服务架构中,当服务出现故障或响应时间过长时,可以快速返回错误结果,避免出现更严重的故障或延迟。
熔断降级的目的是在系统异常或过载时,保证系统的可用性和稳定性,避免出现更严重的故障或延迟。通过熔断降级,可以保证部分服务或功能的正常运行,为用户提供有限的服务,避免系统全面崩溃。
可以看到,不管是线程隔离还是熔断降级,都是对客户端(调用方)的保护。需要在调用方 发起远程调用时做线程隔离、或者服务熔断。
而我们的微服务远程调用都是基于Feign来完成的,因此我们需要将Feign与Sentinel整合,在Feign里面实现线程隔离和服务熔断。
SpringCloud中,微服务调用都是通过Feign来实现的,因此做客户端保护必须整合Feign和Sentinel。
修改OrderService的application.yml文件,开启Feign的Sentinel功能:
feign:
sentinel:
enabled: true # 开启feign对sentinel的支持
业务失败后,不能直接报错,而应该返回用户一个友好提示或者默认结果,这个就是失败降级逻辑。
给FeignClient编写失败后的降级逻辑
①方式一:FallbackClass,无法对远程调用的异常做处理
②方式二:FallbackFactory,可以对远程调用的异常做处理,我们选择这种
这里我们演示方式二的失败降级处理。
步骤一:在feign-api项目中定义类,实现FallbackFactory:
代码:
package cn.itcast.feign.clients.fallback;
import cn.itcast.feign.clients.UserClient;
import cn.itcast.feign.pojo.User;
import feign.hystrix.FallbackFactory;
import lombok.extern.slf4j.Slf4j;
@Slf4j
public class UserClientFallbackFactory implements FallbackFactory<UserClient> {
@Override
public UserClient create(Throwable throwable) {
return new UserClient() {
@Override
public User findById(Long id) {
log.error("查询用户异常", throwable);
return new User();
}
};
}
}
步骤二:在-api项目中的DefaultFeignConfiguration类中将UserClientFallbackFactory注册为一个Bean:
@Bean
public UserClientFallbackFactory userClientFallbackFactory(){
return new UserClientFallbackFactory();
}
步骤三:在feign-api项目中的UserClient接口中使用UserClientFallbackFactory:
import cn.itcast.feign.clients.fallback.UserClientFallbackFactory;
import cn.itcast.feign.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
@FeignClient(value = "userservice", fallbackFactory = UserClientFallbackFactory.class)
public interface UserClient {
@GetMapping("/user/{id}")
User findById(@PathVariable("id") Long id);
}
重启后,访问一次订单查询业务,然后查看sentinel控制台,可以看到新的簇点链路:
测试:关闭 userService微服务 之后访问http://localhost:8088/order/101 不再显示报错,而是显示返回数据中的user为null
线程隔离有两种方式实现:
如图:
线程池隔离:给每个服务调用业务分配一个线程池,利用线程池本身实现隔离效果
信号量隔离:不创建线程池,而是计数器模式,记录业务使用的线程数量,达到信号量上限时,禁止新的请求。
两者的优缺点:
用法说明:
在添加限流规则时,可以选择两种阈值类型:
案例需求:给 order-service服务中的UserClient的查询用户接口设置流控规则,线程数不能超过 2。然后利用jmeter测试。
选择feign接口后面的流控按钮:
填写表单:
重启两个微服务;选择《阈值类型-线程数<2》:
一次发生10个请求,有较大概率并发线程数超过2,而超出的请求会走之前定义的失败降级逻辑。
查看运行结果:
发现虽然结果都是通过了,不过部分请求得到的响应是降级返回的null信息。
熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例,如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求;而当服务恢复时,断路器会放行访问该服务的请求。
断路器控制熔断和放行是通过状态机来完成的:
状态机包括三个状态:
断路器熔断策略有三种:慢调用、异常比例、异常数
慢调用:业务的响应时长(RT)大于指定时长的请求认定为慢调用请求。在指定时间内,如果请求数量超过设定的最小数量,慢调用比例大于设定的阈值,则触发熔断。
例如:
解读:RT超过500ms的调用是慢调用,统计最近10000ms内的请求,如果请求量超过10次,并且慢调用比例不低于0.5,则触发熔断,熔断时长为5秒。然后进入half-open状态,放行一次请求做测试。
案例
需求:给 UserClient的查询用户接口设置降级规则,慢调用的RT阈值为50ms,统计时间为1秒,最小请求数量为5,失败阈值比例为0.4,熔断时长为5
修改user-service中的/user/{id}这个接口的业务。通过休眠模拟一个延迟时间:
此时,orderId=101的订单,关联的是id为1的用户,调用时长为60ms:
orderId=102的订单,关联的是id为2的用户,调用时长为非常短;
下面,给feign接口设置降级规则:
规则:
超过50ms的请求都会被认为是慢请求
在浏览器访问:http://localhost:8088/order/101,快速刷新5次,可以发现:
触发了熔断,请求时长缩短至5ms,快速失败了,并且走降级逻辑,返回的null
在浏览器访问:http://localhost:8088/order/102,竟然也被熔断了:
异常比例或异常数:统计指定时间内的调用,如果调用次数超过指定请求数,并且出现异常的比例达到设定的比例阈值(或超过指定异常数),则触发熔断。
例如,一个异常比例设置:
解读:统计最近1000ms内的请求,如果请求量超过10次,并且异常比例不低于0.4,则触发熔断。
一个异常数设置:
解读:统计最近1000ms内的请求,如果请求量超过10次,并且异常比例不低于2次,则触发熔断。
案例
需求:给 UserClient的查询用户接口设置降级规则,统计时间为1秒,最小请求数量为5,失败阈值比例为0.4,熔断时长为5s
首先,修改user-service中的/user/{id}这个接口的业务。手动抛出异常,以触发异常比例的熔断:
也就是说,id 为 2时,就会触发异常
下面,给feign接口设置降级规则:
规则:
在5次请求中,只要异常比例超过0.4,也就是有2次以上的异常,就会触发熔断。
在浏览器快速访问:http://localhost:8088/order/102,快速刷新5次,触发熔断:
此时,我们去访问本来应该正常的103:
亲爱的读者,
我在这篇文章中投入了大量的心血和时间,希望为您提供有价值的内容。这篇文章包含了深入的研究和个人经验,我相信这些信息对您非常有帮助。
如果您觉得这篇文章对您有所帮助,我诚恳地请求您考虑赞赏1元钱的支持。这个金额不会对您的财务状况造成负担,但它会对我继续创作高质量的内容产生积极的影响。
我之所以写这篇文章,是因为我热爱分享有用的知识和见解。您的支持将帮助我继续这个使命,也鼓励我花更多的时间和精力创作更多有价值的内容。