阿里云php做网站,智能建站公司,柳州seo关键词优化,企业高端网站文章目录 一、引言1. 雪崩问题的产生原因2. 解决雪崩问题的思路 二、微服务保护1. 服务保护方案1.1 请求限流1.2 线程隔离1.3 服务熔断 2. Sentinel2.1 安装2.2 微服务整合2.2.1 请求限流2.2.2 线程隔离①OpenFeign整合Sentinel②配置线程隔离 2.2.3 服务熔断①编写降级逻辑②配… 文章目录 一、引言1. 雪崩问题的产生原因2. 解决雪崩问题的思路 二、微服务保护1. 服务保护方案1.1 请求限流1.2 线程隔离1.3 服务熔断 2. Sentinel2.1 安装2.2 微服务整合2.2.1 请求限流2.2.2 线程隔离①OpenFeign整合Sentinel②配置线程隔离 2.2.3 服务熔断①编写降级逻辑②配置熔断规则 2.2.3 规则持久化①添加依赖②修改 bootstrap.yml 配置文件③在nacos中添加共享配置 3 . 总结 一、引言
微服务架构虽然解决了单体应用的诸多问题但也带来了新的挑战其中之一就是雪崩问题Cascade Failure。当一个或多个服务出现故障会引发连锁反应使得其他依赖这些服务的服务也出现问题从局部故障变为整体故障最后就像生活中的雪崩那样整个系统崩溃。 1. 雪崩问题的产生原因
服务依赖链条过长在微服务架构中服务A可能依赖于服务B而服务B又依赖于服务C当服务C出现问题时整个链条可能都会受到影响。服务过载某个服务的突然高负载或流量激增可能导致下游服务的资源耗尽从而导致更多的服务失败。资源耗尽某个服务由于内存泄漏或其他原因导致资源耗尽如内存、CPU、数据库连接等从而影响整个系统的状态。网络问题网络延迟或断连可能导致服务间通信失败从而引发雪崩效应。Bug引起的失败某个服务中存在未处理的异常在运行时被触发导致服务崩溃依赖该服务的其他服务也因此出现问题。
2. 解决雪崩问题的思路 熔断机制Circuit Breaker 通过监控服务的调用状况当检测到调用失败率过高时自动断开与问题服务的调用连接防止故障扩散。 应用场景服务依赖链条过长、网络问题、Bug引起的失败 限流Rate Limiting 通过限制单个服务的最大请求数来防止因为流量过大而导致的资源耗尽从而保护服务的可用性。 应用场景服务过载 服务降级Fallback 设置备用方案或降级处理在服务不可用时返回预设的降级响应。 应用场景服务依赖链条过长、服务过载 隔离Bulkhead Pattern 通过将服务实例的资源进行隔离防止单个服务实例的故障影响到其他服务实例。 应用场景资源耗尽 健康检查和监控Health Check and Monitoring 实时监控服务的运行状态通过健康检查及时发现和解决潜在问题。 应用场景资源耗尽、网络问题、Bug引起的失败
二、微服务保护
1. 服务保护方案
1.1 请求限流
请求限流是一种常用的保护服务的手段当系统接收到的请求量超过预设的阈值时限流器会拒绝或者延迟一些请求以防止系统过载导致崩溃是一种预防措施。
请求限流往往会有一个限流器数量高低起伏的并发请求曲线经过限流器就变的非常平稳。这就像是水电站的大坝起到蓄水的作用可以通过开关控制水流出的大小让下游水流始终维持在一个平稳的量。 比如我们有一个订单服务恰逢双十一购物节订单服务在促销活动期间会受到大量用户的访问导致系统负载急剧增加甚至出现服务崩溃的情况。
而如果我们使用限流器限制每秒钟最多只能处理1000个请求如果请求量超过这个阈值多余的请求将被拒绝或者延后处理这样我们可以有效防止因短时间内大量请求涌入而导致的系统过载和崩溃。
1.2 线程隔离
线程隔离是一种将不同的任务隔离运行在不同的线程池中的方法防止某一任务的故障蔓延影响其他任务的正常执行是一种补救措施。
当一个业务接口响应时间长而且并发高时就可能耗尽服务器的线程资源导致服务内的其它接口受到影响。所以我们必须把这种影响降低或者缩减影响的范围。线程隔离正是解决这个问题的好办法。
线程隔离的思想来自轮船的舱壁模式 就像一艘轮船被划分为若干个独立的空间分隔开的水密隔舱当船体破损时只会导致损坏的部分隔舱进水而其他隔舱由于隔离并不会进水以确保即使一个隔舱进水其他隔舱不会进水从而防止整艘船的沉没。泰坦尼克号沉没的主要原因之一就是它的舱壁有一个设计上的失败水可以通过舱壁顶部上的甲板注入淹没整个船体。
同样在微服务架构中我们通过隔离不同的服务及其资源防止一个服务出现问题时影响到其他服务。
于此类似为了避免某个接口故障或压力过大导致整个服务不可用我们可以限定每个业务能使用的线程数避免耗尽整个Tomcat的资源因此也叫线程隔离。 如图所示我们给查询购物车业务限定可用线程数量上限为20这样即便查询购物车的请求因为查询商品服务而出现故障也不会导致服务器的线程资源被耗尽不会影响到其它接口。
1.3 服务熔断
服务熔断是一种保护机制当某个服务的故障率超过预设阈值时自动断开对该服务的调用避免故障影响到更多的服务是一种补救措施。
假如一个商品服务故障服务在一段时间内连续超过一定数量的失败请求我们可以触发熔断避免购物车服务服务调用方频繁调用故障的商品服务导致购物车服务也故障。
所以我们要做两件事情
编写服务降级逻辑就是服务调用失败后的处理逻辑根据业务场景可以抛出异常也可以返回友好提示或默认数据。异常统计和熔断统计服务提供方的异常比例当比例过高表明该接口会影响到其它服务应该拒绝调用该接口而是直接走降级逻辑。 2. Sentinel 针对服务过载、线程隔离以及熔断降级我们可以使用 Alibaba Sentinel 来提供全面的解决方案。Sentinel 是 Alibaba 开源的一个流量防卫组件专注于服务端的流量控制、熔断降级以及系统保护 home | Sentinel (sentinelguard.io) Sentinel和Hystrix对比
SentinelHystrix隔离策略信号量隔离线程池隔离/信号量隔离熔断降级策略基于响应时间或失败比率基于失败比率实时指标实现滑动窗口滑动窗口基于 RxJava规则配置支持多种数据源支持多种数据源扩展性多个扩展点插件的形式基于注解的支持支持支持限流基于 QPS支持基于调用关系的限流有限的支持流量整形支持慢启动、匀速器模式不支持系统负载保护支持不支持控制台开箱即用可配置规则、查看秒级监控、机器发现等不完善常见框架的适配Servlet、Spring Cloud、Dubbo、gRPC 等Servlet、Spring Cloud Netflix
Sentinel 的使用可以分为两个部分:
核心库Jar包不依赖任何框架/库能够运行于 Java 8 及以上的版本的运行时环境同时对 Dubbo / Spring Cloud 等框架也有较好的支持。在项目中引入依赖即可实现服务限流、隔离、熔断等功能。控制台Dashboard亦称 Sentinel 服务器。基于 Spring Boot 开发打包后可以直接运行不需要额外的 Tomcat 等应用容器Dashboard 主要负责管理推送规则、监控、管理机器信息等。
为了方便监控微服务我们先把Sentinel的控制台搭建出来。
2.1 安装
下载jar包
下载地址Release v1.8.7 · alibaba/Sentinel (github.com) 如果觉得下载慢可以从镜像下载地址下载https://mirror.ghproxy.com/https://github.com/alibaba/Sentinel/releases/download/1.8.7/sentinel-dashboard-1.8.7.jar 运行 将jar包放在任意非中文、不包含特殊字符的目录下重命名为sentinel-dashboard.jar 然后在命令行运行如下命令(端口如果冲突可以换其他端口)
java -Dserver.port8090 -Dcsp.sentinel.dashboard.serverlocalhost:8090 -Dproject.namesentinel-dashboard -jar sentinel-dashboard.jar其它启动时可配置参数可参考官方文档
启动配置项 · alibaba/Sentinel Wiki (github.com) 访问
访问http://localhost:8090页面就可以看到sentinel的控制台了 输入账号和密码默认都是sentinel
登录后即可看到控制台默认会监控sentinel-dashboard服务本身 控制台页面分析 实时监控 展示当前应用的实时流量情况包括 QPS、线程数等信息。簇点链路 展示服务的调用链路帮助用户快速定位问题。流控规则 用于配置流量控制规则例如限制每秒请求数、并发线程数等。熔断规则 用于配置熔断降级规则当服务出现异常时可以快速熔断避免级联故障。热点规则 用于配置热点参数限流例如限制某个用户每秒的请求数。系统规则 用于配置系统级别的保护规则例如限制 CPU 使用率、Load 等。授权规则 用于配置访问权限控制例如限制某些 IP 访问。集群流控 用于配置集群级别的流量控制。机器列表 展示当前应用接入的所有机器。 2.2 微服务整合 添加Sentinel依赖 !--sentinel--
dependencygroupIdcom.alibaba.cloud/groupId artifactIdspring-cloud-starter-alibaba-sentinel/artifactId
/dependency添加配置文件 spring:cloud: sentinel:transport:dashboard: localhost:8090 # Sentinel控制台地址用于与控制台链接便于控制台推送规则监控和管理应用程序的流量控制和熔断策略。访问添加Sentinel的服务端口之后查看Sentinel控制台
簇点链路 簇点链路就是单机调用链路。是一次请求进入服务后经过的每一个被Sentinel监控的资源链。默认Sentinel会监控SpringMVC的每一个Endpointhttp接口。限流、熔断等都是针对簇点链路中的资源设置的。而资源名默认就是接口的请求路径。 如果你的项目的API接口风格采用的是Restful风格由于请求路径一般都相同这会导致点资源名称重复,因此需要修改配置。 修改配置把请求方式请求路径作为簇点资源名称
spring:cloud:sentinel:transport:dashboard: localhost:8090http-method-specify: true # 开启请求方式前缀再次访问该服务的各个接口之后查看Sentinel控制台 2.2.1 请求限流
在簇点链路后面点击流控按钮即可对其做限流配置 分析 资源名 这是限流规则所作用的具体资源。图中资源名为/carts表示该限流规则是针对/carts这个资源设置的。资源名一般是服务的 URL 地址或业务方法名。 针对来源 表示该限流规则针对的是哪个调用来源。default表示不限具体的调用来源也即对所有调用该资源的请求都适用此规则。 阈值类型 这里可以选择限流的类型通常有 QPS每秒查询次数或并发线程数。默认的是类型是QPS表示采用每秒最大请求数来进行限流控制。 单机阈值 设置每秒最多允许的请求数或并发线程数。如果实际请求数超过该阈值多余的请求将被拒绝或延迟处理。例如填入1000表示每秒最多允许1000次请求。 是否集群 表示是否启用集群流控。如果启用Threshold 将按集群模式进行分布式统计和计算。 高级选项 可以展开设置一些高级参数比如流控模式、冷启动时间等。 而如果想要对接口限流进行测试可以使用jmeter这个软件里面有详细的教程可以只下载文档 链接:https://pan.baidu.com/s/1Y_qxYVVEns6qBsvltyyOXg?pwdtutu 提取码:tutu 或者直接去官方网站下载安装包度盘限的真狠 Apache JMeter - 下载 Apache JMeter — Apache JMeter - Download Apache JMeter 或者去国内镜像下载 apache-jmeter安装包下载_开源镜像站-阿里云 (aliyun.com) 这里我们使用QPS限流策略每秒最多请求数设为6使用jmeter测试后查看控制台 可以看到10个请求其中有4个被拒绝符合我们的QPS限流策略。
2.2.2 线程隔离 限流可以降低服务器压力尽量减少因并发流量引起的服务故障的概率但并不能完全避免服务故障。一旦某个服务出现故障我们必须隔离对这个服务的调用避免发生雪崩。 ①OpenFeign整合Sentinel 由于微服务的各个服务之间经常使用OpenFeign进行请求要FeignClient接口做线程隔离需要将OpenFeign整合Sentinel 修改服务调用方的application.yml文件开启Feign的sentinel功能
feign:sentinel:enabled: true # 开启feign对sentinel的支持重启服务会发现要服务调用方要调用的接口FeignClient自动变成了一个簇点资源 ②配置线程隔离 勾选并发线程数限制也就是说这个接口最多使用5个线程。如果该接口每秒处理2个请求则5个线程的实际QPS在10左右而超出的请求自然会被拒绝。 再次使用jemeter进行测试
很容易就能发现端口的QPS完全不同服务调用方本身的接口的QPS为100而被调用的接口的QPS为10接口每秒处理2个请求则5个线程的实际QPS在10左右。 2.2.3 服务熔断 熔断是解决雪崩问题的重要手段。思路是由断路器统计服务调用的异常比例、慢请求比例如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求而当服务恢复时断路器会放行访问该服务的请求。 在前面我们使用线程隔离对服务调用方进行隔离保护了微服务的其它接口。但由于线程隔离导致被调用服务QPS较低导致接口吞吐能力有限这也导致了下面几个问题
第一超出的QPS上限的请求就只能抛出异常从而导致上游服务中想要请求该接口获取资源的接口请求失败。但从业务角度来说即便上游服务没有请求成功上游服务也应该展示给用户用户体验更好。也就是给请求失败设置一个降级处理逻辑。
第二由于下游接口的延迟较高模拟的500ms从而导致上游服务接口的响应时间也变的很长。这样不仅拖慢了上游服务消耗了上游服务的更多资源而且用户体验也很差。对于下游服务中这种不太健康的接口我们应该直接停止调用直接走降级逻辑避免影响到当前服务。也就是将下游服务的该接口熔断。
①编写降级逻辑
触发限流或熔断后的请求不一定要直接报错也可以返回一些默认数据或者友好提示用户体验会更好。
给FeignClient编写失败后的降级逻辑有两种方式
方式一FallbackClass无法对远程调用的异常做处理方式二FallbackFactory可以对远程调用的异常做处理我们一般选择这种方式。
这里我们演示方式二的失败降级处理。
步骤一 这里默认已经在上游服务配置文件中将OpenFeign整合了Sentinel feign:sentinel:enabled: true # 开启feign对sentinel的支持在相应的FeignClient所在模块定义降级处理类实现FallbackFactory
import feign.hystrix.FallbackFactory;
import org.springframework.stereotype.Component;Component
public class ItemServiceFallbackFactory implements FallbackFactoryItemServiceClient {Overridepublic ItemServiceClient create(Throwable throwable) {return new ItemServiceClient() {Overridepublic Item getItemById(Long id) {// 降级之后返回的默认数据Item defaultItem new Item();defaultItem.setId(id);defaultItem.setName(默认Item);defaultItem.setDescription(由于系统负载这是一个默认的Item描述。);return defaultItem;}};}
}分析
ItemServiceFallbackFactory 实现了 FallbackFactory 接口而FallbackFactory 接口允许我们创建一个 Fallback 实例此实例可以用于处理远程调用失败后的逻辑。create(Throwable throwable) 方法是 FallbackFactory 接口中的唯一方法用于生成一个 ItemServiceClient 的降级处理实现。在调用失败时该方法会接收到一个 Throwable 对象表示调用失败的原因。在 create 方法中返回了一个匿名内部类实现 ItemServiceClient 接口的降级处理逻辑。当 Feign 客户端的远程调用失败时将调用这个降级处理器的方法。这里是 getItemById 方法的降级实现当请求远程 getItemById 方法失败时返回一个默认的 Item 对象。
通过这种方式即使远程服务不可用上游服务仍然可以返回友好的默认数据避免直接暴露问题并提升用户体验。
步骤二
注册配置在 FeignClient 接口中添加注解指明降级处理类
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;FeignClient(name item-service, fallbackFactory ItemServiceFallbackFactory.class)
public interface ItemServiceClient {GetMapping(/items/{id})Item getItemById(PathVariable(id) Long id);
}这样上游服务就不会受到下游服务的影响延迟会变得很低这就是给请求失败设置的降级处理逻辑。
②配置熔断规则 在前面我们知道对于下游服务中这种不太健康的接口我们应该直接停止调用直接走降级逻辑避免影响到当前服务。也就是将下游服务的该接口熔断。当下游服务恢复正常时再允许调用。这其实就是断路器的工作模式。 Sentinel中的断路器不仅可以统计某个接口的慢请求比例还可以统计异常请求比例。当这些比例超出阈值时就会熔断该接口即拦截访问该接口的一切请求降级处理当该接口恢复正常时再放行对于该接口的请求。
断路器的工作状态切换有一个状态机来控制 状态机包括三个状态
closed关闭状态断路器放行所有请求并开始统计异常比例、慢请求比例。超过阈值则切换到open状态open打开状态服务调用被熔断访问被熔断服务的请求会被拒绝快速失败直接走降级逻辑。Open状态持续一段时间后会进入half-open状态half-open半开状态放行一次请求根据执行结果来判断接下来的操作。 请求成功则切换到closed状态请求失败则切换到open状态
接下来配置熔断规则在上游服务下拉栏中选择下游接口进行配置 熔断策略 有三种熔断策略可供选择 慢调用比例根据调用响应时间来触发熔断。异常比例根据调用异常比例来触发熔断。异常数根据调用异常数来触发熔断。 最大 RT 最大 RT 是指响应时间如果请求的响应时间超过这个值即认为是慢调用。例如设为 500 毫秒表示响应时间超过 500 毫秒的请求被视为慢调用。 比例阈值 当慢调用的比例达到这个阈值时触发熔断。取值范围在 [0.0, 1.0] 之间。例如设为 0.5表示慢调用比例达到 50% 时触发熔断。 熔断时长 设置熔断持续的时间即熔断发生后的休眠期在此期间请求将会直接失败。例如设为 5 秒表示一旦触发熔断这个接口将在接下来的 5 秒内直接返回降级处理结果。 最小请求数 表示触发熔断机制的最小请求数量。如果请求数不足这个数量即使比例达到阈值也不会触发熔断。默认设置为 5表示在熔断检测计算的时间窗口内至少必须有 5 个请求才会进行熔断判断。 统计时长 表示进行统计的时间窗口大小以毫秒为单位。默认设置为 1000 毫秒也即 1 秒。这是统计时间窗口的长度熔断策略将在这个时间窗口内计算和统计。
比如
如果配置成下面这样 实际效果
如果该接口在 1 秒内超过 50% 的请求响应时间超过 200 毫秒同时请求数至少有 5 个则触发熔断。此时接口将在接下来的 20 秒内直接返回降级处理结果相当于在这 20 秒内停止向目标接口发送真实请求从而保护下游服务避免进一步的压力。
2.2.3 规则持久化 由于每次重启应用Sentinel 规则将消失在生产环境中我们需要确保 Sentinel 的配置规则在应用重启后仍然有效。为了达成这一目标可以使用 Nacos 来持久化 Sentinel 规则当我们刷新 REST 地址时Sentinel 控制台的流控规则可以从 Nacos 中读取并继续生效。 ①添加依赖
!-- Sentinel 持久化相关 --
dependencygroupIdcom.alibaba.csp/groupIdartifactIdsentinel-datasource-nacos/artifactId
/dependency②修改 bootstrap.yml 配置文件
spring:application:name: cart-serviceprofiles:active: devcloud:nacos:server-addr: 192.168.56.101:8848config:file-extension: yaml # 文件后缀名shared-configs: # 共享配置- dataId: shared-jdbc.yaml # 共享mybatis配置- dataId: shared-log.yaml # 共享日志配置- dataId: shared-swagger.yaml # 共享日志配置# 添加以下内容------------------------------------sentinel:datasource:ds0:nacos:server-addr: 192.168.56.101:8848 # Nacos 服务地址dataId: ${spring.application.name}-degrade-rules.json # 数据 IDgroupId: DEFAULT_GROUP # 分组data-type: json # 数据格式rule-type: degrade # 规则类型这里指定为 degrade表示是熔断降级规则③在nacos中添加共享配置 这里添加的是熔断规则如果采用限流规则可以看这个 [{resource: GET:http://item-service/items,limitApp: default,grade: 1,count: 1,strategy: 0,controlBehavior: 0,clusterMode: false}
]resource: 资源名表示要保护的资源对应代码中配置的资源名例如某个接口的路径。limitApp: 流控针对的调用来源表示只有来自哪些应用的调用才会被限流。 default 表示不区分调用来源所有调用都会被限流。也可以设置为具体的应用名例如 user-service表示只有来自 user-service 应用的调用才会被限流。 grade: 限流级别可选值包括 0线程数限流限制并发线程数。1QPS 限流限制每秒请求数这里使用的就是 QPS 限流。 count: 限流阈值根据grade 的不同含义也不同 当 grade 为 0 时表示最大并发线程数。当 grade 为 1 时表示每秒允许通过的请求数这里设置为 10表示每秒最多允许通过 10 个请求。 strategy: 流控策略可选值包括 0直接拒绝策略超过阈值直接拒绝后续请求。1关联资源限流策略当关联资源的流量达到阈值时对当前资源进行限流。2链路限流策略统计整个调用链路上的流量对超过阈值的请求进行限流。 controlBehavior: 流控效果可选值包括 0快速失败超过阈值直接拒绝后续请求。1Warm Up 预热模式逐渐增加流量避免系统过载。2排队等待模式将超过阈值的请求放入队列中等待直到有资源可用。 clusterMode: 是否开启集群限流模式false 表示不开启true 表示开启。 [{resource: GET:http://item-service/items,count: 0.5,grade: 0,timeWindow: 20,minRequestAmount: 5,statIntervalMs: 10000,slowRatioThreshold: 0.5}
]字段解释
resource 资源名称表示熔断规则应用于的具体资源。 count 触发熔断的阈值数值的含义取决于熔断策略的类型grade。 如果 grade 是 0慢调用比例则 count 表示慢调用占比的阈值即当慢调用比例达到 50% 时触发熔断。如果 grade 是 1异常比例则 count 表示异常请求占比的阈值。如果 grade 是 2异常数count 表示触发熔断的异常请求数阈值。 grade 熔断策略类型 0表示按异常比例触发熔断。1表示按慢调用比例触发熔断。2表示按异常数触发熔断。 timeWindow熔断持续的时间窗口单位为秒。表示当熔断条件满足时该资源将进入熔断状态并在 20 秒内直接拒绝请求或执行降级处理。minRequestAmount触发熔断判定的最小请求数。统计时窗口内请求数量需至少达到该值时才会根据熔断策略进行判定。statIntervalMs统计时间窗口单位为毫秒。slowRatioThreshold慢调用比例触发熔断的阈值这个值跟 count 是同样用途用于定义慢调用比例如果 grade 是 1。一般情况下这个值和 count 值一致。
重新启动服务测试。请求一下相应的接口然后查看Sentinel 控制台发现控制台多出来了一个熔断规则 3 . 总结
通过本篇文章我们简单地了解了如何使用 Alibaba Sentinel 进行微服务保护并且详细讲解了三种主要的服务保护策略——请求限流、线程隔离以及服务熔断。其实Sentinel相关的知识内容还有很多很多太多了所以这里就简单讲解一下提供一些基本的用法希望对大家有所帮助 参考文章
为故障设计微服务架构 - RisingStack Engineering
微服务之微服务保护(Sentinal) - Martin8866 - 博客园 (cnblogs.com)
dashboard | Sentinel (sentinelguard.io)
微服务架构 | 5.2 基于 Sentinel 的服务限流及熔断-阿里云开发者社区 (aliyun.com)
第十章 Sentinel微服务熔断限流 - 掘金 (juejin.cn)
服务保护和分布式事务
