三个问题帮你构建更好的软件架构

在任何软件开发工作中，总是有太多的事情要做，而时间或资源却远远不够。问题在于我们想要构建的东西可能无限大，而相比之下，我们可用的时间和资源却几乎无限小。

这尤其适用于架构设计。软件架构设计的艺术在于决定哪些决策需要现在就做出，哪些可以等等。

做决策涉及到回答关键问题，某些问题需要按照特定的顺序回答。成功设计架构的关键是根据经验快速且低成本地拒绝错误的假设/断言。换句话说，就是快速找到那些错误且成本高昂的可选方案，并选择一个更好的替代方案。最小可行产品（MVP）及其最小可行架构（MVA）方法有助于回答这些问题。

如果在交付 MVP 时遇到了看似不切实际的截止日期挑战，团队就需要按照特定顺序回答一些关键问题：

1. 这个业务想法值得追求吗？

2. 需要多大的性能和可扩展性？

3. 需要多大的可维护性/模块化和可支持性？

图 1：解答三大关键问题，确定 MVA 决策和权衡取舍

这些问题的答案决定了团队在设计 MVA 时需要做出的架构决策和权衡取舍（见图 1）。

这个列表不包括有关安全（包括网络安全和数据保护）的问题，因为安全没有商量余地，所以不应涉及权衡取舍。正如我们在之前的文章中所讨论的那样，回答这些问题的唯一方法是运用经验主义并进行实验。

最重要的问题是“业务想法值得追求吗？”

想法是廉价的，解决方案很昂贵，不解决实际问题的解决方案就是浪费。团队可以做出的最重要的决策是决定不构建人们不需要的东西。MVP 可以测试提出的解决方案的价值。对我们来说，MVP 是一种机制，用于确定产品想法是否有价值。

MVP 必须测试业务想法提交审批时所做的假设（特别是技术假设）。这些假设还有效吗？你怎么知道？你需要收集哪些数据才能确定？MVP 需要能够收集这些数据。

这与软件架构有何关联？你不会想为没人需要的产品创建架构的。在验证业务想法时，你将测试驱动质量属性的假设，如可扩展性和性能需求。为此，MVP 不能仅仅是一个概念验证，它还需要具备足够的可扩展性和性能来验证业务场景，但它不需要回答所有关于可扩展性和性能的问题，至少现在不需要。

此外，成本始终是一个考量因素，MVP 必须评估业务场景是否可以满足。如果解决方案过于昂贵，无法满足用户的需求，那么追求它就是不值得的。在设计 MVA 的过程中，需要充分探讨成本问题，以确保解决方案不会超出预算。

第二重要的问题是“性能和可扩展性需求是怎么样的？”

早期性能问题是未来扩展问题的先行指标，至少在潜意识里，业务发起方要理解这一点。如果一个系统在只有一两个用户的时候也出现响应迟缓的情况，那么发起方就会质疑系统是否能够实现其性能和扩展目标。因此，及早关注性能问题可以保障未来开发工作的顺利进行。

与性能相关的决策挑战在于“性能”是主观的，取决于用户的期望。他们当然希望系统能够即时响应，但稍微有点延迟也是他们能够接受的。因此，团队在处理方式上就有了权衡取舍的空间。例如，耗时较长的事情可以转移到异步后台任务中，只要在用户需要时能及时提供结果即可。

用户还会根据性能预测可扩展性。初始性能不佳可能会让用户对系统是否能够扩展并提供可接受的性能产生怀疑。这可能会导致他们对 MVP 的可行性提出质疑。

在处理性能问题时，有一些类似于物理定律的必然规律：

• 由于物理吞吐量限制，访问存储设备的数据总是昂贵的。

• 由于延迟限制，远程数据访问非常昂贵。

• 通过将数据移动到内存中，可以降低数据访问的成本，但这只有在数据量小且内存相对比较大时才有效。

因此，总是需要在数据存放位置和访问方式之间进行权衡，这也意味着需要在两个处理成本来源之间进行权衡。

你怎么才能知道？你需要收集哪些指标才能做出决定？

有时，执行一个复杂的算法需要很长时间，并且成为性能问题的来源。除了优化和近似计算外，这些计算通常是适合移至后台任务的良好候选对象。

要验证系统是否将提供良好的性能，需要团队构建系统的关键部分，以便测试某些事情是否需要假设的时长。团队不需要构建整个系统，但他们确实需要构建系统中那些对性能影响最大的部分。

与性能相关的一个问题是“需要多大的可扩展性？”

可扩展性是一种无形的质量特性，是指系统在高负载（用户、数据、事务等）情况下表现为性能下降。因此，要衡量可扩展性，就需要团队在负载增加时度量性能。用户希望系统具有良好的可扩展性；对他们来说，负载增加应该是“隐形”的。

可扩展性投资是团队需要做出的最昂贵的决策之一，因为他们通常可以为了提高可扩展性做任何事。问题是要知道实际需要多少可扩展性。

团队在交付最小可行产品（MVP）时几乎总是会面临可扩展性挑战。那么他们应该现在就进行可扩展性设计，还是应该推迟相关决策？正如我们在之前的文章中讨论的那样，扩展系统是一个难题，找到恰当的平衡至关重要。在可扩展性方面投资不足可能会限制系统的寿命，而过度投资则可能会因为成本问题而对 MVP 的业务场景产生负面影响。

通常，团队很难准确预测可扩展性需求，其中一部分原因是业务发起方可能发现很难预测系统使用的增长情况；他们通常会希望系统有接近“无限”的可扩展性。遗憾的是，没有相应的预算。然而，可扩展性需求总是存在的，只是有时不那么明显。每个系统都有一个业务场景，其中有隐含的可扩展性需求。

最终，要仔细权衡才能实现可负担的可扩展性。例如，使某些任务异步来提高可扩展性，但这样做可能会增加协调这些后台任务的复杂性。这种复杂性不是免费的，可能会影响性能。

实现了可扩展性又要保持良好的性能，可能意味着重新设计你已经构建好的部分解决方案；用户少时表现良好的解决方案可能在负载增加时崩溃。另一方面，你可能永远不需要扩展到会导致这些故障的负载，所以过早过度投资可能只是浪费。

许多扩展问题也源于一个关键瓶颈，通常是与访问共享资源有关。及早发现这些问题，团队便可以知道，何时以及在什么条件下他们可能需要改变他们的方法。

第三个重要的问题是“需要多大的可维护性/模块化和可支持性？”

为了使系统更容易开发、理解和维护，团队会以模块化的方式进行开发。模块化程度高的系统也有助于团队识别和利用重用机会。参数化或可配置性等技术也可以使系统更容易维护，因为某些类型的更改不需要更改代码了。

然而，这些策略也不总是有用。预测永远不会发生的更改只是浪费精力。实现从未使用过的可配置性也是浪费。在不知道 MVP 是否会成功之前，提高系统模块化程度、可维护性和可支持性的努力可能都只是浪费。

使系统更易于维护和支持的挑战在于预测最有可能发生的更改类型，并为更改代码做好准备。

在之前的文章中，我们识别了开发 MVP 及其相关 MVA 时可能出现的 5 种结果：

1. MVP 成功，MVA 不需要更改；

2. MVP 成功，但 MVA 不可持续；

3. MVP 部分而不是完全成功，但可以修复；

4. MVA 部分而不是完全成功，需要改进；

5. MVP 不成功，所以 MVA 便无关紧要了。

在那篇文章中，我们观察到，结果 #2、#3 和 #4 是团队最有可能会面对的情况。如果 MVP 成功，团队应该迅速确定 MVA 是否可持续。这样一来，大多数团队都得处理结果 #3 和 #4。

对于结果 #3，为了修复 MVP，团队应该在可维护性方面进行足够的投资，因为他们还没有确切地知道 MVP 需要做什么。总是有这样的风险，他们对 MVP 做了一些更改，却发现他们实际上是在处理结果 #5，一个不可行的 MVP。在实践中，这意味着要在模块化方面进行足够的投资，使下一次迭代更容易，例如，定义主要组件的接口，但实现只需要足够支持 MVP 即可，改进可以留待以后进行。

结果 #4 既简单又复杂。最小可行产品（MVP）是可能还需要做更多的工作，但最小可行架构（MVA）是肯定还需要做更多的工作。换句话说，你还没有可行的 MVA，比如可能性能不佳或无法扩展。或者，它可能缺少你不知道是否需要构建的主要组件，如果确实需要构建，可能成本就太高了。在这种情况下，团队的重点应该是证明 MVP，当然，也可以探索可能的 MVA 折衷方案，看看是否有一个既能够满足 MVP 需求又负担得起的 MVA。

这与模块化、可维护性和可支持性之间的关联在于：团队应该投入恰到好处的资源，确保能够根据需求持续演进 MVA。模块化与性能/可扩展性之间往往存在权衡取舍关系，因此需要通过实验验证进行评估。

使用技术债务来评估可支持性和可维护性

正如我们在之前的文章中讨论的那样，技术债务是一个流行的隐喻，用于向利益相关者传达架构决策和权衡取舍的长期影响。技术债务是衡量系统可支持性和可维护性的一种方式。在交付 MVP 时，产生技术债务是不可避免的，因为要快速获取针对业务概念和技术解决方案的反馈。

团队必须做出的最重要的架构决策之一，就是确定如何判断技术债务是否已累积到超出系统未来可支持性与可维护性的临界点。他们的首要任务是明确当前实际产生了多少技术债务。实现这一目标的其中一个方法，是在架构决策记录（ADR）中详细记录所有可能产生技术债务的决策。

接下来，他们需要做的是运用经验主义来度量可维护性和可支持性。一种方法是考虑团队在发布版本时的返工成本。每次迭代（对于使用 Scrum 的人来说，是 Sprint）都不可避免地会产生一些返工，因为他们会纳入之前迭代的反馈。度量这种返工可以帮助团队了解撤销/重做现有代码的成本。

另一种理解可维护性和可支持性的方法是将变更案例纳入工作流程。变更案例非常简单，本质上，它是通过有意识的返工来检验架构决策在代码中的可变更性。这可能涉及更换主要组件或子系统，或者在某些地方将消息模型从同步更改为异步。关键在于，通过小范围的代码变更预判未来可能发生的变化，进而推演结果以评估可维护性。

结论

用 Helmuth von Moltke 的话来说，没有 MVP 能经得住客户的检验。这也会影响到 MVA。就架构决策而言，团队首先需要考虑业务想法是否值得追求，如图 1 所示。这反过来又会影响他们对 MVA 的决策。

根据我们的经验，团队必须做出的下一组最重要的架构决策涉及性能和可扩展性，因为这些会对技术选择产生广泛的影响。只有在那时，关于可维护性和可支持性的决策才值得考虑，因为性能和扩展决策的变化经常影响系统的构成。反过来，这些决策可能会超出成本限制，进而影响系统的商业可行性。

架构决策的一项挑战是，永远无法真正地一劳永逸；每一条新信息都可能改变决策的影响，所以团队总是在根据新情况调整他们的决策。因为 MVP 是一系列小实验，所以它会根据反馈随时间演进。MVA 也需要以类似的方式和时间框进行演进。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/articles/three-questions-better-architecture/