系统容错和容灾简要说明

先介绍几个概念，同步一下认知：
容灾：是指系统冗余部署，当一处由于意外停止工作，整个系统应用还可以正常工作。
容错：是指在运行中出现错误（如上下游故障或概率性失败）仍可正常提供服务。
可用性：描述的是系统可提供服务的时间长短。用公式来说就是A=MTBF/(MTBF+MTTR)，即正常工作时间/(正常工作时间+故障时间)。
可靠性：描述的是系统指定时间单位内无故障的次数。比如：一年365天，以天为单位来衡量。有天发生了故障，哪怕只有1秒，这天算不可靠。其他没有故障的是可靠的。
稳定性：这个业界没有明确的定义，我的理解是：在受到各种干扰时仍然能够提供符合预期的服务的能力。
从要求的严格程度上：可用性<可靠性<稳定性。
可用性和可靠性更侧重于容灾，而对稳定性同时包含容灾和容错

容错和容灾
一、容灾
增加冗余性，通过在相隔较远的异地，建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处系统因意外（如火灾、地震等）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作。

容灾可分为三个层次：

1.数据容灾： 就是数据远程的备份，灾难发生时，只保证数据不丢失，但是业务会中断，慢慢恢复、重建。
2.应用容灾： 在数据备份或同步的基础上，还要建立一套相同的应用系统，除了涉及数据，还要涉及到主机、网络、存储、OS、软件等等。灾难发生时，业务能快速回复甚至不中断
3.业务容灾： 不仅包含了IT应用系统，还要包括办公场地、电话通讯、后勤保障等等，跟业务相关的一切都要考虑。

二、容错
容错（fault tolerance）指的是， 发生故障时，系统还能继续运行。

例如： 飞机有四个引擎，如果一个引擎坏了，剩下三个引擎，还能继续飞，这就是"容错"。同样的，汽车的一个轮子扎破了，剩下三个轮子，也还是勉强能行驶。

容错的目的是，发生故障时，系统的运行水平可能有所下降，但是依然可用，不会完全失败。

雪崩效应
微服务架构的应用系统通常包含多个服务层。微服务之间通过网络进行通信，从而支撑起整个应用系统，因此，微服务之间难免存在依赖关系。我们知道， 任何微服务并非100%可用，网络往往也很脆弱，因此难免有些请求会失败。

我们常把“基础服务故障”导致“级联故障”的现象称为雪崩效应。雪崩效应描述的是提供者不可用导致消费者不可用，并将不可用逐渐放大的过程。

例如： 服务D是一个辅助类型服务，整个业务不依赖于D服务，某天D服务突然响应时间变长，导致了核心服务C响应时间变长，其上请求越积越多，C服务也出现了响应变慢的情况，由于A，B强依赖于服务C，故而一个无关紧要的服务却影响了整个系统的可用。因此，当D不可用引起C不用，并将不可用像滚雪球一样放大到A和B时，雪崩效应就形成了。

雪崩是系统中的蝴蝶效应导致其发生的原因多种多样，有不合理的容量设计，或者是高并发下某一个方法响应变慢，亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头的发生，但是雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估，做好熔断，隔离，限流。

三、容错隔离的方法有哪些
我们再来看看常见的「容错隔离」方法有哪些：

超时： 这也是简单的容错方式。就是指在服务之间调用时，设置一个 主动超时时间，超过了这个时间阈值后，如果“被依赖的服务”还没有返回数据的话，“调用者”就主动放弃，防止因“被依赖的服务”的故障所影响。
限流： 顾名思义，就是限制最大流量。系统能提供的最大并发有限，同时来的请求又太多，服务不过来啊，就只好排队限流了，就跟去景点排队买票、去商场吃饭排队等号的道理一样一样儿的。
降级： 这个与限流类似，一样是流量太多，系统服务不过来。这个时候可以可将不是那么重要的功能模块进行降级处理，停止服务，这样可以释放出更多的资源供给核心功能的去用。同时还可以对用户分层处理，优先处理重要用户的请求，比如VIP收费用户等。
延迟处理： 这个方式是指设置一个流量缓冲池，所有的请求先进入这个缓冲池等待处理，真正的服务处理方按顺序从这个缓冲池中取出请求依次处理，这种方式可以减轻后端服务的压力，但是对用户来说体验上有延迟。
熔断： 可以理解成就像电闸的保险丝一样，当流量过大或者错误率过大的时候，保险丝就熔断了，链路就断开了，不提供服务了。当流量恢复正常，或者后端服务稳定了，保险丝会自动街上（熔断闭合），服务又可以正常提供了。这是一种很好的保护后端微服务的一种方式。
熔断技术中有个很重要的概念就是：断路器，说到熔断器，java技术栈的同学第一时间会想到Hystrix。熔断器有三种状态：

Closed（闭合状态，也就是正常状态）
Open（开启状态，也就是当后端服务出故障后链路断开，不提供服务的状态）
Half-Open(半闭合状态，就是允许一小部分流量进行尝试，尝试后发现服务正常就转为Closed状态，服务依旧不正常就转为Open状态)。

五、微服务架构中可用性风险有哪些？
我们先来看一下微服务架构中，常见的可用性风险到底有哪些吧，知道了有哪些风险我们才知道该如何去规避、去隔离风险。

我们可以从项目部署规模的角度去分析风险：

单机可用性风险： 这个很好理解，就是微服务部署所在的某一台机器出现了故障，造成的可用性风险。这种风险发生率很高，因为单机器在运维中本身就容易发生各种故障，例如 硬盘坏了、机器电源故障等等，这些都是时有发生的事情。不过虽然这种风险发生率高，但危害有限，因为我们大多数服务并不只部署在一台机器上，可能多台都有，因此只需要做好监控，发现故障之后，及时的将这台故障机器从服务集群中剔除即可，等修复了再重新上线到集群里。

单机房可用性风险： 这种风险的概率比单机器的要低很多，但是也不是完全不可能发生，在实际情况中，还是有一定概率的。比如最为常见的就是通往机房的光纤被挖断了，前段时间支付宝所在机房不是就发生过光纤被挖么。咱们全国大小城市都在疯狂的进行基建，修桥修路修房子，GDP就这么搞起来了，地下的光纤挖断几根不是再正常不过的事情了么，哈哈。如果我们的服务全部都部署在单个机房，而机房又出故障了，那就没辙了。好在，现在大多数中大型项目都会采用多机房部署的方案，比如同城双活、异地多活等。一旦某个机房出现了故障不可用了，咱们立即采用切换路由的方式，把这个机房的流量切到其它机房里。

跨机房集群可用性风险： 既然都跨机房集群了，可用性理论上应该没啥问题啊。但要知道这是在物理层面没有问题了，如果咱们的代码有坑，或者因为特殊原因用户流量激增，导致我们的服务扛不住了，那在跨机房集群的情况下一样会不可用。但如果我们提前做好了「容错隔离」的一些方案，比如 限流、熔断 等等，用上这些方法还是可以保证一部分服务或者一部分用户的访问是正常

原文链接：https://blog.csdn.net/u010979642/article/details/106948757