公有云上应该怎么做容灾？

做个简单总结就是，要想起到容灾效果，优先做到同城双活，再考虑异地双活或多活。从这个铺垫往下，谈谈如果我们上了云，高可用和容灾策略应该怎么选择。

我从几个方面来讲：

第一，先理解几个公有云的通用概念。

为了便于理解，我尽量说的通俗点，大家别跟我抠字眼，如果要找准确定义，大家可以 Google，也可以去看几大公有云实际的布局，比看我讲的更清楚。

我们知道的公有云一些专用名词，如 Region-地域和 AZ-可用区，通用的 IDC-机房园区，其中 Region 和 AZ 理解起来，本质上都是逻辑概念，并不像机房一样更多的是物理概念。

简单理解，先说 Region，公有云可能会有北京的 Region、上海的 Region、杭州的 Region 等等。

对于 AZ 可用区，是包含在 Region 内的，比如公有云上海 Region，可能会有多个 AZ，而单个 AZ 可能会有一个或多个 IDC 机房园区组成，比如上海一号可用区，可能包括了徐汇 IDC 园区和静安 IDC 园区。

这里的原则，就是同一个 AZ 内的机房距离要相对较近，中间可以通过专线互通，保证较低的时延，从而将物理上分离的机房组合成逻辑上统一的可用区，这个是有建设标准的。

一个 AZ 多个 IDC 机房园区的目的，我认为跟多的是提供足够大的资源容量，单个机房的容量有时是有限的，特别是有些通用的存储类服务务，如数据库、缓存、消息、分布式存储等等也可以以 AZ 为单位来统一管理，提供足够容量的同时，也可以方便统一管理。

目前了解到的一些信息，貌似一个 AZ 对应一个 IDC 园区的情况多一些，特别是新建的 IDC 园区，规模足够大，足够匹配 AZ 的头衔。

而一个 Region 多个 AZ 的目的，就是从底层的机房电力/网络等层面来保障一个 AZ 出现故障的时候不会影响到另外一个可用区。

上面仅仅是举例，方便理解，但是实际场景下，这些概念的界限有时候是有些模糊的，据说（仅仅是据说）早期阿里云上海和杭州就是同一个 Region，因为两个地方相对较近，专线带宽、时延和成本相对可控（我想主要是因为阿里有钱吧），所以虽然地域是两个，但是从管理的维度，他们仍然是同一个 Region。

第二，在公有云上的双活、多活，应该怎么选择？

讲到这里，我们再联系下上篇文章提到的同城双活、异地多活的概念，就不难理解，云其实是在同城和异地这个概念之上的一个新的维度。

不过，上面文章如果看明白了，在整清楚上面的几个概念，答案不难得出。

如果要是做同城，其实就是选择同一个公有云同一 Region 的不同 AZ 就好了。

因为前面提过，不同的 AZ 在电力设施和网络入口层面是做了隔离的，不会因为一个 AZ 故障导致其它 AZ 同时故障。而且，不同 AZ 必然是不同的机房，如果考虑地域距离相对远一些，可以选择距离远的 AZ。

比如，业务运行在上海 1 可用区，再建一个双活站点，我就选择到松江区或嘉定区这种距离较远的 AZ，但是 AZ 之间有专线，时延也不用担心有太大问题。

如果是异地，把异地转化成 Region 这个维度来看就好了，就是选择哪个 Region 的问题。

像阿里云前两天的 IO HANG 的故障，看故障描述，应该就是单 AZ 内分布式存储故障，也就是我们常说的 ECS 使用的网盘出现故障，很多 ECS 虚拟机不可用了，这个没招，除非有同城不同 AZ 的双活，立马把业务切走，否则，就只能等着。

第三，关于云产品层面的高可用应该怎么做？

上面我主要讲的还是基础设施层面的内容，不同的 AZ 完全可以满足要求。

或者说的简单点，很多产品都是 AZ 级别的，在一个 AZ 不可用，但是可以跨 AZ 容灾访问。不过前面说的 IO HANG 的问题，就比较困难，现实情况下，跨 AZ 做虚拟机热迁移，这么大批量同时做，带宽满足不了，在很多技术细节上也没法做到，所以，还是具体问题具体看。

但是有些产品，本身就是 Region 级别的，也就是有可能某个 Region 整个地域就是一套服务，比如常见的文件存储 OSS，或者腾讯云的 COS。

这里带来的问题就是，数据或文件存储在 Region 内就一份，比如很多图片、css、js、hdsf 文件存在上面。

如果挂了，就是整个 Region 不可用，这时切同城 AZ 其实也没用了，业务自身有双活、有多活，这个时候都是没效果的。

那咋办呢？

就是在使用这类 Region 级别的产品，必须要要求在另一个 Region 有对应的容灾集群，出问题能切过去。

比如我们在腾讯云上，COS 就做了华东和华南两个 Region 的同步和备份，如果出现灾难状态，华东不可用，我还可以切到华南。

当然，有备份，必然带来成本，但是有时候总比故障造成的损失要小的多，这个还是看 ROI。

对于公有云厂商来说，应该要提供这种 Region 级别的数据同步机制，客户可以自己选择是否需要备份，当故障时，云产品做的完善点可以自己切走，但是厂商一般不会这么做，因为有时候影响并不是全局的，所以这个时候客户自身就要做好切换手段，通过切域名或 IP 的方式，将服务依赖指向可用 Region 的备份集群。

但是，是不是所有产品都适合这种模式呢？答案是，不一定，还是要看场景，看具体情况。

比如，对于文件存储，业务对其时延的要求可能没有这么高，特别是用在 CDN 场景下，时延长一点也没问题。

对于数据库或缓存这样的云产品来说，跨 Region 就没有任何意义了，时延太大，业务根本无法容忍。如果是跨 AZ，数据库可能还好，但是缓存有时候也无法接受。

从 AWS 的标准来说，像数据库或缓存是要保证同 Region 跨 AZ 高可用的，但是实际能不能满足真实的业务要求，这个还要看具体情况，有些系统对时延敏感度极高，可能容忍度就更弱一些。

好在绝大多数的产品都是 AZ 级别，Region 的相对较少，但是一定要注意识别，如果有使用 Region 级别的产品，那我们的双活、甚至多活方案，就要考虑这个因素，而不能仅仅考虑我们自身的技术架构。

单就这一点，客户不提，一般云厂商也没人提，有时候为了跟忧伤对比，反而更喜欢强调自己有多少个 9 的稳定性，这个从客户引导上是有问题的。其实真诚一点，承认自己无法做到 100%，建议客户做更可靠的方案，产品在基础能力层面更完善一些，反而会收到更多的利益，客户也会更满意。

所以，我前面一直在讲，云计算行业，需要有更多的解决方案架构师真正站在客户角度考虑问题，当真正能解决用户的痛点问题时，才会带来更广阔的合作空间，最终带来的收益，一定会这些地方呈现出来。

最后，总结一下：

到了公有云上，面对的场景，使用的产品类型不同，这时候要做高可用，要做容灾，要考虑的因素就更多，其实比自建机房时考虑的因素还要多，因为业务不仅仅是对基础设施依赖，可能还跟很多云产品发生了紧耦合，场景必然更复杂。

几个结论：

• 第一，云上做容灾，做高可用，先搞清楚云的几个关键概念，比如 Region、AZ 和 IDC，以及它们之间的关系。

• 第二，云上的双活就选同城不同 AZ 即可，多活就选多 Region。

• 第三，一定要注意识别云产品的高可用级别，是 AZ 级别，还是 Region 级别，如果是 Region 级别，就要考虑跨 Region 的备份方案，否则，即使做了业务多活和双活，真的灾难状态下，还是起不到作用。

• 第四，大家可以继续补充。

本文转载自成哥的世界公众号。

原文链接：https://mp.weixin.qq.com/s/3wWjT4LYWLeUX6taCsioRg