什么是“云原生”数据，以及为什么它很重要？

本文要点

• 以鼓励灵活性的方式存储和构建云原生数据
• 适应微型数据库需要新级别的自动化和自助服务
• 与云原生应用程序一样，云原生数据平台应支持纵向扩展和横向扩展
• 如何使用、集成和分析云原生数据可能与过去有所区别

你可能听说过“云原生应用程序”，它是指为适应变更、扩展性、弹性和可管理性而构建的软件。通常情况下，它类似微服务和容器。无论是在公有云还是私有云上运行，云原生应用程序都利用了主机平台提供的弹性和自动化。

但这些应用程序对其所依赖的数据功能有什么影响？云原生应用程序有像 12 因素标准这样的蓝图来指导设计，但你的数据服务却没有。

下面，我们将了解云原生数据的十大特点，以及为什么它们可以帮助你开发出更好的软件。当然，你可能既不想也不需要遵循所有的原则。但不管怎样，它们应该是在现代系统中收集、存储和检索数据时最重要的东西。

1. 云原生数据以多种方式进行储存

15 年前，你在哪里存储数据？一般来说，你有一个本地或通过网络连接的文件系统，以及一个关系型数据库。你将二进制内容保存在文件中，将事务性数据放在规范化数据库中。现在，云原生数据以各种不同的方式生成，并驻留在许多地方。

云原生数据可能位于事件日志、关系数据库、文档或键值存储、对象存储、网络存储、缓存或冷存储（cold storage）中。使用何种方式取决于具体情况。如何存储对持久性要求较高的媒体文件？可以使用对象存储。将未使用的事务性数据保存至监管要求的时间？把它放在冷存储里。为高流量 Web 系统提供产品目录信息？考虑使用缓存或键值存储吧。对延迟、读取性能、持久性等方面的考虑将帮你缩小选择范围。

请注意，在云原生系统中，统一日志通常为记录系统。物化视图表示出了数据的不同用途。这是一种与众不同的数据存储思维方式，颠覆了许多人对数据库的认识！ 统一日志掌握着各种输入源的事务信息。这些内容可能遍布在你的应用程序或缓存中的对象或记录中。这可能是存储数据的一种新方法，但事实证明它是一个很好的解决方案。

也就是说，你不必扔掉可信赖的关系数据库。相反，重新考虑如何使用它。例如，如果你一直在使用关系数据库来保存应用程序的会话状态，那么请考虑引入类似Redis 的东西，并学习如何键值存储。

与此同时，引入像Google Cloud Spanner 这样的现代关系型数据库，这个数据库专门为地理弹性和云规模性能而设计。或使用针对快速查找和高可用性进行过优化的NoSQL 数据库，对象存储就是一种很容易上手的数据库。尽可能避免使用(本地) 文件系统依赖项，并重构应用程序，让它们使用外部存储。

2. 云原生数据没有固定模式

绝大多数情况下，你可以看到云原生应用程序和服务以 JSON 形式来处理数据。也就是说，你也可以使用 protocol buffer 或传统的 XML 来构造数据。无论如何，云原生应用程序优先考虑适应性。这意味着它很容易适应变化。如果数据结构发生变化，你也要跟着不断地修改数据库表结构或重新生成类文件，这种情况下要做到快速适应变化很难。

对于上述问题，可以考虑使用多样化的存储。如果你要求所有数据都符合一种固定的模式，并灵活地插入到 SQL 数据库中，那么就没必要约束自己。可以考虑减少对 ORM 和类的重度使用，因为要对它们作出变更比较困难。

如果你喜欢使用结构化数据模式，请在数据库外层使用设计良好的服务门面。通过版本化 API 的方式来添加新功能或修改数据。

3. 云原生数据具有复制冗余

在学习软件工程时，我们学到了什么？不要重复。这是很有价值的指导原则，但云原生应用程序的数据可能不会只存在于一个地方。

你会发现公有云数据库提供了优秀的弹性。Amazon RDS 这样的服务使创建异步更新的只读副本变得很容易。微软Azure SQL 数据库支持地域分布式。数据保存在一个地方，同时复制到另一个地方。在使用非关系型数据库时，不存在存储所有数据的“主”服务器，数据被复制到许多机器上。这样可以提升弹性，但通常要牺牲一致性。

在你引入缓存时，你发现需要同时读写缓存。 缓存中的数据最终会被写入记录系统。缓存本身是一种数据复制的形式，并且此副本为你提供了更好的性能和弹性。

数据通常从边缘流向内部系统，比如通过云网关从客户端设备移动到应用程序和数据存储中。或者，在处理数据时，它们可能会被保存、过滤或聚合。数据可能不会在这些过程中消失，它们会被用于后续的分析比较或计算。

虽然“记录系统”非常重要，但你的云原生数据可能会被多次复制，用于处理、缓存和多云存储。

4. 云原生数据通过服务接口进行集成

看看 Google Cloud Spanner 或 Amazon DynamoDB 这些云数据库的文档，可以看到什么？它们的 API 是基于 Web 服务 (REST) 的，没有驱动程序，没有固定的 IP 地址。而同样的云厂商也提供传统的关系数据库服务 (例如 Google Cloud SQL、Amazon RDS)，它们使用标准的客户端应用程序、驱动程序和主机名来查询数据库。不过，你将看到通过服务 API 访问云数据的趋势，而不是直接访问底层的服务器和原始模式。从 Salesforce.com 中提取数据时，你不能访问底层的 Oracle 数据库。相反，你可以通过一个精心设计的服务 API 来管理数据的使用和结构。

有一种全新的集成平台，可满足云端点的要求。微软提供了 Logic App，戴尔提供了 Dell Boomi，还有更多像 IFTTT 这样的用户友好型工具。它们有一个共同点，就是它们都连接到不同云系统的主机上，并通过服务接口进行集成。在设计云原生数据策略时，应该考虑如何在应用程序上提供对外的数据端点。

5. 云原生数据以自助服务为导向

可能有人认为，云计算在十几年前得以发展的主要原因是自助服务。企业开发人员不再受制于晦涩的企业规则来获取硬件。而且，创业公司不必进行大规模的资本投资来尝试商业理念。

云原生数据平台支持按需资源调配和自助服务配置。这是不可改变的事实。如果你的数据存储跟不上，那么不断部署和扩展云原生应用程序有什么意义呢？事实是，云原生数据存储在数据库、缓存和文件存储中，可以很容易进行调配，并自动或通过简单的 API 进行伸缩。数据的加载或抽取是通过已知 API 来完成的。我们不能忽视对共享身份、访问和存储策略方面的问题，但这些应该是自动化分配的一部分，或者能够在事后进行审计。

虽然公有云为云原生数据存储设置了标杆，但在一般站点上获得这些功能并不是不可能的。如果说“原生云”运维是指通过软件来运行软件，那么任何一种内部数据产品都必须作为平台运行。

6. 云原生数据与其他租用者是隔离的

出于性能、敏捷性和安全方面的考虑，云原生数据不存放于单个共享实例中。

我们都习惯于构建大规模的数据库实例，从而存储所有内容。共享容量是危险的，不管共享的容量是大是小。相邻的租户会对彼此产生级联影响。所有租户都受制于相同的软件升级时间窗和灾难恢复策略。从安全的角度来看，我们倾向于为特定数据库的用户分配权限。但是随着租户数量的增加，你将拥有一个访问控制规则网络，这可能会导致将某些权限授予不需要它们的人。

云原生数据支持为每个租户分配单个数据库实例。 无论是在共享云平台还是在内部环境中，这些数据库都被分配给单独的服务和应用程序，而不是整个企业。这意味着团队可以控制何时以及如何升级、可以扩展的容量、以及谁可以访问。这些微型数据库提供了更大的灵活性，因为每个团队可以选择最适合他们应用程序或服务的数据库引擎和部署模型。

7. 云原生数据在托管平台上

云原生：它是由软件运行的软件。特别是对于数据库，平台是关键的部分。这是有效管理不断增长的数据库实例的唯一方法。

托管数据库平台提供了什么？首先是安装和配置。你再也无需在精心构建的集群上手动安装 Microsoft SQL Server，这样做容易出错，也很耗时。开发人员和应用程序团队需要单击一个按钮或调用一个 API，从而在他们想要的任何位置获得正确配置的数据库实例。

托管平台同时提供了“day 2”管理。包括内置监控、基础架构扩展、补丁、版本升级和故障恢复。需要一个只读副本吗？只需片刻就可获得一个Amazon RDS 实例。需要高可用性吗？Microsoft Azure Cosmos DB 可以处理节点(或区域) 故障，而且不需要修改代码。这些都不是可有可无的功能，它们代表了大公司存储和访问云原生数据的方式。

8. 云原生数据不害怕横向扩展

当你听到“云”这个词时，除了想到“灵活性”之外，你可能也会想到“扩展”这个词。互联网上充斥着网络公司和初创公司的例子，这些公司处理数十亿甚至数万亿的数据点。虽然你可能不用面对现在的扩展水平，但仍然需要规划未来的增长。与云原生应用程序一样，你的数据容量应侧重于横向扩展，而不是纵向扩展。

设备将会产生前所未有的数据量。数据中心的硬件和软件发出诊断信息。而现在，云端的服务在运行过程中也会发出各种事件。业务应用程序生成和使用各种数据。当你采用云原生数据方法时，将面临不断增加的数据量。

你面临着更多的数据，它们产生的速度越来越快。云原生数据流经实时消息系统或事件流系统，并按 TB 单位进行存储。为了实现这一点，你需要确保消息传递中间件是为突发事件和 AlwaysOn 可用性而设计的。传统上，这意味着需要预先分配巨型集群。在云原生世界中，你的底层平台应该根据需求来扩展消息传递层。

你的数据库 (和数据微服务) 必须能够处理小批量或大批量的数据更新。这可能会影响你设计 RDBMS 模式的方式，也可能影响你在为密集型工作负载选择使用无模式时做出的决策。不再使用大规模的单个数据库实例，而是考虑使用可以扩展到多实例的数据库。横向扩展你的数据库可能会带来事务性权衡，但你获得了更好的灵活性。这意味着较小的初始占用空间，并为不可避免的实例 (和站点) 故障做好准备。

9. 云原生数据是经常被使用和丢弃的

清除数据可能是一个需要克服的心理障碍。我们为了“以防万一”而存储数据。虽然云原生数据容易扩展 (参见上文)，但很多数据都只有临时用途。

可以肯定的是，大量的云原生数据被无限期地保存。但是，你会注意到，越来越多的数据被处理 (在某个地方) 并被丢弃。或许它们在边缘聚集，然后发送一个概要事件到内部系统。或者它们在一定时间段内被用来查找服务器性能异常，随后删除。它们可以是机器学习模型生成的即时购物建议，并在购物者离开网站时删除。

不要觉得好像要储存一切数据。要知道，你现在处理的数据的生命周期比以往任何时候都来得短暂，并在规划其存储介质之前，计算出数据的生命周期。

10. 云原生数据按照实时和批量的方式进行分析

流数据非常流行，但据研究公司 Gartner 的报告显示，85% 的企业仍然青睐面向批处理的技术。这一数字将随着时间的推移而减少，但云原生数据同时需要实时和批处理。

基于云的流引擎 (如 AWS Kinesis 或 Azure Event Hubs）简化了无边界事件的处理。客户使用这些引擎来检测欺诈、更新定价或揭示性能问题。这些引擎还将数据转储到数据仓库中，进行更复杂的批量分析。在那里，可以对相同的数据进行现场分析和更有意义的分析 。

总结

现在还处在云原生数据的早期阶段。我们如何将遗留数据存储引入到云原生应用程序中？处理多云数据需求的正确方法是什么？锁定和可移植性在哪里？虽然这些问题还没有明确的答案，但是本文率先研究了云原生概念如何应用于数据领域中。在未来的几个月甚至几年中，我认为我们将花更多的时间来探索这一重点领域。

关于作者

Richard Seroter 是 Pivotal 的高级产品主管，拥有科罗拉多大学工程硕士学位。他也是 10 届微软 MVP、Pluralsight 公司培训讲师、演说家、InfoQ 云计算首席编辑，同时还是多本有关应用程序集成战略的图书作者。Richard 通过定期更新的博客探讨架构和解决方案相关话题，可以在Twitter 上关注 @rseroter 。

查看英文原文： What Is “Cloud-Native” Data and Why Does It Matter?

感谢薛命灯对本文的审校。