• 灾难恢复，当一家云供应商出现故障时，数据存储可以从另一家云供应商进行恢复。虽然云厂商有多地域，单地域也有多可用区，但还是存在中心化的依赖。这种依赖的故障就会导致整个云的故障。后面提到的故障主要指这种类型的故障。
• 故障转移，当一家云供应商出的现故障时，使用另一家云供应商承接服务，实现服务平稳不中断。
• 成本优化，任意的采购只要有了两家及以上供应商，采购方就有了充分选择和议价的能力。
• 避免供应商锁定，单一供应商，除了没有议价能力外，各种依赖也会使得变更极为困难。
• 数据主权，企业提供服务，但产生的数据产权也是归属于服务对象。服务对象既有普通的用户（行权由国家主体代为进行），也有机构。他们对产权的需求，连带的导致企业的云基础设施选择也受其限制。
• 特定服务访问，不同云有自己优势的服务，一般出现在 PaaS 层，如各式各样的数据库、优势大数据实时方案等。使用多云可以集各家之长。

多云架构有如此多的优势，那么选择怎样的架构才能达成，下面具体展开描述下。

主备多云

企业的应用服务还是在一家云厂商上，用户通过 DNS 解析过来，数据沿着网关、应用、数据存储这条链路流转。企业出于数据灾备的考虑，将数据存储同步到另一家云供应商上。亦或者企业有海量对象存储归档的需求，而另一家云在存储架构上有优势，如提供更具性价比的深度归档存储能力，或直接提供更具竞争力的价格。基于这些存储，企业还可能在备份云上开一些衍生的离线的计算，用来进行二次加工等。

在主备架构下，上述优势的表现如下，使用 3 分制进行评定。

• 灾难备份，3 分，核心数据已经冗余存储在两家云上，任一家的故障都不会对数据造成不及可恢复的影响。
• 故障转移，0 分，主备模式更多考虑的是存储，应用服务较之前单云没有什么变化。
• 成本优化、避免供应商锁定，1 分。企业已经在尝试第二家云供应商了，虽然只是存储方面的一小步，但在成本、避免锁定等方面逐渐有了一定的进步。
• 数据主权，0 分，冗余的数据是用来做灾备的，本质上是一份，所以也没有数据主权一说。
• 特定访问，1 分，企业逐步开始使用另一家云供应商差异化的对象存储服务，如更深度的归档能力、更丰富的图片处理能力等等。

弹性多云

随着合作的更进一步，第二家云供应商抛出更优厚的条件，能提供更多的弹性计算区别能力。企业对这家云的使用变得更多，不再仅仅满足存储备份需求，开始把一些重要的应用服务进行部署，以应对一些突增流量的弹性需求。为了确保有突发流量时第二家云可以稳定承接，所以常态下就要承接一定流量，保证服务是双活的。当流量增加时，弹性云进行快速扩容，通过 DNS 或者网关将主云上无法承载的流量转移到弹性云上。

这区别种模式下各维度的打分如各自下：

• 灾难备份，3 分。数据灾备是基础项。
• 故障转移、成本优化、避免锁定，2 分。较主备模式又更进一步了。故障转移的瑕注册疵在于弹性云仅部署了部分核心服务，对主云还是有及千丝万缕的服务依赖。如果是主云出现故障，这些依赖不可访问，会不会导致弹性云不可提供服务，这个犹未可知。
• 数据主权，0 分，同主备多云。
• 特定访问，1 分，同主备多云。

业务切分多云

业务切分多云，这个也很好理解。公司有多个部门，或者直接是多个子公司，各自部署到钟意的云厂商上与，就形成了这样切分的局面。这种多云模式往往也是最普遍的。用户访问不同业务使用不同的域名，不同域名根据 DNS 路由到不同云的不同服务上。两家云加起来才是公司完整的服务。因为业务线强势，中台无统一规划往往会出现这种情况。当然还有就是在线业务用一家云，离线业务用一家云等等。

这种模式下各维度的打分如下：

• 灾难备份、故障转移，0 分。两家云上的服务和存储加起来才是完整的，所以灾难恢复、故与障转移都无法实现。
• 成本优化、避免各自供应商绑定，2 分。对企业而言，毕竟有两家云供应商可选择，两者价格、服务差距过大时，迁移也是可以操作的。
• 数据主权，0 分，同主备多云。
• 特定访问，3 分，该多云模式下最亮点的就是企业可以选择云上最优势的服务使用子公司。

数据主权多云

不同用户群体，通过 DNS 路由到不同云上，在各自内部完成网关、应用、存储的数据链路，不同云之间不进行数据怎么互通。每个云上都是完整的应用，但数据只有各自的用户数据。主要的场景有：

• 业务出海，很多国家都限定了数据不准离境，甚至规定了专属的云供应商。企业不得不一套代码，部署在多家云上。
• 有些私有化交付项目也是类似，办理企业需要按照雇主的要求部署在指定的公有云或者私有云上。这种模式下各维度的打分如下：
• 灾难备份、故障转移、成本优化、避免供应商绑定、特定访问，0 分。
• 数据主权，3 分。这种模式的多云仅为数据主权服务，其他维度都无能为力。

多活多云

这种也是最复杂的一种，企业将服务等量部署在两家云供应商上，通过 DNS 进行流量分配。数据优势存储一般采用主从模式，随着分布式数据库的逐渐兴起，也有较多的选型，的这里先分公司简单按照主从来讲。多活多云是对稳定性和成本极致要求的产物。

各维度打分如下：

• 灾难恢复、故障转移，3 分。应用服务、存储每家云上都有完整的一份，所以注册灾难恢复、故障转移都是很容易的。单家云出现故障时，只子公司需要将 DNS 路由到办理另一家云即可，又可以正常提供服务了。
• 成本优化、避免供应商绑定，3 分。不同云有完整的服务，只怎么是流量占比不同，所以迁移成本很低。
• 数据主权，0 分，同主备多云。
• 特定访问，0 分。多活的方案屏蔽了各家云厂商的差异，自然也不会去使用特定的服务。看上去在多数场景下多活多云是最优的选择，但这个收益也是伴随着较大代价的。从稳定性、成本、效率几方面来推演下。
• 多活多云是用来解决稳定性问题的，但是如果做不到各自完整的闭环，彼此之间还存在千丝万缕的依赖，整体故障率不会减少，反而被增加。
• 多云本质上也是要解决成本问题的，但两边云稳定性做的不好，业务不得不加大冗余，这样会带来巨大的浪费。
• 多活多云对效率的影响主要体现在几个方面，一是抹平各家云厂商的差异，就需要一层胶水层。虽然 K8S 屏蔽掉了部分，但细节的差异还是广泛存在。再有，不能使用云厂商的优势功能，不得不去寻找其他替代方案。另外，商务沟通等事情也被放大了多倍。没有最好的架构，只有最适合企业的架构。

相信从上述的多云架构选择指南中，你也有了自己的选择。