【squids.cn】 全网zui低价RDS，免费的迁移工具DBMotion、数据库备份工具DBTwin、SQL开发工具等
数据库设计是微服务和云原生解决方案的关键因素，因为基于微服务的架构导致了数据的分布式。数据管理不再在一个单一的过程中发生，而是可以通过多个过程来操作数据。云计算的兴起使得数据更加分布式。
为了应对这种复杂性，微服务和云原生解决方案已经出现了几种数据管理模式。在这篇文章中，我们将看到一些可以帮助我们在分布式环境中管理数据的最重要的模式。
微服务和云数据库设计的挑战
在我们深入了解具体的数据管理模式之前，理解微服务和云数据库设计的主要挑战是很重要的：
- 在微服务架构中，数据分布在不同的节点上。其中一些节点可能位于世界上完全不同的地理区域的不同数据中心中。在这种情况下，很难保证所有节点之间数据的一致性 。在任何给定的时间点，各个节点之间的数据状态可能会有所不同。这也被称为最终一致性的问题。
- 由于数据是分布式的，没有像单节点单体系统中那样管理数据的中央权威。对于各种参与系统来说，使用一种机制（例如，共识算法）进行数据管理非常重要。
- 在微服务架构中，恶意行为者的攻击面更大，因为有多个活动部件。这意味着我们需要在构建微服务时建立更为强大的安全态势。
- 微服务和云的主要承诺是可伸缩性。尽管扩展应用程序过程变得更容易，但水平扩展数据库节点却并不容易。如果没有适当的可伸缩性，数据库可能会成为性能瓶颈。
深入数据管理模式
考虑到相关的挑战，有几种模式可用于管理微服务和云原生应用程序中的数据。这些模式的主要任务是帮助开发人员解决上述各种挑战。让我们逐一看看这些模式。
每个服务一个数据库
顾名思义，这种模式建议每个微服务管理其自己的数据。这意味着没有其他微服务可以直接访问或操作由另一个微服务管理的数据。任何数据的交换或操作只能通过一组明确定义的API来完成。下图显示了一个每个服务一个数据库模式的例子。
图1: 每个服务一个数据库模式
表面上看，这种模式似乎相当简单。当我们从一个全新的应用程序开始时，可以相对容易地实施它。然而，当我们将现有的单体应用程序迁移到微服务架构时，服务之间的划分并不是那么清晰。
大多数功能都是以一种不同系统部件非正式访问其他部件数据的方式编写的。
在使用每个服务一个数据库模式时，我们需要关注两个主要领域：
- 为每个服务定义有界上下文
- 管理跨多个微服务的业务事务
共享数据库
下一个重要的模式是共享数据库模式。尽管此模式支持微服务架构，但它通过使用可供多个微服务访问的共享数据库采取了一种更为宽松的方法。对于正在过渡到微服务架构的现有应用程序，这是一个更安全的模式，因为我们可以慢慢地发展应用程序层，而无需更改数据库设计。然而，这种方法削减了微服务的一些优势：
跨团队的开发人员需要协调表格的模式更改。当多个服务试图访问相同的数据库资源时，可能会出现运行时冲突。
CQRS 和事件溯源
在命令查询责任分离（CQRS）模式中，应用程序监听来自其他微服务的域事件，并更新一个单独的数据库以支持视图和查询。然后，我们可以从这个单独的数据库中服务复杂的聚合查询，同时根据需要优化性能并按需扩展。
事件溯源通过将实体或聚合的状态存储为事件序列来更进一步。每当我们对对象进行更新或插入时，都会创建一个新事件并存储在事件存储中。我们可以一起使用CQRS和事件溯源来解决围绕事件处理和维护单独查询数据的许多挑战。这样，您可以根据各自的需求单独扩展写入和读取。
图2: 事件溯源和CQRS一起执行
不足之处在于，对于大多数开发人员来说，这是一种不熟悉的构建应用程序的方式，并且有更多的移动部件需要管理。
Saga 模式
Saga模式是处理跨多个微服务的业务事务的另一个解决方案。例如，在食品配送应用上下订单是一项业务事务。在Saga模式中，我们将此业务事务分解为由不同服务处理的一系列本地事务。对于每个本地事务，执行事务的服务都会发布一个事件。
事件触发另一个服务中的后续事务，并且链条持续下去，直到整个业务事务完成。如果链条中的任何特定事务失败，Saga将通过执行一系列补偿事务来回滚，以撤销所有先前事务的影响。
Saga实现有两种类型：
- 基于编排的Saga
- 基于编舞的Saga
分片
分片有助于构建云原生应用程序。它涉及将一张表的行分隔到多张不同的表中。这也被称为水平分区，但是当分区位于不同的节点上时，它们被称为分片。分片帮助我们提高数据库的读写可伸缩性。同时，它还提高了查询的性能，因为由于分片，特定的查询必须处理更少的记录。
复制
复制是一个非常重要的数据管理模式。它涉及创建数据库的多个副本。每个副本都是相同的，并运行在不同的服务器或节点上。对一个副本所做的更改将传播到其他副本。这就是所谓的复制。有几种类型的复制方法，例如：
- 单领导者复制
- 多领导者复制
- 无领导者复制
复制帮助我们实现高可用性和提高可靠性，并且它让我们扩展读取操作，因为读取请求可以转发到多个服务器。下面的图3显示了分片和复制的组合运作。
图3: 使用分片和复制一起
云原生环境中数据库设计的最佳实践
虽然这些模式可以在很大程度上解决微服务和云原生架构中的数据管理问题，但我们还需要遵循一些最佳实践以简化操作。
以下是一些最佳实践：
- 我们必须尝试为弹性设计解决方案。这是因为在微服务架构中，故障是不可避免的，设计应适应故障，并在不中断业务的情况下从中恢复。
- 当过渡到其中一个模式时，我们必须实施适当的迁移策略。一些常见的可以评估的策略包括模式优先与数据优先，蓝绿部署，或使用扼杀者模式。
- 不要忽视备份和经过良好测试的灾难恢复系统。这些事情对于单节点数据库来说也很重要。然而，在分布式数据管理方法中，灾难恢复变得更为重要。
- 在微服务或云原生应用程序中，持续监控和可观察性同样重要。例如，分片技术可能会导致不平衡的分区和热点。如果没有适当的监控解决方案，对这种情况的任何反应可能都为时已晚，并可能使业务面临风险。
结论
我们可以得出结论，良好的数据库设计在微服务和云原生环境中绝对是至关重要的。没有适当的设计，应用程序将因分布式数据的固有复杂性而面临多个问题。存在多种数据管理模式，以帮助我们以更可靠和可扩展的方式处理数据。然而，每种模式都有自己的挑战和一组优势和劣势。没有哪种模式适合所有可能的情景，我们应该在处理了各种权衡后才选择特定的模式。
作者：Saurabh Dashora
更多内容请关注公号【云原生数据库】
squids.cn，云数据库RDS，迁移工具DBMotion，云备份DBTwin等数据库生态工具。