云架构的思考4--云上灾备

本文主要是介绍云架构的思考4--云上灾备，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前几章讲了云上架构、开发等事项，其实灾备也算是架构中的一步，但是这里特意拎出来讲主要有2个原因，其一是因为灾备相对独立且复杂，而且并非所有的业务需求都需要有灾备；其二是在云上的灾备是云的吸引力之一，因为以前做一个灾备，特别是异地灾备的数据中心有多困难多费钱就不说了，现在云似乎可以让灾备随时触手可及。那么本章就来讲一下云上灾备的内容。

1 关键指标

灾备说到底就是在系统发生灾难性打击的时候，是否存在备用解决方案，简单来说就是还具备高可用吗？那么要实现高可用就必须冗余，因此灾备说到底就是对你系统的冗余（无论哪种方式）。那么不同业务、不同系统、不同层次、不同要求对灾备的需求都不一样，实现不一样的灾备其人力物力也不一样。这里有2个指标必须知道：
RPO：简单来说就是能恢复数据到哪个时间点（一般决定于数据备份频率）
RTO：需要从故障发生后，多久时间恢复服务可用（一般决定于高可用或冷热备）
这2个指标的高低决定你会采用哪种方式的灾备，也取决于灾备的成本，RPO和RTO越低，成本越高，灾备方案也复杂。

2 灾备方案

不同的灾备方案有不同的效果，同时具备优缺点，这里以表格方式列举不同灾备方式：

\	备份	冷备	温备	热备
方案描述	将应用和数据以备份（snapshot）方式备份到灾备区，且数据备份延迟可能达1天	将应用和数据部署在灾备区，但是不启动的冷备，且数据可以准实时备份	整体系统以最小资源运行在灾备区，当出现灾难时，自动切换和扩展资源。	整体系统在灾备区重新运行一套一模一样的系统，当出现灾难时，自动切换。
RPO/RTO	RPO：可能会是1天到1周时间；RTO：相对比较长，可能几个小时；	RPO：相对于“备份”有更低的RPO，可能几分钟到几小时；RTO：相对于“备份”有更短的RTO，可能几分钟到十几分钟；	RPO：比较低的RPO，可能几分钟；RTO：比较低的RTO，可能几分钟；	RPO：非常低的RPO，可能几秒钟；RTO：非常低的RTO，可能几秒钟；
优点	成本低；实现简单	成本较低；恢复较快	恢复快；	几乎等同于高可用；
缺点	RPO和RTO高；	RPO和RTO一般；	成本较高；	成本高；实现复杂；

可以看出灾备的要求和成本正比，且成本可能会指数增长。因此在考虑自己的系统灾备问题时，更需要多方面考虑，往往的情况是采用混合方式，也就是核心主要系统采用热备，其它非核心系统按照其重要程度逐步降低要求。另外除了灾备方案之外，灾备区的选择也是一种需要考量的参数，下一节中云上灾备常见模式就能看到不同灾备区对应的灾备方案也会有所不同，当然成本也会有所不同。

3 云上灾备常见模式

讲完了指标和灾备方案，那么在云上有哪些常见的云上灾备模式

3.1 “地域”模式

所谓的地域模式就是利用云的多地域优势进行灾备。在公有云上有2个概念需要知道，一个是“区域”即表示一个区域（可以是广州、上海等），一般一个云厂商有很多个区域，这些区域并没有内网专线联通。另外一个是“可用区”即表示在一个区域（比如上海、广州等）建造了多个数据中心，每个数据中心相聚十几到几十公里，每个中心使用高速带宽连接一起，这样每个数据中心就称为“可用区”。简单来说一个云厂商有多个区域，每个区域有一个到多个可用区。我们在做灾备时，就可以利用不同云厂商、区域、可用区的解决方案来实现不同程度的灾备。

可用区灾备：我们知道虽然我们部署了一个集群，但是很可能这个集群都是在一个可用区（也就是一个数据中心），但这个可用区网络出现问题或者出现破坏性行为时，可能导致整个系统不可用。而利用云的多可用区特点做灾备，可以提高我们的高可用。由于一个区域内的可用区都是由内网联通的，所以很多云产品（负载均衡、自动伸缩等）都是提供多可用区的模式，因此采用可用区灾备是一种成本比较低且方便的操作。但是毕竟多可用区都是属于一个区域，有可能出现整个区域不可用的情况，这时候就需要跨区域灾备。
跨区域灾备：前面简述了区域指的是云厂商在一个区域部署的多个数据中心，但是一个区域出现自然灾害导致整片区域不可用的情况还是会存在，因此为了我们应用高可用性，我们还需要做到跨区域灾备。跨区域灾备就不想可用区灾备那么简单，因为区域之间的网络是没有专门高速通道联通，意味着你需要比较大的成本且需要牺牲一些内容。一般采用DNS做一个域名转发，使用就近原则将请求分配到距离用户最近的区域，但是无状态的应用可以多个区域部署，前端搭载负载均衡，在通过DNS转发到负载均衡上面。而数据层面就很难做到多区域强一致性，这部分在“数据”模式中详细讨论。这里我们知道可以通过多区域灾备模式提升我们应用的高可用性。
混合云灾备：我们知道除了公有云，还存在私有云、专有云甚至本地数据中心，利用混合云模式，将数据和应用在公有云和其它云模式下相互灾备也是一种场景的模式，特别是利用公有云来作备份，利用公有云来分担流量，这些都是一些灾备折中方案，既可以节省一定成本，也能利用到公有云的特性。
多个云供应商灾备：云供应商虽然提供很高的SLA保障，但是云供应商出现问题的事件却一直没有听过。如果云供应商出现问题，作为用户你只能干等着他们修复问题，却无法做其它事情，因此现在很多企业采用的是多个云供应商部署方式，一方面是解决被单个供应商绑定的困扰，另一方面就是灾备。

3.2 “应用”模式

部署的应用有哪些模式做容灾。

快照：通过对云主机的快照备份，然后定时将备份传送到灾备区进行备份，必要时可以使用快照迅速恢复云主机
镜像：对于无状态的应用，我们可3.以提前制作镜像，这样我们就能快速部署新的应用同时也能提高部署效率，通过镜像我们可以在灾备区迅速搭建新的应用
云灾备工具：不同云厂商对于虚拟机、云主机都提供一个便利的灾备工具，通过灾备工具可以迅速恢复或者重新搭建新的应用。

3.3 “数据”模式

在所有的灾备中，数据的灾备是最复杂的，因为数据一般要求很高的强一致性，而灾备的原理就是冗余，如果既要冗余又要强一致性，那么可能会导致性能下降。CAP原理就是需要做出一些选择。下面说一下云上不同存储的一些灾备模式

云盘（块存储）灾备：在数据存储中，我们可能会采用云盘（如果理解不了就直接理解主机挂载的硬盘）。这类存储就是很主机挂上关系的，因此在灾备的时候，你不止需要考虑其备份的速度，还需要考虑恢复的的挂载机制。因此这类存储的灾备一般采用云厂商提供的一些备份方案，将其准实时地自动地备份到灾备区，同时也能够迅速在灾备区挂载到新的云主机中。
对象存储灾备：对象存储一般指云产品上面如S3、OSS等产品，存储静态文件的数据存储。这些存储一般都是成熟的云产品，我们采用的方式可以是使用跨区域复制+版本机制来达到灾备效果。
关系型数据库：关系型数据库是比较常见的应用数据库，这里分两部分，一个部分是自建的关系型数据库，这部分不在讨论访问。另一部分是云关系型数据库。一般的云关系型数据库都是由云厂商提供的，都会提供高可用的版本，也就是可以是主从模式、双主模式、集群模式等，但是一般都是在一个区域内保证多个可用区部署，如果涉及到跨区域，一般还是采用都是备份或者日志同步（DTS工具）方式，在灾备区备份一份数据（无论是冷备还是热备，取决于你对RTO的要求）。

4 总结

之所以灾备单独拿出来讲是因为灾备比较重要，更是因为灾备在云上做起来会容易的多并且不需要付出太大的代价就能可以对你多种方案的试验。但我们知道灾备更多的是要应付出现极端情况下的系统不可用，也知道RPO和RTO越低，对于灾备的成本也就越高。我们通过对云部署模式、应用、数据等几个方面详细讲了云上灾备模式，希望对你在云架构设计上有所帮助。