软件架构：核心挑战

第 4 章 建筑分解 架构分解

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

Monday, October 4, 10:04

现在，Addison 和 Austen 已经获得许可，可以迁移到分布式架构 ，并拆分单体的 Sysops Squad 应用程序，他们需要确定如何开始的最佳方法。

"这个应用程序太大了，我都不知道从何说起。它有一头大象那么大！"艾迪生感叹道。

"好吧，"奥斯汀说。"大象怎么吃？"

"哈，我以前听过这个笑话，奥斯汀。当然是一口一个！"爱迪生笑道。

"没错。那么，让我们用同样的原则来处理 Sysops 小队的应用程序吧，"奥斯汀说。"我们为什么不一次一口地把它拆开呢？还记得我说过，报告是导致应用程序冻结的原因之一吗？也许我们应该从这里开始"。

"艾迪森说："这也许是个好的开始，但数据怎么办？仅仅将报告作为一项单独的服务并不能解决问题。我们还需要将数据拆分开来，甚至创建一个单独的报告数据库，并用数据泵为其提供数据。我认为，从一开始就这样做，代价太大了。

"你说得对，"奥斯汀说。"嘿，知识库功能怎么样？那是相当独立的，可能更容易提取。"

"没错。那调查功能呢？这应该也很容易分离出来。"艾迪森说。"问题是，我不禁觉得我们应该更有条不紊地解决这个问题，而不是一口一口地吃掉大象。"

"奥斯汀说："也许洛根能给我们一些建议。

Addison 和 Austen 与 Logan 会晤，讨论了他们正在考虑的如何拆分应用程序的一些方法。他们向 Logan 解释说，他们想从知识库和调查功能入手，但不确定之后该怎么做。

"洛根说："你建议的方法就是所谓的大象迁移反模式。一口一口地吃掉大象在开始时可能看起来是个好方法，但在大多数情况下，这会导致一种无序的方法，从而形成一大团分布式泥浆，也有人称之为分布式巨石。我不建议采用这种方法。

"那么，还有其他方法吗？有什么模式可以用来拆分应用程序吗？"艾迪生问道。

"洛根说："你需要从整体上看待应用程序，并应用战术分叉或基于组件的分解。"据我所知，这是两种最有效的方法。

艾迪生和奥斯汀看着罗根。"但我们怎么知道用哪个呢？"

架构模块化描述的是为什么要拆分单体应用程序，而架构分解描述的是如何拆分。拆分大型复杂的单体应用程序可能是一项复杂而耗时的工作，因此了解开始这项工作是否可行以及如何进行非常重要。

基于组件的分解（Component-based decomposition）和战术分叉（Tactical forking）是拆分单体应用程序的两种常用 方法。基于组件的分解是一种提取方法，它应用各种重构模式来提炼和提取组件（应用程序的逻辑构件），以渐进和可控的方式形成分布式架构。战术分叉法是指复制应用程序，然后削去不需要的部分以形成服务，就像雕刻家从一整块花岗岩或大理石中创造出一件精美的艺术品一样。

哪种方法最有效？答案当然是 "视情况而定"。选择分解方法的主要因素之一是现有单片应用程序代码的结构如何。代码库中是否存在清晰的组件和组件边界，还是代码库在很大程度上是一个无结构的大泥球？

如图 4-1所示，架构分解工作的第一步是首先确定代码库是否可以分解。我们将在下一节详细介绍这一主题。如果代码库是可分解的，那么下一步就是确定源代码是否基本上是非结构化的一团糟，没有明确定义的组件。如果是这样，那么战术分叉（参见"战术分叉"）可能是正确的方法。但是，如果源代码文件的结构方式是在定义明确（甚至是松散定义）的组件中组合同类功能，那么基于组件的分解方法（参见 ...