@lsmn
2016-10-13T06:32:10.000000Z
字数 2510
阅读 1847
MVP
可扩展
在开发最小可行产品(MVP)时应该考虑可扩展性。从技术上讲,MVP需要可扩展性,而你需要有一个计划,当许多用户都对你的MVP感兴趣时,如何实现快速扩展,并取得成功。Unboxd首席技术官Erik Duindam认为,在开发MVP时,了解可能存在的性能瓶颈,并使用常识,可以让你取得很大的收获。
在开发最小可行产品(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这样的网站可以采用微服务,将前端店面和后端处理过程分开。使用任何语言或平台都可以达成这些目标。因此,语言、工具以及库的选择依据应该是你找到程序员并向他们开放源代码的能力,而不是可扩展性。