每个初创公司都梦想一夜之间获得数百万用户,但是很少有公司声称做到了这一点——将基础设施近乎完美的扩展以通往成功之路。
广为流行的移动应用Mailbox开发者Orchestra面临了每个应用开发者梦想遇见的难题:负载太高,迫使他们不停的扩展,并且要在最短的时间完成扩展。然而在这个扩展的过程中,很少有机构可以在6周内完成从零到百万用户的扩展,并且几乎未遇见任何瓶颈。
近日Mailbox工程主管Sean Beausoleil接受了ReadWrite的采访,就基础设施扩展在Mailbox的实践进行了分享。区别于随处可见的迭代应用,Beausoleil还分享了一些成功的秘诀,比如严格控制基础设施可替代组件的数量,以及该公司的Rservation System(预约系统)。
扩展的规划
记者:Mailbox在6个星期内实现从0到百万用户的支持,你们是否预见到了这个辉煌的胜利?
Beausoleil:我们从开始就有做大型系统的规划,因为电子邮件是个牵扯到庞大数据体积的应用,但是我们并没有预见到现在的规模。早在2012年12月份发布我们视频的时,我们发现收获的远不止所期待的10万浏览;可实际情况是,仅仅4个小时就达到了我们的预期。这个状况说明,Mailbox上大有可为。而从那时起,我们就踏上了不断扩展之路。
图:Mailbox第一周数据
记者:应对如此增长,你是如何规划的?我们相信自Mailbox发布到今天这个规模,是不能离开你们的精心规划,请带我们回忆一下Mailbox背后的基础设施扩展过程。
Beausoleil:我认为在Mailbox扩展到当下的规模主要经历过3个关键阶段:
- 设计,针对规模进行谨慎的扩展,不停的迭代
- 规模模拟,竭尽所能的对项目扩展到大规模后的情景进行模拟
- 对产品负载迅速反应,开发并迅速的赋以实践
鉴于Mailbox处理的是电子邮件,而电子邮件的要求又比较苛刻,我们使用扩展、有效及精准的理念来设计系统。我们的目标就是设计一个扩展系统,让我们可以不断的完善并迭代我们的系统和产品。为了达到这一点,我们构建了一个模块化系统,并对每个组件持续的迭代。
为了发布之前能尽可能的避免错误和瓶颈,我们建立了一个克隆系统以及IMAP协议,用以模拟产品将要面临的负载。这将让我们发现后端的局限性及存在的问题,而这些问题如果在产品发布后去修补将是非常令人头疼的。
当然,我们清楚不可能在第一天就建立一个完美的系统。所以在软件建立后,随着阶段性问题的频繁出现,以及你对这些问题解决方案的理解,设想和约束也在迅速改变,所以你需要不停的学习,并合理的分配时间。而在收到视频所反馈的信息后,我们认识到系统还需要进一步的打磨;其中之一就是需要建立一个Rservation System,用以帮助我们控制系统上的负载。
对于我们来说,用户体验是最重要的。在产品发布后,我们的工程师团队日以继夜的在发现问题并进行修复,目的就是保证越来越多的人可以拥有一个很好的用户体验。这个阶段扩展的非常迅速;而在理解了我们数据和用户需求后,基础设施的各个核心部分要么修改,要么被分解,要么完全的抛弃。
限制技术数量
记者:你是如何为你的基础设施选择组件的?这些技术在to-do App中就以已经使用了吗?
Beausoleil:我们基础设施组件同样是一个迭代和进化的故事。鉴于Mailbox本身就是我们to-do App的迭代,这个技术同样衍生于我们的Orchestra To-Do后端。我们幸很运的得到了许多初创公司不曾拥有的机会——重写整个系统的机会,让整个系统活了起来。
当然Mailbox开发的准备阶段,花去了我们大把的时间去重思原有的组件。举个例子,我记得有一个星期,我们做了一个非常大矩阵,列举了可选择数据的优缺点。这允许我们为系统做最好的选择,之后只需要付诸行动了。
这样就由Orchestra完美衍生了iPhone应用,我们选取了之前为Orachestra To-Do建立的数据分析和用以实时传递消息的网络框架,并对需要完善的地方进行了迭代。我们同样学习了如何去建立一个高效、响应式iOS UI,并将这些运用到前端框架的搭建,这让App运行的更快更流畅。
其中有个一直在坚持的就是限制不同技术的数量,让其保持最低,因为我们不想在应用打造过程中变成20个不同领域的专家。我们只想在3个领域内走的更精,竟可能的专注产品的开发。
记者:Mailbox现在所使用的是云服务,你是否有考虑过在自己的数据中心建立基础设施?或者是随着业务的增长,移动到更专注的数据中心。
Beausoleil:一个专用的数据中心需求大把的资源以及前期兑现。我们只是一个想建立大型后端的小团队,我们没有资源去管理一个专用的数据中心。AWS是一个令人敬佩的合作伙伴,给我们系统扩展及迭代带来了非常大的灵活性。对我们团队来说,这个平台更加的有成本效益及高效,这为我们有限的资源和时间打下了坚实的基础。
未雨绸缪
记者:我们记得产品刚发布时并不是没有问题。有个阶段,信息甚至不能加载,Orchestra将问题推给了“服务器异常问题”。回首一下,这是不是你可以预料的情况?如果您有预期的话,那么是否是一个已知的意外?
Beausoleil:我认为这些都是后见之名。当你去回顾自己所写代码出现的任何问题时,你可能就会认为你完全可以阻止这个问题的发生,并且抓住bug引起的原因。然而这些都是建立在你对这些问题有所理解,或者是理解了这些之前不曾明白的代码路径。然而在你刚开始尝试时,你是不可能写出完美的代码。虽然我们做足了前期准备,但是我也有一些问题是突然出现的。不管你发布任何规模的应用,总有一些失败是必然会出现的,并且需要去做修复。
记者:如果你再重新发布,那么有什么做法会区别之前的地方?你是否发现你堆栈中的3个组件会有表现不如你预期的地方,并且你希望去取代的?
Beausoleil:这些同样是些后见之名。即使发现也是我们现在才了解的。如果事先知道哪个组件需要被置换,哪些可以被修复,那么我们将可以清楚的提升一些地方。但是我们就失去了这个亲身体验建立和扩展系统的机会。最终结果必然是值得关注的,但是这个过程同样很重要。
我们一直在不断的改善,并且尝试让系统给终端用户带来更加的高效和快速体验。我相信这是一个长远的努力,有一些地方仍然需要不断的改进,有一些地方的实现的途径总会走了弯路。
给后学末进的经验之谈
记者:有什么其它的建议给一些想达到Mailbox规模的初创公司?
Beausolei:迭代,迭代,迭代。不管你现在的状况是什么样,它都可以更好。这里需要做的就是一直的关注它,让它变的更好。随着构思设想不断变化,掌握更多的数据,你的产品的整体框架设计将更加合理、系统的扩展性将更强。
关于细节问题。注重细节,但是别让他们妨碍执行的速度。实现这一点需要很多艰苦的努力,但是每一份努力都是有价值的。
采访中学到的知识
1. 对产品发布后的信息提前进行收集。预热视频可以让用户对产品产生兴趣,同时也可以让你初窥产品发布后的效果,并得到反馈信息,从而提前做出准备。
2. 拥有一些独一无二的特性。有特别之处才可以吸引用户,将创新之处列出清单,并逐个实现。
3. 了解产品背景。比如电子邮件业务非常对资源的需求就很高,并且对产品要求苛刻,所以尽快的扩展。
4. 给产品设定目标。Mailbox初始只针对Gmail以及iPhone,清晰狭窄的目标可以让你在产品设计上投入更多精力,做出更针对性的项目。
5. 修改和迭代。他们有一个非常好的用户体验,因为初期设计就是一个模块化系统,这样就可以根据需求对不同的组件进行迭代。
6. 大规模下的模拟。建立模拟系统用以发现问题,这些测试解决了许多项目在运行过程中难以解决的问题,而这个重要的步骤一般被许多初创公司所跳过。
7. 将技术的数量限制到最小。因为精力是有限的,谁都不可能成为许多领域的专家,专注自己的产品开发才是王道。
8. 关注用户行为。核心基础设施的调整、分解或者删除宗旨在于适应用户的使用模式。
9. 通过Rservation System限制新用户的访问速度。早期Mailbox的Rservation System比产品更加出名,有些类似于“饥饿营销”;不仅刺激了用户,还以一种可控制模式有效的引导负载。这里的关键在于用户体验,而不是吸引新用户。
10. 疯狂的投入。开发者不断的修复故障并完善系统,在早期的开发中应该着重对待,这也是项目整个周期最高效的一个阶段。
11. 应用不可避免会发生故障并且进行修复。任何测试都是有条件的,许多未知的问题在特定的环境下就会爆发出来。迭代,不停的迭代,你将更加了解你的系统、数据和用户行为。
12. 如果你现存的技术、堆栈不再适合当下的环境,果断使用可替代方案去替换。花时间去做新的技术选择,然后在这些技术上下功夫。
13. 云具有成本效益和高效两大特性,云是快速和有限资源构建应用的最佳搭档。
14. 过程的重要性。经历整个产品周期,这是团队和产品磨合的重要组成部分。可以的话,切勿拔苗助长。
14. 择木而栖。在Mailbox产品发布的一个月后就被Dropbox收购,原因是Dropbox可以帮助他们增长的更快、更大。
15. 良好的沟通。如果你关注Mailbox的博客,你就会发现他们在解释发生事件上做了很多的努力,足够多的细节让用户感到的是安慰而不是迷惑。 (编译/仲浩 审校/王旭东)
译文相关链接:
How Mailbox Scaled To One Million Users In Six Weeks
Scaling Mailbox - From 0 To One Million Users In 6 Weeks And 100 Million Messages Per Day