针对云原生转型的6个关键数据策略

如今，许多组织正在将采用云原生平台作为其数字转型战略。云原生允许企业以更灵活的方式提供快速响应、用户友好的应用程序。但是，支持云原生转换的数据体系结构常常被忽略，希望它会自行处理。

随着数据成为每个组织的信息货币，企业如何在云计算转型过程中避免常见的数据错误？在构建云原生应用程序时，应该知道哪些数据问题？如何从数据中获得有价值的见解？以下将阐述企业在向云原生转型过渡时必须考虑的六个关键因素：

（1）放弃面向服务体系结构（SOA），采用微服务

尽管仍有许多遗留应用程序仍然是基于面向服务体系结构（SOA）的，但架构思维已经发生了变化，并且微服务获得了广泛的普及。开发人员可以通过创建许多协同工作的独立服务来获得许多益处，而不是构建单一应用程序。微服务架构在应用程序开发和简单的代码库中提供更高的灵活性。可以独立地实现更新和扩展服务，其服务可以采用不同的语言编写，并连接到不同的数据层和选择的平台。这种策略允许开发人员和运营人员以更加和谐的方式一起工作。这种组件化架构需要一个数据库平台，可以轻松支持不同的数据类型、结构和编程语言。

（2）12-Factor App和云原生微服务

“十二要素应用程序”（12-Factor App）是一套帮助组织构建云原生应用程序的规则和准则。它是一个很好的起点，但是在数据平台方面，有几个因素（第4个和第5个）需要进一步检查。

第4个因素：将支持服务视为附加资源：这里的“支持服务”大部分是指数据库和数据存储。这意味着微服务需要模式和底层数据存储的专用单一所有权。

第5个因素：严格分离构建和运行阶段，单独的构建和运行阶段意味着应用程序应该作为一个更多的无状态进程执行，并且状态通常被加载到后台服务上。这进一步意味着数据库和数据存储应该是有状态的服务。

（3）持续集成/持续交付

服务流程的扩散（每个服务可独立部署）需要自动部署和回滚机制，这称之为持续集成或持续交付（CI/CD）。实际上，如果没有成熟的CI/CD功能，微服务的价值就无法完全实现。请注意，这种瞬态架构意味着数据库实例也将是短暂的，并且它们还必须能够根据需要轻松启动。借助正确的云原生平台和支持数据平台，微服务变得易于部署。云原生平台应处理对其运行的服务的管理，并且数据库应处理数据扩展和监视，在必要事件中添加碎片，重新平衡、重定位或故障转移。组合的数据库和云原生解决方案减轻了监控数据库和平台的运营负担，使企业可以花更多时间来开发和部署优质软件。

（4）多云部署模型的重要性

如今的企业采用多云策略是出于多种原因：准备灾难恢复情况，利用不同云计算基础设施中托管应用程序之间的财务差异，增强安全性，或简单地避免供应商锁定。企业的应用程序代码应该独立于预期运行的平台。

（5）整体与非整体

数据访问和数据移动的传统方法是令人望而却步的。传统方法涉及在其他运营数据存储和数据仓库/数据湖中的主数据存储中创建数据的副本，其中数据在数小时或数天后更新，通常是批量更新。由于组织采用微服务和设计模式，数据在不同类型的数据存储中传输的延迟阻碍了敏捷性，并阻止组织推进其业务计划。

随着采用扼杀模式逐渐将单一应用程序迁移到微服务架构，逐渐用新的应用程序和服务取代特定的功能。这意味着关联的数据存储也需要进行分区和组件化，这意味着每个微服务都可以拥有自己的关联数据存储/数据库。

从数据角度来看，这意味着：

随着每个微服务的增加，数据库实例的数量也随之增加，而再次指向需求上升或下降。

为了使这些微服务彼此进行通信，需要调用额外的HTTP，比如便于使用的REST API，这些都需要在任何平台和语言中灵活扩展。在许多情况下，微服务只是发布指示更改的事件，而监听器/订阅者更新关联的应用程序。

（6）云原生数据库的基本要求

亚毫秒级响应时间仅供少数特殊应用使用。但是，在当今微服务架构的世界中，这是所有应用程序的必备条件。这个延迟要求需要最高性能、最具可扩展性的数据库解决方案。

Active-Active数据复制

批处理模式下的数据复制曾经是一种流行的方法。但对于实时应用程序来说，事件存储和事件采购的复制变得更具吸引力。在松散耦合且需要共享数据的微服务应用程序中，需要具有可调一致性的Active-Active数据复制。许多客户使用Active-Active部署模型的原因很多，例如：

正在不断更新的微服务中的共享数据集。

跨数据中心无缝迁移数据，以便用户体验不受影响。

减少故障情况并把故障切换到第二个数据中心，以最大限度地减少停机时间。

处理大量传入流量并通过无缝同步在多台服务器上分配负载。

地理位置分散的应用程序（如多人游戏或实时竞价/轮询应用），数据需要在多个地理位置之间同步。

数据的高可用性

当企业将一个巨大的应用程序分解成微服务，并且每个微服务都有自己的生命周期时，如何确保数据可用性？云原生应用程序开发人员应该根据恢复点目标（将丢失多少数据？）选择数据存储恢复时间目标（当事件发生时，需要多长时间才能恢复服务？）、高可用性特性、安装拓扑结构和故障转移策略。单节点数据库实例不仅影响故障情况，还会影响客户端宕机事件（如版本升级）影响可用性。

高可用性要求通常取决于应用程序的关键程度，但正确的数据库和云原生让解决方案的组合支持各种高可用性安装策略，适用于从内部部署到关键任务应用程序的各种用例。