前言

在互联网系统中，每个系统都有服务的上线，所以当流量超过服务极限能力时，系统可能会出现卡死、崩溃的情况，那么就需要各种手段或者策略，来保证系统的稳定性、可用性，系统以牺牲部分请求或延迟处理，来提供有损服务，从而保证系统整体或者核心服务是可用的，本章节讲解关于稳定性设计的一些方案，包括高可用的三大利器，例如限流、降级、熔断，另外讲解关于稳定性的方面架构设计技巧和方法。

“Everything fails, all the time”，无论是在传统软件时代还是在互联网、云时代，系统终究会在某个时间点失败，面向失败的设计理念数十年来并没有多大的变化，不同的是在分布式、云架构的互联网时代，失败将由小概率偶发事件变成常态，同时应对和处理失败的具体实现方式也大相径庭，面向失败设计是在架构设计中很重要的一环，提前思考失败的可能性，并为之做出努力或者预案，从而提升系统的高可用和稳定性，面向失败设计的核心理念在于以一个悲观的心态出发，假设系统地任何组件都有可能在某个时刻都会发生和预计不吻合的情况，为这些不符合预期的情况(failure)做好准备。

通过下面这个案例，让我们了解无所不在的失败场景，2001年9月11日，美国世贸中心双子大厦遭受了谁也无法预料的恐怖打击。灾难发生前，约有350家企业在世贸大厦中工作。事故发生一年后，重返世贸大厦的企业变成了150家，有200家企业由于重要信息系统的破坏，关键数据的丢失而永远的关闭、消失了。其中的一家公司称，自己要恢复到灾难前的状态需要50年的时间。

可用性之容灾

容灾的定义指在相隔较远的两地（同城或异地）建立两套或多套功能相同的IT系统，互相之间可以进行健康状态监视和功能切换，当一处因意外（天灾、人祸）停止工作时，整个应用系统可以切换到另一处，使得该系统功能可以继续正常工作，侧重数据同步和系统持续可用，通俗的将是指当灾难发生时，在保证生产系统的数据尽量少丢失的情况下，保持生存系统的业务不间断地运行，对灾难的容忍能力，容灾的核心思想是基于隔离的冗余。

备份的定义指用户为应用系统产生的重要数据（或者原有的重要数据信息）制作一份或多份拷贝，以增强数据的安全性，侧重数据的备份和保存。

灾备是容灾和备份的简称，不论是自然灾难还是人为灾难，只要有数据传输、存储和交换的地方，就会产生数据失效、丢失、损坏等风险，一旦发生，就会给数据中心带来难以估计的损失；而灾备，就是业务数据安全的重要保障，灾备的目的就是保存系统最核心部分。一个好的灾备方案，就是从失败的基础设施中获取企业最宝贵的数据，然后在新的基础设施上恢复它们。注意，灾备不是为了挽救基础设置，而是为了挽救业务。

灾难恢复（Diaster Recovery）是指当灾难破坏生产中心时在不同地点的数据中心内恢复数据、应用或者业务的能力。

衡量指标

衡量容灾系统的主要指标有RPO（Recovery Point Objective，灾难发生时允许丢失的数据量）、RTO（Recovery Time Objective，系统恢复的时间）、容灾半径（生产系统和容灾系统之间的距离）以及ROI(Return of Investment，容灾系统的投入产出比)。

RPO：业务系统所允许的灾难过程中的最大数据丢失量（以时间来度量），这是一个灾备系统所选用的数据复制技术有密切关系的指标，用以衡量灾备方案的数据冗余备份能力。
RTO：将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态，并将其支持的业务功能从灾难造成的不正常状态恢复到可接收状态所需的时间，其中包括备份数据恢复到可用状态所需时间、应用系统切换时间、以及备用网络切换时间等，该指标用以衡量容灾方案的业务恢复能力。例如，灾难发生后半天内便需要恢复，则RTO值就是十二小时。
容灾半径：生产中心和灾备中心之间的直线距离，用以衡量容灾方案所能防御的灾难影响范围。
ROI：用户投入到容灾系统的资金与从中所获得的收益的比例。

显然，具有零RTO、零RPO和大容灾半径的灾难恢复方案是用户最期望的，但受系统性能要求、适用技术及成本等方面的约束，这种方案实际上是不大可行的。所以，用户在选择容灾方案时应该综合考虑灾难的发生概率、灾难对数据的破坏力、数据所支撑业务的重要性、适用的技术措施及自身所能承受的成本等多种因素，理性地作出选择。

衡量级别

大体上讲，根据冗余对象，容灾可以分为数据级容灾、应用级容灾和业务级容灾。

数据级容灾：数据备份，如建立异地容灾中心做数据远程备份（只备份数据，没有备份系统可切换）。

容灾中心的数据可以是本地生成数据的完全复制（一般在同城实现），也可以比生产数据略微落后，但必定是可用的（一般在异地实现），而差异的数据通常可以通过一些工具（如操作记录、日志等）进行手动补回。基于数据容灾实现业务恢复的速度较慢，通常情况下RTO超过24小时，但是这种级别的容灾系统运行维护成本较低。

数据容灾技术选择度量标准在构建容灾系统时，首先考虑的是结合实际情况选择合理的数据复制技术。在选择合理的数据复制技术时主要考虑以下因素：

灾难承受程度 ：明确计算机系统需要承受的灾难类型，系统故障、通信故障、长时间断电、火灾及地震等各种意外情况所采取的备份、保护方案不尽相同。
业务影响程度 ：必须明确当计算机系统发生意外无法工作时，导致业务停顿所造成的损失程度，也就是定义用户对于计算机系统发生故障的最大容忍时间。这是设计备份方案的重要技术指标。
数据保护程度 ：是否要求数据库恢复所有提交的交易，并且要求实时同步，保证数据的连续性和一致性，这是备份方案复杂程度的重要依据。

应用级容灾

应用级容灾是指在数据容灾的基础上构建一套功能相同的系统，可做系统切换。

容灾中心需要建立起一套和本地生成相当的备份环境，包括主机、网络、应用、IP等资源均有配套，当生产系统发生灾难时，异地系统可以提供完全可用的生产环境。应用级容灾的RTO通常在12个小时以内，技术复杂度较高，运行维护的成本也比较高。

业务级容灾

业务级容灾是指在应用容灾基础上，增加了IT系统以外的容灾。如备用办公地点，系统相关文档等。

业务级容灾是生产中心与容灾中心对业务请求同时进行处理的容灾方式，能够确保业务持续可用。这种方式业务恢复过程自动化程度高，RTO可以做到30分钟以内。但是这种容灾级别的项目实施难度大，需要从应用层对系统进行改造，比较适合流程固定的简单业务系统。这种容灾系统的运行维护成本最高。

评价指标

容灾系统有三个重要的评价指标，分别是灾难检测、容灾切换、数据一致性，下面一起来了解：

灾难检测：具备容灾能力的系统需要能够检测出哪个子系统、组件发生了灾难，以便决策解决方案（灾难恢复）。
容灾切换：系统检测到某个子系统、组件故障后，要具备把流量切换到其他具备相同能力的子系统上去的能力。
数据一致性：同功能的不同子系统（主备）之间的数据要保持一致。灾难恢复后的业务应该不受影响。理论上用户对灾难是无感知的。

解决方案

灾备

这里说的灾备指的是关于数据中心的灾备技术大体上可以分为：冷备、暖备、热备。

冷备：即冷备份，也称离线备份，是指在关闭数据库并且数据库不能更新的状况下进行的数据库完整备份。冷备份只有主数据中心承担业务，备数据中心不会对主数据中心进行实时备份，当主数据中心宕机时，业务也会随之中断，此技术对故障无提前防范和接管能力，恢复耗时较长，已经无法适应数据中心灾备发展的高要求。

暖备：暖备份是介于冷备份和热备份之间的一种方式，它主要通过设置硬盘远程镜像、数据库复制和设置灾难备份中心以实现对整个系统的完全备份。

热备：即双机热备，指的是基于高可用系统中的两台服务器的热备。虽然热备份也只有对主数据中心进行实时备份，当主数据中心故障造成业务不可用时，备数据中心可以自动接管主数据中心业务，并且业务能够在最短时间内恢复。

双活

所谓的双活数据中心，区别于传统的数据中心和灾备中心的两种模式，前者多个或者两个数据中心都处于运行当中，运行相同的应用，具备同样的数据，能够提供跨中心业务负载均衡的运行能力，实现持续的应用可用性和灾难备份能力所以称之为双活；后者是生产数据中心投入运行，灾备数据中心处于不工作状态，只有当灾难发生时，生产数据中心瘫痪，灾备中心才启动。

双活数据中心有下特点：

第一、充分利用资源、避免一个数据中心常年处于闲置状态而造成浪费。通过资源整合，双活数据中心可提供服务的能力时翻倍的。
第二、双活数据中心，如果断了一个数据中心，其业务可以迅速切换到另外一个运行的数据中心，切换过程对用户来说是不可感知的。

两地三中心

同城双中心加异地灾备中心的 “两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。

同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；灾难情况下可在基本不丢失数据的情况下进行灾备应急切换，保持业务连续运行。与异地灾备模式相比较，同城双中心具有投资成本低、建设速度快、运维管理相对简单、可靠性更高等优点。

异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。

小结

总结下两地三中心是同城双中心+异地灾备一种商用容灾备份解决方案；两地是指同城+异地；三中心是指生产中心+同城容灾中心+异地容灾中心。

第九篇：稳定性之面向失败设计【可用性架构设计、可用性容灾】相关推荐

第十一篇：稳定性之面向失败设计【过载保护】
稳定性之面向失败设计[过载保护] 在互联网架构中,高可用架构设计很重要的一个抓手就是过载保护,所谓的过载保护,是指当系统负载超过该系统或服务的承载能力时,系统会自动采取保护措施,确保自身不被压垮,从而 ...
架构篇：什么才是真正的架构设计？
一. 什么是架构和架构本质在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解.此君说的架构和彼君理解的架构未必是一回事.因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这 ...
面向 IoT 物联网的架构设计参考
随着云计算.边缘计算与物联网技术愈发成熟,数据的产生与处理已然来到一个新的时代.数据基础设施正在从云原生(Cloud-Native) 向面向物联网(IoT-Oriented)架构演进.基于此,我们总结 ...
架构师之道：面向组件的Web架构设计
一直以来,不断有工程师询问我有关架构设计上的问题,很希望能听听我的意见.也有工程师原封不动的在自己的项目中引用我的架构设计.最近,部门内的学习小组又在向我约稿:大师,可否分享一些架构设计经验. 说到架 ...
浅谈系统架构设计-从架构设计原理、架构设计原则、架构设计方法展开
我们工作中一直强调要做架构设计.系分,最近前端同学在追求前端质量提升的时候,也在进行架构设计.前端系分的推广,那到底什么是架构设计和系分?该怎么做架构设计和系分?本文尝试对架构设计进行全面的介绍和分享 ...
分层设计与领域设计融合架构设计
目录文章目录目录传统分层架构存在的问题领域驱动设计领域驱动设计思想领域驱动设计面临的问题分层设计与领域设计的融合应用服务层和领域服务层领域划分和微服务化传统分层架构存在的问题传统 ...
架构设计：架构设计要平衡兼顾多方需求
"架构设计要平衡兼顾多方需求" 系统建模定义接口划分功能模块套用模式优化性能系统的安全性易用性(usability) 产品支持发布管理部署方式解决以上问题的技术问 ...
诊断（UDS）协议栈设计-总体架构设计
1 概述车辆总线协议(VBP)组件是指符合ISO14229-1.ISO15765-3.ISO15765-2等一系列汽车标准协议的集合,并支持OSEK NM.AUTOSAR NM等网络管理协议. 诊断 ...
云运维拓扑图_浅谈：智慧交通云平台网络拓扑设计及架构设计
众所周知, 智慧交通云平台网络架构设计支撑平台建设基于以物理分区为基本单元的设计理念,整个云计算中心可分为:核心交换区.管理区.DMZ区.业务应用区以及云存储区. 核心交换区:负责核心网络交换: 管 ...

第九篇：稳定性之面向失败设计【可用性架构设计、可用性容灾】

前言