为什么我要选择erlang+go进行服务器架构(1)

浏览数：24 / 时间：2015年06月10日

原创文章，转载请注明出处：服务器非业余研究http://blog.csdn.net/erlib 作者Sunface

估计很多同学看到这里都会觉得迷惑，go的大名已经如雷贯耳了，但是erlang？这个东东是神马？难道是编程语言？怎么从来没听说过。

这里请允许我先介绍一下使用Erlang开发的比较有名的应用：

一：whatsapp

只凭32个技术人员，如何应付4.5亿的用户？对于刚刚被Facebook用190亿美元收购的WhatsApp来说，答案是Erlang——一种诞生于上世纪80年代的编程语言，终于在此时走到了聚光灯下。

这个应用把erlang的特性发挥到了极致，利用到了它最好的vm、集群基础设施、数据库mnesia, 消除了非常多的数据Scale、内存池和锁的问题，提到的技术和修正点非常值得我们参考。

虽然大部分的解决方法我们在日常都差不多用过。但是他很系统的整理出来，用在商业系统了，这是个非常大的飞跃。

可以服务4.5亿用户的高可靠架构：

需要注意的是， WhatsApp的整体架构并未公开，这里仅仅是从不同信息源中获取不同的片段。Rick Reed的讲座主要分享了使用Erlang实现单服务器200万连接数，虽然很有价值，但是并不是整个应用架构

这些统计是当下系统的一些数据，更多针对数据存储、消息、meta-clustering以及新加入的BEAM/OTP补丁。

·4.5亿的活跃用户，并且是史上最快达到这个数字的公司

·32个工程师，平均每人支撑1400万活跃用户

·每天收发跨7个平台的500亿消息

·平均每天注册用户过百万

·0广告开销

·800万投资

·数百个节点

·8000+核心

·数百TB内存

·每秒Erlang消息超过7000万

·在2011年，WhatsApp单服务器取得 100万个tcp会话，同时还有内存和CPU剩余。在2012年，tcp会话发展到了200万。

2013年WhatsAppf发表twriter声明70亿消息入站，110亿消息出战，即每天处理180亿消息，伟大的2013！

二百多万的长连接push服务器：

whatsapp数据集mnesia的规模:

生产系统的数据：

每秒的消息数：

发展历程：

1. WhatsApp服务器基本上完全使用Erlang实现

·做后端消息路由的服务器系统使用Erlang实现

·值得炫耀的是，如此庞大数量的活跃用户只使用非常少的服务器来管理，团队一致认为这很大程度上归功于Erlang。

·值得注意的是，Facebook Chat就是在2009年使用Erlang开发，他们弃用Erlang的原因是难以招聘到优秀的程序员。

2. WhatsApp服务器最早从Ejabberd开始

·Ejabberd是个非常出名的开源Jabber服务器，使用Erlang实现。

·最初选用它的原因是开放、广受开发者关注、易于开始以及Erlang在大型通信系统上的长期口碑。

·接下来的许多年一直从事Ejabberd的重写和修改，包括从XMPP转换到内部开发协议、调整代码库以及重设计一些核心组件，对Erlang VM做了大量的修改以获得高性能。

3. 为了应对每天500亿消息，工作重心被放到可靠系统的打造上，货币化对于我们来说还是件遥远的事情。

4. 系统的健康状况主要看队列的长度，每个节点上消息队列的长度都会被一直监控，超过预先设置的临界值则会发出提醒，多个警报发生则标志着系统进入了下一个瓶颈。

5. 通过上传图片、音频、视频到一个HTTP服务器上来发送多媒体消息，然后将链接与Base64编码的缩略图一起添加到内容（如果可用）。

6. 有些代码基本上每天都在变化，通常情况下是一天几次；当然，峰值期间必须避开的。Erlang非常适用于将修改或者是新功能添加到产品，热加载意味着无需重新启动就可以实现修改，错误可以很快的得到解决，同样通过热加载，系统变得更加松耦合，这可以让更新快速的发布。

7. WhatsApp使用了什么样的协议？WhatsApp服务器池使用了SSL Socket，在客户端重新连接对消息进行检索之前，所有消息都会在服务器上排队。消息的成功检索会发回给WhatsApp服务器，它将会被重新转发给原始发送者；一旦客户端成功接收这条消息，它就会在服务器存储中擦除。

8. WhatsApp注册程序的内部工作机制是什么样的？WhasApp依赖电话IMEI号码来建立用户名/密码，这点在最近已经修改。WhatsApp现在会让应用发送一个包含5位数Pin的一般请求，然后给这个电话号码发送一个SMS，这意味着WhatsApp客户端不再受限于某台手机。基于Pin的号码，应用会从WhatsApp请求一个唯一的键，这个键将作为未来的使用密码，这同样意味着在新的设备上注册后会无效原有设备上的键。

结果

开始时每个服务器有20万个并发连接。

第一个瓶颈出现每台服务器42.5万个连接的时候。系统遇到了很多冲突，工作停止了。安装调度器检测有多少有用的任务被停止、睡眠，或回转了。在加载时，它开始遇到睡眠锁，整个系统只用35-45%的CPU利用率，但调度程序的CPU利用率却达到了95%。

第一轮修复使连接数超过100万个。

VM利用率为76%，CPU利用率为73%，BEAM模拟器利用率为45%，与用户百分比很吻合，这是件好事，因为模拟器得和用户一样。

通常CPU利用率并不是好的评估方法，因为可能由于调度程序使用CPU导致系统看起来很忙。

一个月以后解决了瓶颈，每个服务器连接数达到200万个。

BEAM利用率为80%，与FreeBSD开始分页的情况接近。CPU利用率大致相同，有两倍的连接数。调度程序遇到了冲突，但运行得很好。

看来测试可以暂停了，这时开始分析Erlang代码。

最初每个连接有两个Erlang进程，消减为一个。

用计时器完成一些工作。

在每个服务器有280万连接时达到顶峰