MVP 困境：现在就扩展还是以后再扩展？

本文要点

• 扩展系统是一个很难解决的问题。对可扩展性投资不足会缩短系统的生命周期，但过度投资可能会因为成本问题而扼杀 MVP 业务案例。

• 团队经常猜测可扩展性需求，因为业务发起人很难考虑系统使用的增长。

• 确实存在可扩展性要求，只是很难看到它们。每个系统都有一个商业案例，而商业案例具有隐含的可扩展性要求。

• 以可承受的成本实现可扩展性涉及微妙的权衡。大多数扩展问题是由系统中的某些关键瓶颈引发的，通常是由对共享资源的访问引发的。

• 架构实验是解决可扩展性过度构建的好方法。

引言

每个最小可行产品（MVP）内部都隐藏着一个隐含的可扩展性假设。每个产品都有一个商业案例，而这个案例几乎总是（如果不是总是的话）依赖于一定程度的可扩展性来获得成功。在当今世界，每一个成功的商业想法都必须触及大量的人群才能实现其财务目标。因此，每个软件系统都极度关注可扩展性。如果一个想法不能服务于大量的人群，那么这个想法再好也没有用。因此，最有趣，也可能是最困难的架构决策都是关于可扩展性的。

正如我们在之前的一篇文章中提到的：

“可扩展性有时会与性能混淆，而性能与可扩展性不同，它是关于软件系统满足其时间要求的能力，并且比可扩展性更易于测试。如果系统的性能在初始发布中是足够的，那么团队可能会假设系统能够应对增加的工作负载。但不幸的是，这种情况就很少会发生，即在架构设计时没有将可扩展性作为最重要的顶级质量属性（QARs）之一。”

系统的最小可扩展性需求是满足商业案例所需的使用水平。更多可能很好，但如果商业案例无法实现，那么系统就不值得构建。因此，开发团队需要评估他们系统的架构，以确保能够达到这个最低水平。

一个明智的团队会确保他们有足够的能力来预测未来的使用增长，而不会过度投资到超出他们计划预算的地步。决定预测增长多少是架构艺术的一部分，但需要考虑市场规模和系统支持的解决方案的增长潜力。

团队经常对可扩展性需求进行猜测

团队通常对可扩展性需求没有什么具体的要求。业务可能不是信息的可靠来源，但正如我们上面提到的，他们确实有一个隐含的可扩展性需求的商业案例。团队很容易在早期专注于功能需求，而忽视这些隐含的可扩展性要求。他们可能希望扩展不会成为问题，或者他们可以通过投入更多的计算资源来解决问题。他们对过度构建和不断增加的成本有合理的担忧，但希望扩展问题不会发生并不是一个好的扩展策略。团队需要从一开始就考虑扩展。

在之前的一篇文章中，我们写道：

“最小可行架构（MVA）由一组最小的技术决策组成，这些决策随着时间的推移通过实证主义进行测试和演变。这些决策由一组最小的架构实践来补充，这些实践帮助团队在开发过程中保持产品在架构上的可行性。”

客户反馈通常是关于 MVP 可行性的唯一可靠信息来源，但在你构建一些东西之前，你无法收集这些反馈，而这些东西可能是不可扩展的。因此，可扩展性的架构设计必须是一个迭代的、实验驱动的过程。不幸的是，开发团队有时不愿意在早期的实验中关注可扩展性，因为他们想看看 MVP 是否成功，然后才会担心他们的解决方案是否具有可扩展性。这有一定的逻辑，但问题是 MVP 必须具有可扩展性才能成功。

以可承受的成本实现可扩展性涉及微妙的权衡

对可扩展性需求的不确定性造成了一个困境：如果你的解决方案没有足够的可扩展性，它将在市场（或与你的用户）中失败，但是如果你创建的解决方案的可扩展性超过了你的需求，通过过度投资可扩展性，你可能会在财务上失败。

团队经常会低估产品对可扩展性的需求，例如：

• 他们可能对系统的可扩展性过于乐观，因为他们没有测试他们的假设。

• 他们假设技术（例如云）将解决他们遇到的任何问题。这种情况很少发生，因为可扩展性的障碍通常是由产生瓶颈的决策造成的，而不仅仅是简单地“引擎不够大或不够快”。

• 他们非常担心将最初发布的产品简单地交到客户手中，以至于他们认为可扩展性是一种“锦上添花”只需事后考虑的事情。

然而，过度投资于扩展也是一个问题，因为它会导致成本和进度超支，以及产生臃肿和性能低下的代码。换句话说，可扩展性不足可能会使 MVP 受挫，但早期投资过多可能会过快地耗尽稀缺资金来解决一个你尚未（可能永远不会）遇到的问题。过度投资甚至可能导致项目因“价格冲击”而被取消，因此团队可能更倾向于低估它。

确实存在可扩展性需求，只是它们难以察觉

MVP 通常有隐含的可扩展性要求，例如“为了让这个想法成功，我们需要招募 1 万个新客户”。提出正确的问题并参与协作对话通常可以揭示这些需求。这些通常与 MVP 实验的成功标准有关。

例如，考虑商业案例：为了为某个想法谋取资金，业务发起人通常会采用假设。为了使商业案例被认为是“成功”的，需要实现的最小假设代表了系统的最低可扩展性要求。这些假设对于获得商业案例的批准来说可能是乐观的，但仍然需要通过 MVP 实验来进行验证，但它们代表了考虑架构权衡的起点。

有时，商业案例假设的可扩展性在可承受的成本（或商业案例中所述的成本）下是不可能实现的。快速发现这一问题也是有价值的，因为它可以让一个糟糕的想法更快地被取消，以便资金可以被释放出来，用于更有价值的想法。因此，团队应该进行早期实验，以测试这种假设的可扩展性是否可以实现。

可能导致可扩展性问题的权衡

大多数扩展问题都是由系统中的某些关键瓶颈引发的，通常是由访问共享资源引发的。我们遇到的一些更关键的问题（“YMMV”）包括：

• 和房地产一样，位置很重要。理解分布式流程和数据的影响可以帮助团队做出更好的可扩展性决策，而不会过度投资于他们还不需要的功能。

• 非托管共享资源访问，有时可能像序列号生成器一样简单，通常用于从生成订单号到客户号再到产品号的所有事情。共享资源包括许多应用程序使用的其他类型的公共服务，如电子邮件服务、安全令牌生成器、加密服务、缓存服务，甚至是与 AI 组件接口的服务，如 LLMs。与共享资源访问相关的设计挑战包括锁和并发控制。

• 决定使用一个框架或包（特别是开源），它隐藏了影响共享资源的底层决策：正如我们在之前的文章中提到的，框架和包极大地提高了团队的生产力，但框架/包通常具有未知或理解不足的可扩展性瓶颈。在缺乏这些信息的情况下，团队将需要运行实验来发现框架/包在负载增加时会在哪些地方崩溃。

• 将解决潜在可扩展性问题的责任委托给云供应商。云的可扩展性困境：如果你的应用程序从一开始就没有可扩展，那么再多的“云技术”也无法解决这个问题。考虑一下“云”是什么。这是提供虚拟计算环境的一种简单方法。你的应用程序是否能够利用多个环境来进行扩展，取决于开发团队所做的决策。如果设计中存在关键的瓶颈，那么无限可扩展的环境也不会有所帮助。此外，过度依赖云供应商提供的“现成”解决方案，如虚拟机、容器和无服务器函数，可能会给团队一种错觉，即认为他们的 MVA 在未来能够充分扩展，即使它的设计很糟糕。

在更基本的层面上，“迁移到云”是一个架构决策吗？也许吧，但是如果应用程序没有做任何更改来利用云的一些独特的特性，并且如果你的决定没有解决一些架构问题，那么它就不是“迁移到云”；它只是以一种方便的方式来托管系统。

• 不适当的同步和异步处理策略。有些人将异步通信视为另一种扩展的灵丹妙药，因为它允许工作独立于启动工作的工作任务进行。其原理是，主任务可以在后台工作发生时做其他事情。只要启动任务在某个时候不需要异步任务的结果就可以继续（一个非常简单的例子是将作业发送到打印机或记录事件），异步处理就可以帮助系统扩展。但可能存在一个排序问题。如果启动任务需要得到答案才能继续执行，它最终可能会等待。如果启动任务依赖于许多异步任务，那么它也可能需要以特定顺序组装其结果。异步任务中的延迟很容易使系统变慢。

• 过度使用大语言模型（LLMs）或“无代码”（No Code）应用构建器来开发 MVP。使用 LLMs 或“无代码”应用构建器可以加快 MVP 的构建（即编码）速度。然而，这种方法存在风险。正如 Mirza Masfiqur Rahman 和 Ashish Kundu 在“代码幻觉”（Code Hallucination）中指出的那样，“像大语言模型这样的生成模型被广泛用作代码副驾驶和整个程序生成。然而，它们生成的程序在集成方面通常具有可疑的正确性、真实性和可靠性，因为它们可能不符合用户的需求，提供不正确和/或荒谬的输出，甚至包含语义/语法错误——总体上被称为 LLM 幻觉”。团队是否完全理解他们隐含地做出的权衡，以及这些权衡可能如何影响可扩展性？如果将 MVP 编码任务委托给 LLM 或“无代码”应用构建器，他们的技术技能会随着时间的推移而下降吗？

结论

在你做出可能影响 MVA（最小可行架构）可扩展性的决策时，你应该决定是现在就解决这个问题，还是说可以等下稍后解决。如果将来更改你的可扩展性决策需要工作量“非常”大，那么你应该现在就解决这个问题；否则，否则您应该记录你“足够好”的决策，并注明，以后如果需要，你可以选择不同的可扩展性决策。换言之，你是在有意创建技术债，你可能需要也可能不需要偿还。

扩展一个系统是一个很难解决的问题。对可扩展性投资不足会缩短系统的生命周期，但过度投资可能会因为成本问题而扼杀 MVP（最小可行产品）的商业案例。从可扩展性选项的角度考虑问题是很重要的——只要你能在不改变架构的情况下稍后解决这一问题，你就可以推迟决策，否则你就需要现在就解决。

架构实验是解决过度构建可扩展性的一个好解药。如果你能确信可以在需要时以可预测的成本调整系统以增加可扩展性，那么你不必在需要它之前构建所需的可扩展性水平。如果你的实验表明，可扩展性决策可以推迟到以后的某个时间，那么现在投资于可扩展性既不必要也不明智。

原文链接：

https://www.infoq.com/articles/mvp-dilemma/