辽阳专业建设网站公司电话互动平台抽手机

当前位置： 首页 > news >正文

辽阳专业建设网站公司电话,互动平台抽手机,网站建设项目售后服务承诺,淮安做微信网站文章目录前言服务容错容错策略附前言 “容错性设计”#xff08;Design for Failure#xff09;是微服务的一个核心原则。 使用微服务架构#xff0c;拆分出的服务越来越多#xff0c;也逐渐导致以下问题#xff1a; 某一个服务的崩溃#xff0c;会导致所有用到这个服务… 文章目录前言服务容错容错策略附前言 “容错性设计”Design for Failure是微服务的一个核心原则。 使用微服务架构拆分出的服务越来越多也逐渐导致以下问题 某一个服务的崩溃会导致所有用到这个服务的其他服务都无法正常工作一个点的错误经过层层传递最终波及到调用链上与此有关的所有服务这便是雪崩效应。如何防止雪崩效应便是微服务架构容错性设计原则的具体实践否则服务化程度越高整个系统反而越不稳定。服务虽然没有崩溃但由于处理能力有限面临超过预期的突发请求时大部分请求直至超时都无法完成处理。这种现象产生的后果跟交通堵塞是类似的如果一开始没有得到及时地治理后面就会需要很长时间才能使全部服务都恢复正常。 以上就是“流量治理”要解决的问题涉及到服务容错、流量控制、服务质量管理等一系列解决方案。 服务容错 构建微服务系统的指导性原则九大原则中多数特征可能会有或多或少的妥协比如分散治理、数据去中心化、轻量级通讯机制、演进式设计但有一些特征是无法做出妥协的就包括容错性设计。 容错性设计不能妥协的原因在于分布式系统的本质是不可靠的一个大的服务集群中程序可能崩溃、节点可能宕机、网络可能中断这些“意外情况”其实全部都在“意料之中”。原本信息系统设计成分布式架构的主要动力之一就是提升系统的可用性最低限度也必须保证将原有系统重构为分布式架构之后可用性不出现倒退才行。 容错策略 容错策略指的是“面对故障我们该做些什么”这里主要介绍7 种常见的容错策略包括故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用和广播调用。 故障转移Failover 高可用的服务集群中多数的服务尤其是那些经常被其他服务依赖的关键路径上的服务都会部署多个副本。这些副本可能部署在不同的节点避免节点宕机、不同的网络交换机避免网络分区甚至是不同的可用区避免整个地区发生灾害或电力、骨干网故障中。 故障转移是指如果调用的服务器出现故障系统不会立即向调用者返回失败结果而是自动切换到其他服务副本尝试其他副本能否返回成功调用的结果从而保证了整体的高可用性。 故障转移的容错策略应该有一定的调用次数限制比如允许最多重试三个服务如果都发生报错那还是会返回调用失败。引入调用次数的限制不仅是因为重试有执行成本更是因为过度的重试反而可能让系统处于更加不利的状况。 快速失败Failfast 一些业务场景是不允许做故障转移的因为故障转移策略能够实施的前提是服务具有幂等性。那对于非幂等的服务重复调用就可能产生脏数据引起的麻烦远大于单纯的某次服务调用失败。这时候就应该把快速失败作为首选的容错策略。当故障发生时尽快让服务报错并抛出异常坚决避免重试由调用者自行处理。 安全失败Failsafe 在一个调用链路中的服务通常也有主路和旁路之分并不见得每个服务都是不可或缺的属于旁路逻辑的一个显著特点是服务失败了也不影响核心业务的正确性。典型的有审计、日志、调试信息等等。 属于旁路逻辑的另一个显著特征是后续处理不会依赖其返回值或者它的返回值是什么都不会影响后续处理的结果。 对这类逻辑一种理想的容错策略是即使旁路逻辑调用失败了也当作正确来返回如果需要返回值的话系统就自动返回一个符合要求的数据类型的对应零值然后自动记录一条服务调用出错的日志备查即可。这种容错策略被称为安全失败。 沉默失败Failsilent 如果大量的请求需要等到超时或者长时间处理后才宣告失败很容易因为某个远程服务的请求堆积而消耗大量的线程、内存、网络等资源进而影响到整个系统的稳定性。 面对这种情况一种合理的失败策略是当请求失败后就默认服务提供者一定时间内无法再对外提供服务不再向它分配请求流量并将错误隔离开来避免对系统其他部分产生影响。这种容错策略就被称为沉默失败。 故障恢复Failback 故障恢复一般不单独存在而是作为其他容错策略的补充措施。故障恢复是指当服务调用出错了以后将该次调用失败的信息存入一个消息队列中然后由系统自动开始异步重试调用。 一方面是尽力促使失败的调用最终能够被正常执行另一方面也可以为服务注册中心和负载均衡器及时提供服务恢复的通知信息。很显然故障恢复也要求服务必须具备幂等性由于它的重试是后台异步进行即使最后调用成功了原来的请求也早已经响应完毕。所以故障恢复策略一般用于对实时性要求不高的主路逻辑也适合处理那些不需要返回值的旁路逻辑。 为了避免在内存中的异步调用任务堆积故障恢复与故障转移一样也应该有最大重试次数的限制。 并行调用Forking 并行调用策略是指一开始就同时向多个服务副本发起调用只要有其中任何一个返回成功那调用便宣告成功。这种策略是在一些关键场景中使用更高的执行成本换取执行时间和成功概率的策略。 广播调用Broadcast 广播调用与并行调用是相对应的都是同时发起多个调用但并行调用是任何一个调用结果返回成功便宣告成功而广播调用则是要求所有的请求全部都成功才算是成功。也就是说对于广播调用来说任何一个服务提供者出现异常都算调用失败。因此广播调用通常被用于实现“刷新分布式缓存”这类的操作。
附 此文章为3月Day01学习笔记内容来源于极客时间《周志明的软件架构课》