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

为了便于理解，我尽量说的通俗点，大家别跟我抠字眼，如果要找准确定义，大家可以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