共计 2551 个字符，预计需要花费 7 分钟才能阅读完成。
世界正在走向多云。“多云”这个词的含意不能以繁多的形式进行了解，而应该通过多方面的探讨来理解哪些类型的多云性能值得谋求。
1、多云的四个定义
多云的不同用例并不总是互相排挤，这意味着企业能够将多个用例利用于其零碎。本系列文章将涵盖四个多云定义：
在本文中，咱们将探讨数据可移植性。
2、数据可移植性
多云数据可移植性意味着可能将数据从一个云提供商挪动到另一个云提供商。其中的一个重要目标是理解停机、市场情况、价格变动或供应商关系变动。另一个目标是收集和挪动适合的数据。
大规模数据可移植性的最大阻碍是速度和带宽老本。带宽和提早永远是计算中的大瓶颈。网络进口费用往往绝对较高，因而云架构师偏向于将工作负载及其数据放在同一个云上，以最大限度地升高这些老本并缩小提早。
这个概念称为数据引力。将大量数据通过网络挪动到另一个云须要破费大量金钱和工夫。
3、Break-Glass 与间断
用户能够通过两种形式构建数据可移植性：
Break-Glass 的便携性：用户心愿抉择将数据作为逃生口或潜在的业务决策挪动。
继续复制：用户心愿其数据在多个云区域中继续可用。
许多企业在晚期没有抉择间断复制，因而对于这些企业，他们只能更改应用新数据系统的操作。
刚开始进行数据存储的企业有两种截然不同的抉择，但业务老本却截然不同。企业须要依据其抉择做出架构来反对它。
费用
连续式：老本是恒定的。企业会被动领取跨多个站点复制数据的老本。随着每条附加记录的呈现，企业将为此领取增量老本。
Break-Glass：费用产生一次。企业可能在一个微小的数据湖中的一个地位累积数据，而后当企业想要行使挪动所有数据的选项时，其账单要大得多。
随着工夫的推移数据迁徙的粗略老本
如果企业没有在统一的、更小的根底上复制数据，这张图显示了一次性数据挪动的老本 (蓝色的“选项”线) 如何随工夫增长。在大多数状况下，数据呈指数增长，这将使期权线成为向上曲线，而间断线则成为回升线。依据工作负载的不同，任何数据可移植性的老本都会十分高。
初始老本：对于这两种类型，初始老本都很低，因为企业临时还没有太多数据。
继续老本：对于 Break-Glass 的可移植性，继续的数据可移植性老本基本上为零，但对于继续挪动的数据，通过将每个新数据记录复制到多个地位，能够逐步升高数据可移植性的老本。
提早老本：Break-Glass 可移植性的提早老本十分高，因为如果须要挪动和复制所有数据，则费用会很高。通过间断复制，企业曾经为每次创立新记录时的数据挪动提前领取了费用。
一个很好的类比是股票期权与保险。Break-Glass 的便携性就像一个股票期权——企业事后领取大量的费用来抉择行使权力，但如果你抉择行使它，就会付出低廉代价。继续复制就像保险一样，企业每个月都须要领取账单。它可能不会始终对您有用，然而当的确须要它时，它不会使企业付出极为低廉的老本。
2、速度、可扩展性、弹性、可察看性、可管理性
速度、可扩展性、弹性、可察看性和可管理性等其余因素通常有利于间断复制门路。在一次性可移植性场景中，从 GB 到低 TB 的大量数据汇合是可治理的、有弹性的、可察看的并且疾速地挪动，然而随着事务数量和数据大小的减少，这些传输将会变得不那么实用。
小型数据系统和某些用例可能一开始就不须要间断复制——在这些状况下，间断复制的速度或可靠性是无关紧要的。继续复制真正重要的中央是在想要利用动静、云原生应用程序的零碎中，其中大部分数据须要可能立刻可用并在寰球范畴内散发到云供应商。
4、第三抉择：即插即用的专有架构
还有一个方向，既不提供 Break-Glass 的便携性也不提供继续复制——云专有解决方案。如果企业抉择专有的云数据库服务，例如 AWS DynamoDB、Azure CosmoDB、GCP Spanner 等，那么企业就会被该云供应商锁定。
如果企业开始应用其余技术，那么数据将很难挪动。企业诚然能够取得商业反对的解决方案的所有常见益处，并且该供应商的解决方案之间的可移植性可能会相当顺利，然而依据企业的需要和畛域将本人锁定在一个云数据库服务中会是一个微小的危险。
5、实现 Break-Glass 的便携性
对于 Break-Glass 的路线，须要对每个数据区域都有一个通用接口。这意味着企业须要应用宽泛可用的开源数据库或专有解决方案。MySQL、PostgreSQL 和其余开源数据库的托管版本能够失常工作。在应用程序应用雷同 API 的状况下，领有一个兼容的接口更为重要。
例如，企业能够应用 AWS Aurora，但因为有一个通用 API，依然会与 MySQL 有应用程序级别的兼容性。企业的数据系统还须要具备导入 / 导出性能，这样就能够轻松地将数据从一个地位移到另一个地位。
企业不须要实时执行此操作，因为这些是仅按需执行的批处理作业。然而，企业可能必须临时敞开站点能力进行此数据迁徙，具体取决于企业的数据存储以及它是否反对增量导出 / 导入。
6、启用间断复制
对于间断路由，企业须要反对实时复制的零碎。有几个数据系统更关注这种云原生用例，包含 CockroachDB、Cassandra 等。这些零碎提供跨区域数据的继续可用性。
许多传统的数据库系统通常也反对实时流和复制，但可能具备更简单的故障模式，或者只反对被动 / 被动配置。间断复制也须要一个兼容的接口，就像 Break-Glass 的可移植性一样，除此之外，它还须要一个兼容的实现。
借助 Break-Glass 的可移植性，咱们正在进行导出和导入，因而实现可能会有所不同。对于间断复制，应用程序必须反对在事务级别复制数据。这意味着企业不能混合实现（例如 AWS Aurora 和规范 MySQL）来设置间断复制。
7、在抉择前清晰理解本身需要
利用多云数据可移植性的要害是尽早分明地理解本身零碎需要。当然，企业也面临着多种抉择，可能企业会决定将来不再须要数据可移植性，应用云专有技术即可。也可能会设计一个具备在紧急情况下进行大型数据迁徙选项的零碎。或者，企业能够抉择设计一个间断的数据复制零碎，这样就不会产生大量的后续费用。
无论企业做出何种抉择，每个决策都须要事后思考零碎设计和业务老本详情剖析。还须要留神的是，这两种抉择之间的老本可能会依据零碎中应用的工作负载类型而有很大差别。企业的零碎域和领有的数据量也是抉择门路的次要因素。
