通向高可扩展性之路（WhatsApp篇）---- 脸书花了190亿买来的WhatsApp的架构

原文连接：http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html

原文写于2014年2月26日，如下是译文：

 

在雅虎曾经用C++写太高性能信息通道的Rick Reed并非高扩展性架构世界中的新手。跟他一块儿的创业者们都是有丰富可扩展系统经验的前雅虎人。因此WhatsApp在可扩展性上的实力很是强。并且因为他们的目标就是让世界上每一台智能机（ 几年内总数将达到50亿）都装上WhatsApp，这一经验对他们来讲相当重要。

在进入正题以前，咱们先来花点时间看看：为何WhatsApp对于脸书来讲值190个亿？

做为一个编程人员，若是你问我WhatsApp是否是值这么多钱，我确定回答不是！它只是在网络上传送一些东西。可是我也是一个认为咱们不须要博客平台的人，由于远程登陆你的服务器，用vi改改index.html文基恩，而后在HTML里写你的博文，能有多难呢？后来我认识到作这些事情的代码有多愚蠢不是关键，关键是让用户喜欢使用你的产品。你不能买到人们的喜好。

那是什么让WhatsApp这么值钱呢？技术？忽视那些说他们能够在一周内用PHP写出一个WhatsApp来的人们。这是不可能的。WhatsApp里面确实用到了一些比较厉害的技术。可是若是脸书想的话，绝对有这个实力来实现一个WhatsApp。

让咱们来看一看它的一些功能。咱们知道WhatsApp是一个没有广告、花招和游戏，可是有来自全世界的忠实用户的产品。它在一个短信收费严重的世界里提供免费的短信服务。做为一个美国人，最让我惊讶的是有那么多真实的用户用WhatsApp来与家人朋友联系。当你登录WhatsApp的时候，极可能发现你认识的不少人已经在使用它了。因为每一个人都有一个手机，这也减小了有些人不使用社交网络的问题。WhatsApp积极的在不一样的手机平台上发布，使得每一个你认识的人均可以使用它，并且它just works。“just works”是一个经常使用的短语。它表明全部的含义（共享位置、视频、音频、图片、按住讲话、语音短信和照片、读收据、群聊、经过WIFI发送信息、以及不论收件人在不在线这一切均可以完成）。它能够支持各类语音，使用你的手机号码做为身份认证，你的手机联系人列表就是你的社交图。这一些都极其简单。不须要邮件认证、用户名和密码、也不须要信用卡号码。因此它just works。

这些都很厉害，可是也不知190亿美金。其余产品也能够作到这些功能。

一个缘由多是谷歌也想要买它，由于它是一个威胁，由于多一个用户能够赚上99美分。而脸书则是很是急切的须要它，为了用户手机中的联系人列表，也为了一些其余数据（即便WhatsApp什么也不存）。

这一切都是为了4亿5千万活跃用户，而且天天增长一百万用户，潜在用户数量达到10亿。脸书须要WhatsApp来得到它的下一个十亿用户。这确定是一部分缘由。何况一个用户40美金也不是很离谱，尤为是190亿里的大头是用股票来支付的。脸书收购Instagram时一个用户的价格是30美金。一个推特用户则价值110美金。

Benedict Evans曾经估算过，移动是一个超过一万亿美金的生意。WhatsApp颠覆的是这个生意里短信那一部分。全球短信系统年收入超过1千亿，一天发送200亿条短信，而WhatsApp一天发送180亿条。现在的大趋势是从PC端转到更广泛的智能机端，这个机遇的规模要比如今脸书所在的市场大得多。

可是脸书保证没有广告和干扰，那它能得到什么呢？

这里有些颇有趣的移动端商业化的例子。WhatsApp被用来建立一些项目组的群聊，还有一些风投会用它来进行交易流程的对话。

Instagram在科威特用来卖羊。

微信，一个WhatsApp的竞争者，在一月开通了出租车叫车服务。第一个月就叫了2千1百万辆次出租车。

电子商务的将来看来会经过一些移动短信app来实现，但这仅仅只局限于电子商务吗？

其实不仅有商业会使用WhatsApp来替代之前在电脑或网页应用。西班牙的警察使用WhatsApp来抓捕罪犯。意大利的人们用它来组织篮球赛。

商业和其余应用开始向移动端转移有很充足的理由。每一个人都有手机，并且这些短信应用很强大、免费、用起来成本很低。你再也不须要电脑或者网页应用来作这些事了。不少功能能够再一个短信app上实现。

因此短信对谷歌和脸书来讲是一个威胁。电脑正在不流行，web也在不流行。短信加移动端构建了绕过传统渠道的一个完整生态系统。短信取代搜索成了移动端的中心，改变了事物被发现的途径，也决定了什么样的应用能在将来胜出。

脸书想不想要进入这个市场？

随着转向移动端，咱们能够看到脸书的去门户化。脸书的电脑网页界面是门户风格的，提供了全部后端所能提供的功能的入口。它很大、很复杂、很容易出问题。谁真的喜欢脸书的UI？

当脸书像移动端倾斜时，他们也尝试过门户风格，但行不通。因此他们采用了一系列更小更专一的不一样目的的app。移动为先！你在这么小的屏幕上只能作有限的事情。在移动端更容易找到一个特定的app，而不是在一个复杂的门户式应用的重重菜单中找到你想要的东西。

可是脸书走的更远。他们不只仅提供各类app，他们还提供多个互相竞争的功能相似的app，而这些app可能都不使用相同的后端基础设施。好比Messenger和WhatsApp，Instagram和脸书的照片app。Paper是另外一个脸书的界面，只提供不多的功能，可是在这些功能上能作的很好。

康威定律在这里也成立。它的大意是“设计系统的大型机构会受到自身限制而作出和自身的通讯构架类似的设计”。有一个大块头的后端基础架构，咱们就会有一个城堡同样的前端门户设计。转向移动端把大公司从这种思路中解放了出来。若是应用能够只提供一部分脸书基础架构的功能，那应用就能够彻底不依赖与脸书的基础架构。若是它们不须要脸书的基础架构，那它们也不须要有脸书来建立。那这个时候脸书仍是脸书吗？

脸书的CEO Mark Zuckerberg有本身的理解。在移动端世界大会上他说脸书收购WhatsApp是与Internet.org的愿景高度相关的：

咱们的宗旨是发展一系列免费的基础互联网服务 -- “一个互联网的911”。这些服务可使像脸书同样的社交网络服务、一个短信服务、搜索、或者像天气一类的服务。 向用户提供这些免费服务就像是一种容易上瘾的药  -- 可以承担的起数据服务和手机的用户就不会想要花钱来得到这些服务。这会使得他们以为本身很重要，从而花钱购买其它相似的服务。 -- 或者咱们但愿如此。

这是一个长期的目标，须要有巨大的值钱的股票才能玩得起。

那咱们有结论了吗？不见得。这毕竟是一大笔钱，而直接的好处却不是很明显，尽管长期目标的解释有必定的道理。咱们仍然实在移动的早期。没人知道将来是什么样子的，因此为了让将来不会像过去那样是须要付出代价的。脸书正在这么作。

这个话题就到此为止了。让咱们来看看32个工程师是怎么支持4亿5千万活跃用户的。

 

信息来源：

预警：咱们并不知道不少关于WhatsApp的总体架构。只有从不少来源获得的一星半点信息。Rick Reed的演讲是关于如何用Erlang来让每台服务器能够支持2百万链接的优化过程，很是有趣，可是不是一个关于总体架构的演讲。咱们的来源有：

• Rick Reed 2012 的演讲 Scaling to Millions of Simultaneous Connections 
• Rick Reed 的Erlang Factory interview
• An interview with Eugene Fooksmam from WhatsApp
• DLD14 - What's up WhatsApp? (Jan Koum, David Rowan)
• yowsup是一个WhatsApp的API的开源版。由于DMCA的关闭，这个代码库已经没法下载了。可是他们确实记录了一些WhatsApp的内部工做。好比，全部事情都会搞多样化。
• 一些在相关文献中提到的来源。

 

数据：

这些数据大部分来自现有系统，而不是演讲时的那个系统。那个演讲会包括更多的数据存储的改动、消息、大集群和更多的BEAM/OTP的补丁。

• 4亿5千万活跃用户，比任何公司更快的达到了这一数字
• 32个工程师，每一个人支持1千4百万活跃用户
• 七个平台上天天500亿条信息（收+发）
• 天天超过1百万新增用户
• 广告投入为0
• Sequoia Capital投了6千万；回报是34亿
• 脸书35%的现金用在了这单交易中
• 数百个节点
• 大于8000个核
• 数百TB的RAM
• 每秒超过7千万条Erlang消息
• 2011年WhatsApp在单一服务器上有1百万tcp会话链接，还能有内存和CPU的剩余；在2012年能够有2百万tcp链接；2013年WhatsApp在推特上公告，12月31号产生了一个新纪录：收了70亿短信+发了110亿短信=总的一天180亿条短信！2013年快乐！！！

平台：

后端：

• Erlang
• FreeBSD
• Yaws， lighttpd
• PHP
• BEAM的特制补丁（BEAM就像JAVA的JVM，可是是Erlang的）
• 特制XMPP
• 可能在Softlayer中运行

前端：

• 七个客户端平台：iPhone、安卓、黑莓、诺基亚塞班S60、诺基亚S40、Windows Phone、？
• SQLite

硬件：

标准的涉及用户的服务器：

• 两个Westmere Hex-core（24个逻辑CPU）
• 100GB RAM， SSD；
• 双NIC（一个公有链接用户的网络，一个私有与后端相连的网络）

产品：

• 关注消息。链接全球的人们，无论他们在哪里，也不须要他们花不少钱。创立人Jan Koum还记得在1992年时要和全世界不一样地方的家人们保持联系有多难。
• 私密性。这与Jan Koum在乌克兰长大有关，那里没什么东西是保密的。消息不会被存在服务器上；聊天记录也不被保存；目标是对用户了解的越少越好；不知道用户的姓名和性别；聊天记录只在用户的手机上。

概述：

1. WhatsApp的服务器几乎彻底基于Erlang：

• 后端短息路由系统是由Erlang实现的
• 一个巨大的成就是只有不多的服务器就管理了这么多的活跃用户。WhatsApp团队一致认为这很大程度上市Erlang的功劳。
• 有趣的是2009年时Facebook Chat也是用Erlang写的，可是后来他们放弃了，由于很难找到合适的程序员。

2. WhatsApp的服务器从ejabberd启动：

• Ejabberd是一个著名的开源Jabber 服务器的Erlang版
• 一开始选它是由于它是开源的，代码通过不少程序员审核，容易入手，而且从长远来看Erlang对大型通讯系统十分合适
• 接下来的几年花在了重写和改变ejabberd的部分代码上，包括从XMPP换到一个内部开发的协议、修改代码结构、从新设计一些核心组件、以及对Erlang VM作出了许多重要改变来提升服务器性能

3. 一天处理5百亿条消息的重点在于有一个可靠、可用的系统。赚钱是之后的事情，还有很远的路要走。

4. 一个主要的衡量一个系统是否健康的标准就是消息队列的长度。一个服务器上全部进程的消息队列长度都被实时监控着，一旦超过某一个预设的值就会发出警报。一旦一个或多个进程发出警报，那就说明这是下一个须要解决的瓶颈。

5. 发送多媒体消息时，图片、音频或视频会被上传到一个HTTP服务器，而后这个内容的链接以及一个用Base64编码的预显示内容（若是有的话）会被发送出去。

6. 有些代码天天都会被改变。常常是一天几回，虽然一般会避开高峰时刻。Erlang有助于积极地上线修复和新的功能。热加载意味着更新能够在不用重启或者转移负荷的状况下启用。错误常常很快就能经过热加载来纠正。系统设计地比较松耦合，使得递增地推出新的东西变得很容易的。

7. WhatsApp用了什么协议？SSL通讯管道通向WhatsApp的服务器池。全部的消息都在服务器的队列上，直到客户端下一次链接而后取走消息。成功获取一条消息的状态会被送回WhatsApp的服务器，而后被转发个发送消息的那我的（他会看到这条消息旁边出现了一个勾）。一旦客户端接收的这些消息，它们就会在服务器的内存中被删除。

8. WhatsApp内部的注册过程是怎么实现的？WhatsApp曾经基于手机的IMEI号码建立一个用户名密码。可是最近修改了这一机制。WhatsApp的客户端如今经过一个通用API发送一个独特的5位PIN。WhatsApp而后会发送一条短信到这个手机号码（这意味着WhatsApp的用户不在须要使用同一部手机了）。根据这个PIN，客户端会请求一个独特的键。这个键就被当作将来全部请求的密码。（这个永久的键被存在手机中。）这也意味着注册一台新的设备会使得老设备上的键失效。

9. 安卓平台上使用了谷歌推送服务。

10. 安卓平台上有更多的用户。安卓开发也更友好一些。开发者能够开发一个功能的初始版，而后一个晚上就能够把它推送到亿万用户的机器上。若是有什么问题就能够立刻修复。在iOS上就不行。

每台服务器超过2百万链接：

1. 巨大的用户增加，这是一个幸福的烦恼，但这也意味着要花不少钱买更多的设备以及增长管理这些设备的复杂程度。

2. 须要为负荷的激增作好计划。例如西班牙或者墨西哥有足球比赛或者地震的时候。这些一般在原本就是高峰的时候发生，因此须要有足够的空闲带宽来处理高峰+激增。一次最近的足球比赛在本来的高峰期基础上又产生了35%的发送增量。

3. 本来的服务器能够同时处理200个链接：

• 能够推断须要不少的服务器来知足增加须要
• 服务器在忽然到来的负荷面前很脆弱。网络故障和其余问题会出现。须要解耦各个部件使它们在高峰期不那么脆弱
• 目标是一台服务器1百万个链接。这是在他们能够实现20万链接时定下的极有野心的目标。还要让服务器有多余的容量来处理世界性活动、硬件故障以及其它各类问题意味着要有足够的弹性来处理高负荷和故障。

用来增长可扩展性的工具和技术：

1. 系统主动汇报工具（wsar）：

• 记录一个系统的各类数据，包括OS数据、硬件数据、BEAM数据。它被设计成能够很容易从其余系统插入测量数据的模式，例如虚拟内存、跟踪CPU使用率、整体使用率、用户时间、系统时间、中断时间、上下文转换、系统调用、陷阱、收/发包、全部进程队列中的消息总数、繁忙端口事件、通信负荷率、输入输出比特数、调度数据、垃圾回收数据、收集到的文字、等等
• 原来每分钟跑一次。随着系统性能提高，须要每秒运行一次，否则有些事件在一分钟的精确度上是发现不了的。如今数据很是精确，能够看到全部部件是如何工做的。

2. CPU中的硬件性能计数器（pmcstat）：

• 能够看到CPU在哪里花了多少比例的时间。能够看到多少时间被用在了仿真器的循环上。在他们的例子上，只有16%的时间用来执行仿真器中的代码上了。也就是说即便他们一点也不运行Erlang代码，也就只能节省16%的时间。意味着他们应该在其余地方想办法提高系统的性能。

3. dtrace、内核锁计数、fprof：

• Dtrace主要用于debug，而不是性能
• 在FreeBSD上给BEAM打补丁来得到CPU时间戳
• 写了一些脚本，把全部进程的信息汇总到一个地方来显示时间都花在了哪些步骤上
• 最大的收获是在编译仿真器的时候开启锁计数

4. 一些问题：

• 早期看到不少时间或在垃圾回收上，这个已经下降了
• 看到一些网络堆栈上的问题，也被解决了
• 最大的问题在于仿真器中的锁竞争，能够从锁计数的输出中发现

5. 测量：

• 合成负荷，那些从你本身的测试脚本中产生的负荷，在用户规模很是大的时候，对于用户会接触到的系统的测试做用颇有限：
  • 对于简单的接口颇有用，好比一个用户表格，尽快的产生插入和读取
  • 若是要测试一台服务器支持1百万个链接，须要让30台机器打开足够的IP端口，才能产生足够的链接。对于2百万链接就须要60台机器。这么大的规模就很难测试。
  • 产品线上能够看到的负荷的类型也很难产生。能够假设一个正常的负荷是什么类型的，可是其实由于社交活动、世界性的活动、在不一样的平台上用户的行为不一样、不一样的国家，这些因素都会致使负荷的类型变化很大
• Tee‘d负荷：
  • 把正常的产品线上的负荷复制一部分到一个分离的系统
  • 有效地把反作用限制住了。咱们不但愿复制负荷的同时改变一个用户的永久状态或者致使发送重复的信息给用户
  • Erlang支持热加载，因此在满负荷下，若是有一个新想法，能够在程序运行的同时编译并加载这个变化，而且立刻看到这个变化时变好了仍是变坏了
  • 增长一些旋钮来动态调节产品线负荷，并观察性能会如何收到影响。能够一边输出CPU使用率、VM使用率、监听队列溢出等数据，一边调节旋钮看整个系统如何反应
• 真实产品线负荷：
  • 终极测试，同时输入和输出。
  • 在DNS中重复写入一个服务器的信息，因此它会获得两倍或三倍于正常数值的负荷。制造一些TTL的问题来模拟客户端不适用DNS规定的TTL或者出现了延时，因此不能很快地针对负荷过载进行处理。
  • IPFW。把负载从一台服务器转移到另外一台，这样可使一台机器正好有那么多客户端的链接。可是一个bug可能引发内核恐慌，因此不是很行的通。

6. 结果：

• 从一台服务器有20万个并发链接开始
• 第一个瓶颈是42万5千个链接。系统一直处于竞争状态，真正的活没人干了。测量调度器数值来观察多少有用的工做正在执行、或睡眠、或循环。发如今负荷下，它一直试图获取睡眠锁，因此整个系统CPU使用率只有35%-45%，可是调度器有98%的使用率
• 第一轮修复就达到了1百万的链接：
  • VM利用率在76%。CPU在73%。BEAM仿真器的利用率为45%，与用户进程比例很接近。这是一个好事，由于仿真器就是以用户权限运行的。
  • 一般CPU利用率并非一个很好地衡量一个系统有多忙的数据，由于调度器也是用CPU
• 一个月后，赶上了2百万链接的瓶颈
  • BEAM的利用率在80%，很接近FreeBSD开始换页的极限。CPU也差很少。调度器开始竞争状态，不过总的仍是运行的比较稳定。
• 彷佛不太须要继续优化Erlang代码了：
  • 原来一个链接有两个Erlang进程，把数量降到了1个
  • 对计时器作了一样的事情
• 最高峰时每台服务器有2百80万链接：
  • 每秒57万1千个包，超过20万条消息
  • 作了一些内存优化，把VM负荷降到了70%
• 试过3百万链接，可是失败了
  • 当系统出问题时，发现了很长的消息队列，无论是一个消息队列仍是消息队列的总和
  • 把每一个进程的消息队列数据加到了BEAM的管理界面中，显示多少消息被接收和发送，以多快的速度
  • 每十秒钟采样一次，能够看到一个进程的消息队列中有60万消息，每秒处理4万条消息须要15秒。算上期间接收的新消息，总的消化时间须要41秒。

7. 发现：

• Erlang + BEAM + 他们的修复 -- 拥有很牛逼的SMP可扩展性。近乎线性的扩展性。很是厉害。一个24通道的机器运行这套系统处理产品线的负荷会占用85%的CPU，它能够一直运行下去而不出什么问题：
  • 这是对Erlang编程模型的一个证实
  • 一个服务器运行的时间越长，就会有越多长时间的链接，这些链接几乎没有负荷，因此它就能够接受更多的链接
• 竞争是最大的问题：
  • 他们的Erlang代码里有一些针对BEAM竞争问题的修复
  • 一些BEAM的补丁
  • 分割负载，这样每一个CPU的负载就小了
  • 当前时间锁。每次一条消息离开一个端口的时候它会更新当前时间。这是一个全部调度器共享的锁，意味着全部的CPU都会用到这个锁。
  • 优化计时器的使用。不使用bif计时器。
  • 检查IO时间表会致使指数增加。建立的VM有一个哈希表，会被重复分配。使用几何分配这个表能够优化性能。
  • 增长一个文件来记录全部你已经打开的端口能够减小端口竞争
  • Mseg分配本来是一个全部分配器之间的竞争。把它的竞争范围所减到每一个调度器的范围。
  • 在接受一个链接的时候有不少端口之间的交互。修改一些选项能够减小昂贵的端口间交换。
  • 当消息队列变大时，垃圾回收会使整个系统不稳定。因此暂停垃圾回收知道信息队列没有那么大时才进行。
• 避免一些常犯的错误：
  • 一个从FreeBSD 9引入FreeBSD 8的TSE时间计数器。这是一个更快的读计数器。能够更快的拿到当前时间，比查询一个芯片要快。
  • 从FreeBSD 9引入igp网络驱动，以解决多个网卡上队列查询的问题
  • 增长文件和网络管道的数量
  • pmcstat显示不少时间花在网络堆栈查询PCB上。因此扩大哈希表的容量能够加快查询速度
• BEAM补丁：
  • 以前提到的工具补丁。增长调度器仪表盘来获取使用率信息、消息队列的数据、睡眠次数、发送速率、消息计数、等等。这些能够经过Erlang代码和procinfo来作，可是在1百万链接时太慢了
  • 数据收集是颇有效的，由于它们能够运行在产品线中
  • 数据有三个不一样时间间隔：一、十、100秒。这样能够观察到不一样的问题。
  • 让锁计数能够在更大的异步线程中工做
  • 增长debug选项来debug锁计数器
• 调试：
  • 设置一个较低的调度器醒来阈值，不然调度器会一直睡眠
  • 优先mseg分配器，而不是malloc
  • 每一个调度器的每一个实例都有一个分配器
  • 把页的值设的比较大。让FreeBSD使用超级页。减小TLB找不到的几率，提高同一个CPU的吞吐量
  • 把BEAM运行在实时优先级上，这样其余例如cron的任务就不会打扰调度，能够防止致使重要用户负荷堆积的小问题
  • 下降空循环次数，因此调度器不会空循环
• Mnesia
  • 优先os：timestamp，而不是erlang：now
  • 不要使用交易，可是远程复制会堆积起来。并行复制表格能够增长吞吐量
• 有不少改变都没有在这里列举出来

教训：

• 优化是一个又黑暗又肮脏的活，只适合巨怪和工程师。当Rick作出这些改变使服务器能够接受2百万链接时，有不少工做要作：写工具、运行测试、引入代码、在技术堆栈的每一层加入仪表盘、调试系统、观察数据、与很底层的细节打交道以及试图理解全部的事情。这就是去除瓶颈，把性能和可扩展性推到极致索要付出的代价。
• 获取你须要的数据。写工具。给工具打补丁。添加旋钮。Ken不停的修改这个系统来获取他们须要的数据，不停地写工具和脚原本管理他们的数据，优化这个系统。作任何须要的事情。
• 测量。去除瓶颈。测试。重复这一过程。这是你该作的。
• Erlang太棒了！Erlang不断证实它可用来写一个多功能的、可靠地、高性能的平台的能力。尽管我我的对这个说法有必定的保留，毕竟它还须要这么多的调试和打补丁。
• 解决有问题的代码就能够获利。
• 如今价值和员工数量正式没有关系了。如今有不少可利用的工具。一个先进的全球通讯基础设施使WhatsApp这样的应用成为可能。若是WhatsApp须要先创建一个网络或造一个手机，这就不可能发生。强大又便宜的硬件和开源软件固然又是一大利器。这些正确的产品在正确的时间正确的地点出如今了正确的购买者面前。
• 关注用户很重要。WhatsApp致力于成为一个简单的消息应用，而不是一个游戏网络，或者一个广告网络，或者一个消失的照片网络。这对他们很重要。这让他们不打广告、在增长新功能的时候保持应用的简单、以及在任何手机上实现“just works”这一理念。
• 因为简单而致使的限制是能够接受的。你的身份与手机号码绑定。因此若是你换了手机号码，你的身份也没了。这个不像电脑。可是这让整个系统在设计上简单了不少。
• 年龄什么也不是。若是2009年的时候WhatsApp的创始人Brian Acton是由于年龄歧视而没有得到推特和脸书工做的话，那真是一种讽刺。
• 开始要简单，而后再变化。一开始服务器端是基于ejabberd。它后来被重写了，可是那只是Erlang方向的第一步。后来Erlang的可扩展性、可靠性和可维护性获得了愈来愈多的应用。
• 保持不多的服务器。一直保持尽量少的服务器数量，同时又保证足够的冗余来处理一些活动引发的短时间陡升的消息量。分析和优化直到它们不起做用，而后部署更多的硬件。
• 有意提供冗余的硬件。这样能够保证用户在节日期间有不间断的服务，而雇员也能够享受假日，不用把整个假日用来修复过载问题。
• 当你收钱时增加就会放缓。当WhatsApp免费时，增加超级快，一天有1万个下载。当收费以后就降低到1千一天。在年末，当有了图片消息以后，他们先是收一个一次性的下载费，后来改为年费。
• 创意来自最奇怪的地方。常常忘记Skype帐号用户名和密码的经历致使了作一个“just work”的应用的热情。