主备｜弹性｜多活，如何正确的选择多云架构？

多云是指企业使用两个或更多的公有云 IaaS 供应商。广义来看，混合云也在其范畴。多云架构有如下优势：

灾难恢复，当一家云供应商出现故障时，数据存储可以从另一家云供应商进行恢复。虽然云厂商有多地域，单地域也有多可用区，但还是存在中心化的依赖。这种依赖的故障就会导致整个云的故障。后面提到的故障主要指这种类型的故障。
故障转移，当一家云供应商出现故障时，使用另一家云供应商承接服务，实现服务平稳不中断。
成本优化，任意的采购只要有了两家及以上供应商，采购方就有了充分选择和议价的能力。
避免供应商锁定，单一供应商，除了没有议价能力外，各种依赖也会使得变更极为困难。
数据主权，企业提供服务，但产生的数据产权也是归属于服务对象。服务对象既有普通的用户（行权由国家主体代为进行），也有机构。他们对产权的需求，连带的导致企业的云基础设施选择也受其限制。
特定服务访问，不同云有自己优势的服务，一般出现在 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 屏蔽掉了部分，但细节的差异还是广泛存在。再有，不能使用云厂商的优势功能，不得不去寻找其他替代方案。另外，商务沟通等事情也被放大了多倍。没有最好的架构，只有最适合企业的架构。