网站后台无法审核,泰州做兼职的网站,企业网站模板源码,旅游分销平台有哪些文章目录 熔断判定服务的健康状态服务恢复正常 降级跨服务降级自身服务提供有损服务具体案例分析 熔断
微服务架构中#xff0c;如果需要保障可用性#xff0c;其中一个方式就是 熔断。熔断在微服务架构里面是指 当微服务本身出现问题的时候#xff0c;它会拒绝新的请求如果需要保障可用性其中一个方式就是 熔断。熔断在微服务架构里面是指 当微服务本身出现问题的时候它会拒绝新的请求直到微服务恢复。通过熔断机制可以给服务端恢复的时间比如 CPU 使用率已经超出负载了此时服务端触发了熔断那么新来的请求就会被拒绝因此服务端的 CPU 使用率就会在一段时间内降到100%以内。
判定服务的健康状态
判断微服务是否出现了问题需要根据自己的业务来选择一些指标来代表这个服务器的健康程度一般可以使用 响应时间、错误率。不管选择什么指标都要考虑两个因素 一是阈值如何选择二是超过阈值之后要不要持续一段时间才触发熔断。 假设 把响应时间作为指标如果业务对响应时间的要求是在 1s 以内那么你的阈值就可以设定在 1s或者稍高一点留点容错的余地也可以原则上阈值应该明显超过正常响应时间。比如经过一段时间的观测之后发现这个服务的 99 线是 1s那么你可以考虑将熔断阈值设定为 1.2s。 如果响应时间一旦超过了阈值也不能立刻就熔断而是 要求响应时间超过一段时间之后才触发熔断。这主要是出于两个考虑一个是响应时间可能是偶发性地突然增长另外一个则是防止抖动。这个“一段时间”很大程度上就依赖个人经验了如果时间过短可能会频繁触发熔断然后又恢复再熔断再恢复…… 反过来如果时间过长就可能会导致需要触发熔断的时候却迟迟没有触发。你可以根据经验来设定一个值比如说三十秒或者一分钟。 总结为了保障微服务的可用性在核心服务里面可以接入熔断针对不同的服务可以设计不同的微服务熔断策略。比如最简单的熔断策略就是根据响应时间来判定当响应时间超过阈值一段时间之后就会触发熔断一般会根据业务情况来选择这个阈值如果产品方要求响应时间是1s那么可以把阈值设定在1.2s。如果响应时间超过1.2s并且持续三十秒就会触发熔断。在触发熔断的情况下新请求会被拒绝而已有的请求还是会被继续处理直到服务恢复正常。 还可以根据缓存策略设计熔断方案比如某一个接口得并发很高对缓存的依赖度非常严重所以当检测到缓存不可用的时候比如说 Redis 崩溃了那么就会触发熔断因为此时如果不熔断的话高并发的请求会因为 Redis 崩溃而全部落到 MySQL 上导致压垮 MySQL。 在触发熔断之后可以额外开启一个线程例如 Goroutine持续不断地 ping Redis的服务是否正常如果 Redis 恢复了那么就退出熔断状态新来的请求就不会被拒绝了。 这种方案类似于处理缓存雪崩的问题参考《缓存雪崩、缓存击穿、穿透穿透具体指哪些问题》 服务恢复正常
如果我们判断一个服务响应时间过长进入了熔断状态那么一段时间比如十分钟过后已接收的请求已经被处理完了也就是服务已经恢复正常了那么就需要退出熔断状态继续接收新请求。因此在触发熔断之后就要考虑检测服务是否已经恢复正常。
如果本身熔断是高并发引起的那么在一分钟后并发依旧很高这时候你一旦直接恢复正常然后高并发的流量打过来服务是不是又会触发熔断 这就会出现上面说的“抖动”的情况。
所谓 抖动就是服务频繁地在正常-熔断两个状态之间切换。引起抖动的原因是多样的比如说前面提到的一旦超过阈值就进入熔断状态再比如“一分钟后就认为服务已经恢复正常继续处理新请求”就容易引发抖动问题。
要解决这个抖动问题就需要在恢复之后控制住流量。比如说按照 10%、20%、30%……逐步递增而不是立刻恢复 100% 的流量需要负载均衡来配合。在这种逐步放开流量的措施下依旧有请求因为熔断不会被处理那么有没有更好的处理方式
其实可以让客户端来控制这个流量。就是当服务端触发熔断之后客户端就直接不再请求这个节点了而是换一个节点。等到恢复了之后客户端再逐步对这个节点放开流量。整体思路是利用负载均衡来控制流量如果一个服务端节点触发了熔断那么客户端在做负载均衡的时候就可以将这个节点挪出可用列表后续请求会发给别的节点。在经过一段时间之后客户端可以尝试发请求给该节点。如果该节点正确处理了那客户端就可以加大流量否则客户端就要再一次等待一段时间。
综合运用负载均衡和熔断的方案重点在于客户端控制流量并根据服务端节点的状况来操作可用节点列表。参考《微服务的注册发现和微服务架构下的负载均衡》
万一所有可用节点都触发熔断了应该怎么办 如果因为某些原因数据库出问题导致某个服务所有的节点都触发了熔断那么客户端就完全没有可用节点了。针对这个问题熔断解决不了负载均衡也解决不了只能通过监控告警之后人手工介入处理了。 整体流程 服务端在触发熔断的时候会返回一个代表熔断的错误。客户端在收到这个错误之后就会把这个服务端节点暂时挪出可用节点列表。后续所有的新请求都不会再打到这个触发了熔断的服务端节点上了。客户端在等待一段时间后逐步放开流量如果服务端正常处理了新来的请求那么客户端就加大流量。如果服务端再次返回了熔断响应那么客户端就会再一次将这个节点挪出可用列表。如此循环直到服务端完全恢复正常客户端也正常发送请求到该服务端节点。 降级
降级就是在服务资源不够用的时候停用一部分边缘业务这部分被停用的边缘业务可以被理解为“全部熔断了”。
比如在双十一之类的大促高峰电商平台可能会关闭一些服务比如退款服务用来保证订单业务尽可能不受影响当然营销策略部分不在我们的讨论范围这就是降级的典型应用不过它是一种手动的跨服务降级。这种降级的好处有两方面一方面是腾出了服务器资源可以给订单服务或者支付服务另外一方面是减少了对公共组件的压力比如说减少了对数据库的写入压力。
关于服务降级主要关心的也是两个方面其一、如何判定一个服务要不要降级如何判定服务健康其二、降级之后怎么恢复也是要考虑抖动的问题。熔断是彻底不提供服务而降级则是尽量提供不分服务。
所以在一些场景下既可以用熔断也可以用降级。比如说在响应时间超过阈值之后可以考虑选择熔断完全不提供服务也可以考虑降级提供一部分服务。 原则上来说是应该优先考虑使用降级的然而有些服务是无法降级的尤其是写服务。例如 你从前端接收数据然后写到数据库这种场景是无法降级的。另外如果你希望系统负载尽快降低那么熔断要优于降级。 如何降级基本上可以分成两大类跨服务降级 和 本服务提供有损服务。
跨服务降级
当服务资源不够的时候可以暂停某些服务将腾出来的资源给其他更加重要、更加核心的服务使用。上面提到的大促期间暂停退款服务就是跨服务降级的例子。这种策略的要点是必须要确定一个服务比另外一个服务更有业务价值或者更加重要。
跨服务降级的措施常见的做法有三个
整个服务停掉例如前面提到的停掉退款服务。停掉服务的部分节点例如十个节点停掉其中五个节点这五个节点被挪作他用。停止访问某些资源。例如日志中心压力很大的时候发信号给某些不重要的服务让它们停止上传日志只在本地保存日志。
跨服务降级可以在大部分合并部署的服务里面使用一般的原则就是 B、C端合并部署降级 B 端付费服务和非付费服务降级非付费服务。当然也可以根据自己的业务价值将这些部署在同一个节点上的服务分成三六九等。而后在触发降级的时候从不重要的服务开始降级将资源调配给重要服务。
自身服务提供有损服务
例如各大 App 的首页都会有降级的策略。在没有触发降级的时候App 首页是针对你个人用户画像的个性化推荐。而在触发了降级之后则可能是使用榜单数据或者使用一个运营提前配置好的静态页面。这种策略的要点是你得知道你的服务调用者能够接受什么程度的有损。 针对服务本身的一些常见的降级思路
返回默认值这算是最简单的一种状况。禁用可观测性组件正常来说在业务里面都充斥了各种各样的埋点。这些埋点本身其实是会带来消耗的所以在性能达到瓶颈的时候就可以考虑停用或者降低采样率。同步转异步即正常情况下服务收到请求之后会立刻处理。但是在降级的情况下服务在收到请求之后只会返回一个代表“已接收”的响应。后续服务会异步地开启线程来处理或者依赖于定时任务来处理。简化流程如果你处理一个请求需要很多步骤后续如果有一些步骤不关键的话可以考虑不执行或者异步执行。例如在内容生产平台一般新内容要被推送到推荐系统里面。那么在降级的情况下你可以不推而后可以考虑异步推送过去也可以考虑等系统恢复之后再推送过去。 需要注意的是在任何的故障处理里面都要考虑恢复策略会不会引起抖动问题。 也可以考虑使用降级来保护 缓存-数据库 结构一般来说基本上都是先从缓存里面读数据如果缓存里面没有数据就从数据库中读取。那么在触发降级的情况下可以考虑只从缓存里面读取如果缓存里面没有数据那么就直接返回而不会再去数据库里读取。 这样可以保证在缓存里面有数据的那部分请求可以得到正常处理也就是提供了有损服务。如果完全不考虑从数据库里取数据那么你的性能瓶颈就完全取决于缓存那么服务能够撑住的 QPS 会非常高。但是如果缓存不命中的时候要去数据库取数据那么服务的性能会衰退得非常快即极少数缓存未命中的请求会占据大部分的系统资源。
具体案例分析
如果你的某个服务是同时提供了读服务和写服务并且读服务明显比写服务更加重要那么这时候你就可以考虑降级写服务。
假如说现在有一个针对商家的服务比如 某团外卖商家调用这些 API 来录入一些数据比如他们门店的基本信息上传一些门店图片等。同时还有一个针对 C 端普通用户的服务这个服务就是把商家录入的数据展示在商家门店的首页上。所以你可以看到在这个场景下 读服务 QPS 更高也更加重要。那么如果这两个服务是一起部署的在需要降级的时候就可以考虑将针对商家的写服务停掉将资源都腾出来给针对 C 端用户的读服务。从资源占用的角度分析虽然整体来说写服务 QPS 占比很低但是对于数据库来说一次写请求对性能的压力要远比一次读请求大。所以暂停了写服务之后数据库的负载能够减轻不少。
具体解决方案1 读写服务中 降级写服务接入一个跨服务的降级策略当发现读服务的响应时间超过了阈值的时候或者响应时间开始显著上升的时候就将针对 B 端商家用户的服务临时停掉腾出来的资源都给 C 端用户使用。对于 B 端用户来说他们这个阶段是没有办法修改已经录入的数据的但是这并不是一个特别大的问题。当 C 端接口的响应时间恢复正常之后会自动恢复 B 端商家接口商家又可以修改或者录入数据了。 在内容生产平台作者生产内容C 端用户查看生产的内容。那么在资源不足的情况下可以考虑停掉内容生产端的服务只保留 C 端用户查看内容的功能。如果你的用户分成普通用户和 VIP 用户那么你也可以考虑停掉给普通用户的服务。甚至如果一个服务既提供给普通用户也提供给 VIP 用户你可以考虑将普通用户请求拒绝掉只服务 VIP 用户。毕竟VIP用户花钱了 判断一个服务的业务价值最简单的方法就是判定什么业务带来了多少价值又或者根据公司的主要营收来源确定服务的业务价值越是能赚钱的就越重要。 具体解决方案2快慢路径中 降级慢路径在查询商品数据中先查询缓存如果缓存有数据那么就直接返回。如果缓存没有那么就需要去数据库查询。如果此时系统的并发非常高那么就采取降级策略将请求标记为降级请求。降级请求只会查询缓存而不会查询数据库。如果缓存没有那就直接返回错误。这样能够有效防止因为少部分请求缓存未命中而占据大量系统资源导致系统吞吐量下降和响应时间显著升高。 这种思路其实可以在很多微服务里面应用。如果一个服务可以分成快路径和慢路径两种逻辑那么在降级之前就可以先走快路径再走慢路径。而触发了降级之后就只允许走快路径。上面例子中从缓存里加载数据就是快路径从数据库里面加载数据就是慢路径。 慢路径还可以是发起服务调用或者复杂计算。比如说一个服务快路径是直接查询缓存而慢路径可能是发起很多微服务调用拿到所有响应之后一起计算算出来一个结果并缓存起来。那么在降级的时候可以有效提高吞吐量。不过这种吞吐量是有损的毕竟部分请求如果没有在缓存中找到数据那么就会直接返回失败响应。
