网站运营与管理的对策,软件项目管理第二版课后答案,重庆市建设施工安全管理网官网,好用的cms网站文章目录 服务雪崩及其解决方案技术选型: Sentinel or Hystrix 流量治理组件Sentinel**基于SentinelResource注解埋点实现资源保护** Sentinel控制台**限流阈值类型****流控模式****直接****关联** **流控效果**系统规则——系统自适应保护 限流算法**计数器法****滑动时间窗口… 文章目录 服务雪崩及其解决方案技术选型: Sentinel or Hystrix 流量治理组件Sentinel**基于SentinelResource注解埋点实现资源保护** Sentinel控制台**限流阈值类型****流控模式****直接****关联** **流控效果**系统规则——系统自适应保护 限流算法**计数器法****滑动时间窗口算法****漏桶算法****令牌桶算法** 规则持久化拉模式推模式 限流相关术语 服务雪崩及其解决方案
在微服务调用链路中因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程就叫服务雪崩效应。
解决雪崩问题的常见方式有四种
超时机制
设定超时时间请求超过一定时间没有响应就返回错误信息不会无休止地等待。
在不做任何处理的情况下服务提供者不可用会导致消费者请求线程强制等待而造成系统资源耗尽。加入超时机制一旦超时就释放资源。由于释放资源速度较快一定程度上可以抑制资源耗尽的问题。但是这种解决方案只是缓解了雪崩问题并不能解决雪崩问题。
服务限流
限制业务访问的QPS避免服务因为流量的突增而故障。这种是从预防层面来解决雪崩问题。
舱壁隔离(资源隔离)
资源隔离分为进程隔离线程隔离和信号量隔离。隔离机制的本质就是将服务调用的粒度划分的更小以此来减少服务生产崩溃而对服务调用带来的影响避免服务雪崩现象产生。
比如限定每个业务能使用的线程数避免耗尽整个线程池的资源。它是通过划分线程池的线程让每个业务最多使用n个线程进而提高容灾能力。但是这种模式会导致一定的资源浪费比如服务C已经宕机但每次还是会尝试让服务A去向服务C发送请求。
服务熔断降级
这种模式主要是参考电路熔断如果一条线路电压过高保险丝会熔断防止火灾。放到我们的系统中如果某个目标服务调用慢或者有大量超时此时熔断该服务的调用对于后续调用请求不在继续调用目标服务直接返回快速释放资源。如果目标服务情况好转则恢复调用。
当依赖的服务有大量超时时在让新的请求去访问根本没有意义只会无谓的消耗现有资源。比如我们设置了超时时间为3s,如果短时间内有大量请求在3s内都得不到响应就意味着这个服务出现了异常此时就没有必要再让其他的请求去访问这个依赖了这个时候就应该使用断路器避免资源浪费。
有服务熔断必然要有服务降级。
所谓降级就是当某个服务熔断之后服务将不再被调用此时客户端可以自己准备一个本地的fallback回退回调返回一个缺省值。 例如(备用接口/缓存/mock数据) 。这样做虽然服务水平下降但好歹可用比直接挂掉要强当然这也要看适合的业务场景。
技术选型: Sentinel or Hystrix
Hystrix 的关注点在于以 隔离 和 熔断 为主的容错机制超时或被熔断的调用将会快速失败并可以提供 fallback 机制。
而 Sentinel 的侧重点在于 多样化的流量控制 熔断降级 系统负载保护 实时监控和控制台
流量治理组件Sentinel
Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件主要以流量为切入点从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。
资源Resource
资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容例如由应用程序提供的服务或由应用程序调用的其它应用提供的服务甚至可以是一段代码。在接下来的文档中我们都会用资源来描述代码块。
**只要通过 Sentinel API 定义的代码就是资源能够被 Sentinel 保护起来。**大部分情况下可以使用方法签名URL甚至服务名称作为资源名来标示资源。
规则(Rule)
围绕资源的实时状态设定的规则可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。
Sentinel 的使用可以分为两个部分: 核心库Java 客户端不依赖任何框架/库能够运行于 Java 8 及以上的版本的运行时环境同时对 Dubbo / Spring Cloud 等框架也有较好的支持见 主流框架适配 控制台DashboardDashboard 主要负责管理推送规则、监控、管理机器信息等。
基于SentinelResource注解埋点实现资源保护
Sentinel 提供了 SentinelResource 注解用于定义资源并提供了 AspectJ 的扩展用于自动定义资源、处理 BlockException 等。
注意注解方式埋点不支持 private 方法。
SentinelResource 注解包含以下属性
value 资源名称必需项不能为空blockHandler: 定义当资源内部发生了BlockException应该进入的方法捕获的是Sentinel定义的BlockEcxeption异常。如果同时配置了blockHandler和fallback出现BlockException时将进入BlockHandler方法中处理fallback: 定义的是资源内部发生了Throwable应该进入的方法。默认处理所有的异常如果我们不配置blockHandler其抛出BlockEcxeption也将会进入fallback方法中exceptionsToIgnore配置fallback可以忽略的异常
Sentinel控制台
资源名: 接口的API针对来源: 默认是default当多个微服务都调用这个资源时可以配置微服务名来对指定的微服务设置阈值阈值类型: 分为QPS和线程数 假设阈值为10QPS类型: 只得是每秒访问接口的次数10就进行限流线程数: 为接受请求该资源分配的线程数10就进行限流
Sentinel 控制台包含如下功能: 查看机器列表以及健康情况收集 Sentinel 客户端发送的心跳包用于判断机器是否在线。 监控 (单机和集群聚合)通过 Sentinel 客户端暴露的监控 API定期拉取并且聚合应用监控信息最终可以实现秒级的实时监控。 规则管理和推送统一管理推送规则。 鉴权生产环境中鉴权非常重要。这里每个开发者需要根据自己的实际情况进行定制。
用来显示微服务的所监控的API。簇点链路单机调用链路页面实时的去拉取指定客户端资源的运行情况。它一共提供两种展示模式一种用树状结构展示资源的调用链路另外一种则不区分调用链路展示资源的运行情况。
流量控制flow control其原理是监控应用流量的 QPS 或并发线程数等指标当达到指定的阈值时对流量进行控制以避免被瞬时的流量高峰冲垮从而保障应用的高可用性。
同一个资源可以创建多条限流规则。FlowSlot 会对该资源的所有限流规则依次遍历直到有规则触发限流或者所有规则遍历完毕。一条限流规则主要由下面几个因素组成我们可以组合这些元素来实现不同的限流效果。
Field说明默认值resource资源名资源名是限流规则的作用对象count限流阈值grade限流阈值类型QPS 模式1或并发线程数模式0QPS 模式limitApp流控针对的调用来源default代表不区分调用来源strategy调用关系限流策略直接、链路、关联根据资源本身直接controlBehavior流控效果直接拒绝/WarmUp/匀速排队等待不支持按调用关系限流直接拒绝clusterMode是否集群限流否
限流阈值类型
流量控制主要有两种统计类型一种是统计并发线程数另外一种则是统计 QPS。类型由 FlowRule 的 grade 字段来定义。其中0 代表根据并发数量来限流1 代表根据 QPS 来进行流量控制。
QPSQuery Per Second每秒请求数就是说服务器在一秒的时间内处理了多少个请求。
并发线程数
并发线程数控制用于保护业务线程池不被慢调用耗尽。例如当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加对于调用者来说意味着吞吐量下降和更多的线程数占用极端情况下甚至导致线程池耗尽。为应对太多线程占用的情况业内有使用隔离的方案比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢线程池隔离。这种隔离方案虽然隔离性比较好但是代价就是线程数目太多线程上下文切换的 overhead 比较大特别是对低延时的调用有比较大的影响。Sentinel 并发控制不负责创建和管理线程池而是简单统计当前请求上下文的线程数目正在执行的调用数目如果超出阈值新的请求会被立即拒绝效果类似于信号量隔离。并发数控制通常在调用端进行配置。
流控模式
基于调用关系的流量控制。调用关系包括调用方、被调用方一个方法可能会调用其它方法形成一个调用链路的层次关系。
直接
资源调用达到设置的阈值后直接被流控抛出异常
关联
当两个资源之间具有资源争抢或者依赖关系的时候这两个资源便具有了关联。
链路
根据调用链路入口限流。 NodeSelectorSlot 中记录了资源之间的调用链路这些资源通过调用关系相互之间构成一棵调用树。
流控效果
当 QPS 超过某个阈值的时候则采取措施进行流量控制。流量控制的效果包括以下几种快速失败直接拒绝、Warm Up预热、匀速排队排队等待。 快速失败:达到阈值后新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。 warm up:预热模式对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化从一个较小值逐渐增加到最大阈值。 排队等待:让所有的请求按照先后次序排队执行两个请求的间隔不能小于指定时长
热点参数限流会统计传入参数中的热点参数并根据配置的限流阈值与模式对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制仅对包含热点参数的资源调用生效。
系统规则——系统自适应保护
系统保护规则是从应用级别的入口流量进行控制从单台机器的总体 Load、RT、入口 QPS 和线程数四个维度监控应用数据让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
系统保护规则是应用整体维度的而不是资源维度的并且仅对入口流量生效。入口流量指的是进入应用的流量EntryType.IN比如 Web 服务或 Dubbo 服务端接收的请求都属于入口流量。
系统规则阈值类型 Load仅对 Linux/Unix-like 机器生效当系统 load1 超过阈值且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps * minRt 计算得出。设定参考值一般是 CPU cores * 2.5。 CPU usage1.5.0 版本当系统 CPU 使用率超过阈值即触发系统保护取值范围 0.0-1.0。 RT当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护单位是毫秒。 线程数当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。 入口 QPS当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
集群流控中共有两种身份 Token Client集群流控客户端用于向所属 Token Server 通信请求 token。集群限流服务端会返回给客户端结果决定是否限流。 Token Server即集群流控服务端处理来自 Token Client 的请求根据配置的集群规则判断是否应该发放 token是否允许通过。
Sentinel 集群流控支持限流规则和热点规则两种规则并支持两种形式的阈值计算方式 集群总体模式即限制整个集群内的某个资源的总体 qps 不超过此阈值。 单机均摊模式单机均摊模式下配置的阈值等同于单机能够承受的限额token server 会根据连接数来计算总的阈值比如独立模式下有 3 个 client 连接到了 token server然后配的单机均摊阈值为 10则计算出的集群总量就为 30按照计算出的总的阈值来进行限制。这种方式根据当前的连接数实时计算总的阈值对于机器经常进行变更的环境非常适合。
启动方式
Sentinel 集群限流服务端有两种启动方式
独立模式Alone即作为独立的 token server 进程启动独立部署隔离性好但是需要额外的部署操作。独立模式适合作为 Global Rate Limiter 给集群提供流控服务。嵌入模式Embedded即作为内置的 token server 与服务在同一进程中启动。在此模式下集群中各个实例都是对等的token server 和 client 可以随时进行转变因此无需单独部署灵活性比较好。但是隔离性不佳需要限制 token server 的总 QPS防止影响应用本身。嵌入模式适合某个应用集群内部的流控。
云上版本 AHAS Sentinel 提供开箱即用的全自动托管集群流控能力无需手动指定/分配 token server 以及管理连接状态同时支持分钟小时级别流控、大流量低延时场景流控场景同时支持 Istio/Envoy 场景的 Mesh 流控能力。
限流算法
计数器法
计数器法是限流算法里最简单也是最容易实现的一种算法。比如我们规定对于A接口来说我们1分钟的访问次数不能超过100个。那么我们可以这么做在一开始的时候我们可以设置一个计数器counter每当一个请求过来的时候counter就加1如果counter的值大于100并且该请求与第一个 请求的间隔时间还在1分钟之内那么说明请求数过多如果该请求与第一个请求的间隔时间大于1分钟且counter的值还在限流范围内那么就重置 counter。
滑动时间窗口算法
滑动时间窗口又称rolling window。为了解决计数器法统计精度太低的问题引入了滑动窗口算法。
计数器算法其实就是滑动窗口算法。只是它没有对时间窗口做进一步地划分所以只有1格。
由此可见当滑动窗口的格子划分的越多那么滑动窗口的滚动就越平滑限流的统计就会越精确。
漏桶算法
漏桶算法又称leaky bucket。首先我们有一个固定容量的桶有水流进来也有水流出去。对于流进来的水来说我们无法预计一共有多少水会流进来也无法预计水流的速度。但是对于流出去的水来说这个桶可以固定水流出的速率。而且当桶满了之后多余的水将会溢出。
我们将算法中的水换成实际应用中的请求我们可以看到漏桶算法天生就限制了请求的速度。当使用了漏桶算法我们可以保证接口会以一个常速速率来处理请求。所以漏桶算法天生不会出现临界问题。
令牌桶算法
令牌桶算法又称token bucket。首先我们有一个固定容量的桶桶里存放着令牌token。桶一开始是空的token以 一个固定的速率r往桶里填充直到达到桶的容量多余的令牌将会被丢弃。每当一个请求过来时就会尝试从桶里移除一个令牌如果没有令牌的话请求无法通过。
规则持久化
Sentinel规则的推送有下面三种模式:
推送模式说明优点缺点原始模式API 将规则推送至客户端并直接更新到内存中扩展写数据源WritableDataSource简单无任何依赖不保证一致性规则保存在内存中重启即消失。严重不建议用于生产环境Pull 模式扩展写数据源WritableDataSource 客户端主动向某个规则管理中心定期轮询拉取规则这个规则中心可以是 RDBMS、文件 等简单无任何依赖规则持久化不保证一致性实时性不保证拉取过于频繁也可能会有性能问题。Push 模式扩展读数据源ReadableDataSource规则中心统一推送客户端通过注册监听器的方式时刻监听变化比如使用 Nacos、Zookeeper 等配置中心。这种方式有更好的实时性和一致性保证。生产环境下一般采用 push 模式的数据源。规则持久化一致性快速引入第三方依赖
拉模式
pull 模式的数据源如本地文件、RDBMS 等一般是可写入的。使用时需要在客户端注册数据源将对应的读数据源注册至对应的 RuleManager将写数据源注册至 transport 的 WritableDataSourceRegistry 中。
推模式
生产环境下一般更常用的是 push 模式的数据源。对于 push 模式的数据源,如远程配置中心ZooKeeper, Nacos, Apollo等等推送的操作不应由 Sentinel 客户端进行而应该经控制台统一进行管理直接进行推送数据源仅负责获取配置中心推送的配置并更新到本地。因此推送规则正确做法应该是 配置中心控制台/Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel而不是经 Sentinel 数据源推送至配置中心。
限流相关术语
QPS : 每秒查询
QPSQueries Per Sencond意思是“每秒查询率”是一台服务器每秒能够响应的查询次数是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
互联网中作为域名系统服务器的机器的性能经常用QPS来衡量
TPS每秒事务
TPS是TransactionPerSecond的缩写也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时收到服务器响应后结束计时以此来计算使用时间和完成的事务个数。
RT响应时间
响应时间执行一个请求从开始到最后收到响应数据所花费的总体时间即从客户端发起请求到收到服务器响应结果到时间。
响应时间RTResponse-time是一个系统重要的指标之一他的数值大小反应了系统的快慢
并发数
并发数是指系统同时能处理的请求数量这也反应了系统的负载能力
吞吐量
系统的吞吐量承压能力与request对cpu的消耗、外部接口、io等等紧密相连。单个request对cpu消耗越高外部系统接口、io速度越慢系统吞吐能力越低反之越高。
系统吞吐量几个重要参数qps、并发数、响应时间
qps : 每秒request的数量
并发数系统同时处理的request或事务数
响应时间一般取平均响应时间
qps 并发数 / 平均响应时间
并发数 qps * 平均响应时间
在系统访问量激增大量请求涌进来时如果调用的某些第三方接口老是超时或是失败又或者是很慢要想顶过这波高峰我们系统该如何处理常见的处理方式降级、熔断、限流。
降级
降级就是服务降级当我们的服务器压力激增时为了保证核心功能的可用性而选择的降低一些功能的可用性或者直接关闭该功能。这就是典型的丢车保帅了。比如贴吧类型网站当访问量大的时候服务器吃不消了可以选择关闭发帖改密码改头像等等功能保证登陆和浏览的核心功能。
一般而言都会建立一个独立的降级系统可以灵活且批量的配置服务器的降级功能。当然也有用代码自动降级的例如接口超时降级、失败重试多次降级等。
熔断
降级一般而言指的是自身的系统出现了故障而降级。而熔断一般是指依赖的外部接口出现故障的情况断绝和外部接口的关系。
例如ServiceA服务里面依赖serviceB服务这时候serviceB服务出现问题了返回很慢。这中情况可能会拖慢A服务里面所有的功能因此我们这时候就需要熔断即当发现A调用B就返回错误或其他默认值就不去请求B了如果出现问题不熔断那真的是会雪崩。
限流 限流会规定系统可以接受多少请求再有请求过来时就直接拒绝。
