软件架构：核心挑战

第 6 章 拆分运行数据 拆分运行数据

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

Thursday, October 7, 08:55

现在，Sysops Squad 应用程序已成功分解为独立部署的域服务，Addison 和 Austen 都意识到，是时候开始考虑分解 Sysops Squad 的单体数据库了。Addison 同意开始这项工作，而 Austen 则开始着手加强 CI/CD 部署管道。Addison 会见了 Sysops Squad 数据架构师 Dana 和支持 Penultimate Electronics 数据库的 DBA Devon。

"我想听听你们的意见，我们该如何去瓦解 Sysops 小队的数据库？"艾迪森说。

"等一下，"达娜说。"谁说要拆分数据库了？"

"艾迪森和我上周一致认为，我们需要拆分 Sysops Squad 数据库，"德文说。"如你所知，Sysops Squad 应用程序一直在经历一次大修，拆分数据也是大修的一部分。"

"丹娜说："我认为单体数据库很好。"我认为没有理由把它拆开。除非你能说服我，否则我不会在这个问题上让步。另外，你知道拆分这个数据库有多难吗？"

"德文说："这当然会很困难，但我知道有一个利用所谓数据域的五步流程，可以很好地利用这个数据库。这样，我们甚至可以开始研究在应用程序的某些部分使用不同类型的数据库，比如知识库，甚至客户调查功能。"

"我们不要太自以为是了，"丹娜说。"我们也别忘了，我才是所有这些数据库的负责人。"

Addison 很快意识到事情已经失控，于是迅速运用了一些关键的谈判和调解技巧。"艾迪森说："好吧，我们应该让你参与我们最初的讨论，对此我深表歉意。我早该知道的。我们怎样才能让你加入进来，帮助我们分解 Sysops 小队数据库？

"这很简单，"丹娜说。"让我相信 Sysops 小队的数据库确实需要拆分。给我一个充分的理由。如果你能做到这一点，我们就可以讨论德文的五步流程。否则，就保持原样。"

拆分数据库很难，事实上比拆分 应用程序功能要难得多。由于数据通常是公司最重要的资产，因此在拆分或重组数据时，业务和应用程序中断的风险更大。此外，数据往往与应用程序功能高度耦合，因此很难在大型数据模型中找出定义明确的接缝。

与将单体应用程序拆分为独立部署单元的方式相同，有时也需要（甚至必须）拆分单体数据库。有些架构风格， ，如微服务，需要将数据拆分开来，形成定义明确的有界上下文（每个服务拥有自己的数据）， ，而其他分布式架构，如基于服务的架构，允许服务共享单个数据库。

有趣的是，用于拆分应用程序功能的一些相同技术也可用于拆分数据。例如，组件可以转化为数据域，类文件可以转化为数据库表，类之间的耦合点可以转化为外键、视图、触发器甚至存储过程等数据库工件。

在本章中，我们将探讨分解数据的一些驱动因素，并展示如何以迭代和可控的方式有效地将单体数据分解为单独的数据域、模式甚至单独的数据库。我们知道数据库世界并不都是关系型的，因此我们还讨论了各种类型的数据库（关系型、图、文档、键值、列式、NewSQL 和云原生），并概述了与每种数据库类型相关的各种权衡。

数据分解驱动程序

拆分单体数据库可能是一项艰巨的任务，，因此了解是否（以及何时）应该分解数据库非常重要，如图 6-1 所示。架构师可以通过了解和分析数据分解者（证明分解数据是合理的驱动因素）和数据整合者（证明将数据保持在一起是合理的驱动因素）来证明数据分解工作是合理的。在这两种驱动力之间寻求平衡，并分析各自的利弊得失，是正确处理数据粒度的关键。 ...