构建可扩展的最小可行产品

想看更多产品干货文章？推荐极客时间专栏《邱岳的产品手记》，一次订阅、永久阅读。即日起，戳此订阅立享以下两大福利：

福利一：原价 ¥58/45 期，极客时间新用户注册立减 ¥30

福利二：每邀请一位好友购买，你可获得18 元现金返现，多邀多得，上不封顶，随时提现（提现流程：极客时间服务号- 我的- 现金奖励提现）

在开发最小可行产品（MVP）时应该考虑可扩展性。从技术上讲，MVP 需要可扩展性，而你需要有一个计划，当许多用户都对你的MVP 感兴趣时，如何实现快速扩展，并取得成功。Duindam 认为，在开发MVP 时，了解可能存在的性能瓶颈，并使用常识，可以让你取得很大的收获。

Erik Duindam 是 Unboxd 的首席技术官，他在敏捷与软件架构研讨会 2016（ASAS）上作了有关“扩展团队和技术”的演讲。InfoQ 正以 Q&A、综述和文章的形式对这次活动进行追踪报道。

在 Medium 文章“我如何在 5 天之内在一台价值 100 美元的服务器上构建一个有 50 万用户的 App ”中，Duindam 说明了开发 MVP 时可扩展性的重要性：

在创业公司的世界里，似乎存在一个广泛的共识，那就是，应该构建 MVP（最小可行产品），而不必太关注技术上的可扩展性。（……）你不应该在产品的技术可扩展性上浪费时间和金钱。你所要的关心的是，测试你的假设，进行市场验证，并吸引注意。可扩展性是后续需要关注的问题。遗憾的是，这种颇有几分盲目性的做法已经导致了一些严重的失败。

为了开发出可扩展的 MVP，Duindam 对编程语言的选择提供了一些建议：

就可扩展性而言，选择一门精简且易于掌握的语言非常重要，除非你有许多钱可以花在服务器上。更重要的是，选择的语言要有许多实用的库，因为你希望快速构建自己的 MVP。NodeJS、Scala 和 Go 就很好地满足了这两个要求。它们提供了许多不错的工具，并且有很好的性能。

Duindam 在 ASAS 大会上演讲时指出，MVP 必须以这样一种可以应对高负载的方式开发。你必须考虑，如果你的 MVP 有 100 万用户会出现什么情况，要核实一下，它是否能够应对那种情况。设法搞清楚瓶颈在哪，并运用常见的技术编写良好的代码，预防技术上的问题。

Duindam 举了一个例子，说明如何在获取数据时通过添加 Mongoose 的 lean() 函数减少 90% 的服务器负载。Duindam 表示，如果代码写的不好，那么你就需要不断地增加服务器，那可不是一个可行的方案。

InfoQ 采访了 Erik Duindam，内容涉及为什么最小可行产品必须具备技术上的可扩展性，以及如何设计和构建可扩展的 MVP。我们还请他就开发可扩展的 MVP 选择什么工具提供了建议。

InfoQ：为什么最小可行产品（MVP）必须具备技术上的可扩展性？

Erik Duindam:MVP 的目的是通过最小的工作量收集验证学习信息。实际上，这意味着，你不应该花费时间开发对学习过程没有直接贡献的功能或技术。因此，把时间花费在漂亮的代码、架构和可扩展性上通常是没有意义的。相信你的产品会像 SpaceX 的火箭一样升空——因此需要内置许多可扩展技术——就和相信 SpaceX 的每个火箭确实都会升空一样合理。在理想情况下是这样，但在现实生活中，情况可能并非如此（问 Zuck）。但是，如果不用多花时间就可以让它有点扩展性会怎么样？如果你的火箭确实升空了会怎么样？

在许多关于精益创业公司和 MVP 的例子里都有这样的场景，你创建一个登录页面试图向客户卖东西，但并不真卖。你不会真地构建一个具有订单执行、支付和发货功能的系统，你只是要收集人们的 Email 地址，从而进行业务和市场验证。这个例子很容易理解，但对于许多 MVP 而言并不适用。有时候，你实际上就是要测试技术或产品的第一个版本。有时候，你实际上就是要让用户试用一个可以工作的产品。你至少应该考虑下产品的 MVP 版本用于生产场景的可能性。你应该考虑下，你可能有一群用户是受媒体报导或者其他预期或非预期的东西所吸引。你应该为成功着想。

InfoQ：您是如何设计和构建一个可扩展的 MVP 的？

Duindam：最重要的是，确保开发人员了解 MVP“成功”的含义。你和你的开发人员必须预先了解可能的性能瓶颈以及在用户量快速增长的情况下如何应对。因此，我会首先制定一个小计划。

其次，有许多最难的可扩展问题都源于懒惰和糟糕的设计。许多开发人员从数据库获取数据的方式就是一个很好的例子。许多开发人员喜欢在代码中使用某种形式的数据库抽象，并且总是坚持这种做法。例如，他们宁愿在一个循环中执行数据库查询，也不愿意真正地编写一个快速的 JOIN 查询，因为据称那样的代码看上去更简洁，或者更面向对象，或者更简单，因为它是“Rails 的方式”。根据我的经验，这很大程度上是源于开发人员的不安全感——不知道以不同的方式使用数据库抽象工具也是完全可以的。因此，仅仅是认识到编码方式对性能的影响就已经可以为你避免大部分麻烦了。使用常识会让你取得很大的收获。

InfoQ：对于开发可扩展的 MVP，您建议使用什么工具？

Duindam：就个人而言，我并不喜欢推荐具体的技术或工具，因为许多包都解决了类似的问题，只是方式略有不同。对于编程语言、数据库、应用场景等等，你应该自己研究，找出最合适的工具。找一些适合你的语言或应用场景的性能测试工具并不难。尽管如此，关于这一点，我还是要做些更一般化的说明。

重要的是要知道，你可以将任何语言、框架和数据库系统扩展到一个合理的用户数量。在荷兰，只有少数的科技公司可能会为了达到扩展的目的而需要非常特殊的编程语言或数据库系统。其他的公司规模都不够大，这还不成为问题。像 Telegraaf.nl 或 NU.nl 这样的网站可以基于任意技术构建，只要前端有一个类似 Varnish 这样的反向代理。像 bol.com 这样的网站可以采用微服务，将前端店面和后端处理过程分开。使用任何语言或平台都可以达成这些目标。因此，语言、工具以及库的选择依据应该是你找到程序员并向他们开放源代码的能力，而不是可扩展性。

查看英文原文： Building a Scalable Minimum Viable Product