Mailbox：六星期实现从零到百万用户及日处理亿条消息
摘要：14个人、6个星期他们坐拥百万用户，服务日承载信息破亿条。而在App发布不到3周，他们将自己以1亿美元的价格卖给了Dropbox。这里是属于Mailbox的扩展传奇！
每个初创公司都梦想一夜之间获得数百万用户，但是很少有公司声称做到了这一点——将基础设施近乎完美的扩展以通往成功之路。
广为流行的移动应用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的博客，你就会发现他们在解释发生事件上做了很多的努力，足够多的细节让用户感到的是安慰而不是迷惑。