为什么我要选择erlang+go进行服务器架构
Posted Golang语言社区
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了为什么我要选择erlang+go进行服务器架构相关的知识,希望对你有一定的参考价值。
原创文章,转载请注明出处:服务器非业余研究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单服务器取得 ,同时还有内存和CPU剩余。在2012年,。
·
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服务器,它将会被重新转发给原始发送者;一旦客户端成功接收这条消息,它就会在服务器存储中擦除。
结果
开始时每个服务器有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万连接时达到顶峰
571k pkts/sec, >200k dist msgs/sec
做一些内存优化,VM加载下降到70%。
尝试过将连接数增加到300万,但没有成功。
·当系统遇到故障时,查看长消息队列(单个消息队列或消息队列总和)。
·将每个进程的消息队列统计添加到BEAM设备上。包括发送/接收了多少条消息以及发送/接收的速度。
二:RabbitMq
这个相信大家都听说过,世界上最好的企业消息队列系统之一。
三:Web框架
Mochiweb,CowBoy等
四:电信级别的应用
爱立信等电信公司
五:游戏服务器领域的大范围应用
特别是在页游和手游领域,erlang简直如鱼得水,用erlang开发出的千万级流水游戏也是数不胜数
六:数据库
CouchDB,Riak等
七:其他领域的应用
目前据我所知,在银行业务,医疗业务,云业务领域都可以看到erlang活跃的身影.
以上是关于为什么我要选择erlang+go进行服务器架构的主要内容,如果未能解决你的问题,请参考以下文章