为何我要选择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单服务器取得 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万链接时达到顶峰

571k pkts/sec, >200k dist msgs/sec

作一些内存优化，VM加载降低到70%。

尝试过将链接数增长到300万，但没有成功。

·当系统遇到故障时，查看长消息队列（单个消息队列或消息队列总和）。

·将每一个进程的消息队列统计添加到BEAM设备上。包括发送/接收了多少条消息以及发送/接收的速度。

二：RabbitMq

    这个相信你们都据说过，世界上最好的企业消息队列系统之一。

三：Web框架

    Mochiweb,CowBoy等

四：电信级别的应用

    爱立信等电信公司

五：游戏服务器领域的大范围应用

    特别是在页游和手游领域，erlang简直如鱼得水，用erlang开发出的千万级流水游戏也是数不胜数

六：数据库

    CouchDB,Riak等

七：其余领域的应用

    目前据我所知，在银行业务，医疗业务，云业务领域均可以看到erlang活跃的身影.

为何我要选择Erlang呢？

      1、erlang特别适合中小团队创业：

       erlang有异常成熟、通过电信级别大规模验证的OTP应用库，只须要很简单的代码就能创建起异常稳定、容错性强、扩展性强、高并发的服务器框架，这也是erlang最宝贵的核心价值所在。

      2、erlang是天生的并发语言：

           erlang的并发特性是语言级别的，从开发伊始就采用了CSP并发模式, 以进程为单位，进程间没有共享内存，变量不可变的实现方式保证了无锁的并发模型，所以也是异常高效的，换句话说：你只要像日常同样写代码就能并发，彻底不用操心任何底层实现，你的代码能完美的并行运行在多核服务器上，若是你能写出漂亮的并发级别的算法和代码(尽可能少的顺序代码)，那在32核机器上就能跑出32倍性能！！！！ Go 语言的并发模型也是取经于Erlang,可是我认为Erlang的并发模型更优秀，由于进程间彻底没有共享内存，彻底无锁。

      3、再介绍下我当初的业务需求：

         一款多人在线游戏,一个玩家走一步都要把消息广播给同屏的玩家,玩家聊天,战斗更涉及到大量的消息广播;如何应对?再有一个及其普通却不太容易搞定的的需求:在线玩家列表怎么实现?是啊,你是否是在想用哪一种锁合适?提到的两个场景的关键词是:高并发,大量广播;可能你还会想到"锁".

        我尝试过在.net下使用完成端口+TPL库+protocol buffer来完成上面的功能,可是并无经过测试的检验,测试模型是聊天.在收发消息方面,客户端和服务器一对一的收发压力不大,可是一旦开启广播,压力一下就上去了.对象的频繁建立会致使垃圾回收,而垃圾回收会致使CPU和内存都飘忽不定,中间加入对象池会获得必定缓解,可是不能完全解决问题,而后想到的就是人为干预垃圾回收,判断标准是什么呢?那就是用PerformanceCounter吧,结果发现PerformanceCounter一次调用分配的内存至关大!最后一版的结果是:聊天室模型,一人说话广播给全部人,300人在线可以稳定,人数一多就开始不淡定了.这些都是通过量化分析得出的结果,使用的工具是Visual Studio2010中的Performace Profile工具.

       须要解决的第二个问题就是并发加锁,最简单的测试模型就是在线玩家列表.这个问题一样困扰了我好久,尝试各类锁,仍是在抛异常,要么就是性能的降低,问题此起彼伏.后续还要解决TCP通讯的数据格式,以及粘包等问题......

       项目时间紧张,存在的风险不少,要尽快把技术方案肯定下来而后去推动别的事情;可是可供选择的方案有C++和Erlang.坦白讲我和团队的基础若是使用C++方案,必定能搞出来,可是排错和性能优化将是一个巨大的挑战.那么Erlang呢?从开篇引用的那段文字看,好像这就是我须要的,简单了解了一下语法,仍是很惊喜,因为以前对F#有过接触,一下感受很亲切.并且我特别关注到:

     优势：

      1.面向并发,有成熟并且久经考验的框架可供使用,网络部分已经通过了良好封装

      2.内存缓存解决方案进程字典,前者的读写速度是50NS－100Ns级别的

      3.对二进制数据解析的语法是直观,简单,强大(游戏中有大量的二进制数据要处理

      4.没有共享内存! 没有锁!(咱们在代码中没有过显示使用锁)

     缺点

       1.从一种语言过渡到另外一种语言,会有各类不爽:

       2.控制逻辑简单只有if 和 case ,并且有if没有else,没有continue break goto

       3.包括kernel库和standlib库在内,不少函数和变量的命名和传统语言不同

       所以咱们就决定了采用erlang来从新写一套全新的架构，事实证实当初的决定是无比正确的，一个极少须要重启、能热更、稳定的游戏服务器实在是过重要了，并且开发过程和维护是如此的快速和轻松，咱们的团队一致认为：历来没有想过开发会是这么一件愉快的事情！

既然Erlang已经被我“吹”的快飞起来了，为何还要使用Go？

   鉴于Go语言已经妇孺皆知了，我也就不介绍了，大概说说我本身的状况，我这人没啥其余兴趣爱好，业余时间绝大部分都花费在所谓的“程序员要不停的学习才不会落伍”上，所以在11年的时候，知道了go，断断续续学习了一年后，Go1.1版本出来后，发现改进很大，就开始认真研究并常年混迹在google-group及国外大牛的博客世界中，自我感受还能够。固然我绝对不是Go的“朝圣者”,也发现Go确实不是很是完美，具体能够参见“为何我要放弃Go“，此文做者的观点我虽然不敢彻底苟同，可是有些观点仍是赞同的，好比说不少Go爱好者是很是护短的，若是你敢说什么“坏话”，就等着被查水表吧 ；）。

     因为Erlang和Go都是很是棒的语言，这里就出现一个问题：二选其一仍是物尽其用？通过深思熟虑后，我和团队选择了后者。首先，erlang的OTP写服务器并发框架很是之简单、稳定且高性能，erlang的Mnesia数据库也是很轻量：速度很快，分布式简单，使用起来也很原生态(是Erlang标准库支持的），全部的这些都能把程序员从繁琐的工做中解放出来，可是，erlang也有个挺重要的问题(在不一样业务场景中此问题也许很突出，也可能彻底可有可无，至少85%的状况下不算一个问题)：它是虚拟机语言，对于顺序代码的执行速度只有C的七分之一，虽然能够利用多核的优点，可是在大型mmorpg中，消息密集时，CPU的瓶颈仍是挺明显的，会影响玩家顺畅的体验感受(ARPG)。

    所以我就想若是逻辑这部分用Go来写，是否是能够很好的利用这两个语言的优势进行互补？心动不如行动，因为咱们的erlang游戏架构的藕合度仍是挺低的，所以分离出来地图服务器，用Go从新实现了下，经过socket跟erlang架构部分进行通讯，发现效果异常之好，Go的性能、并发的原生支持再配合上erlang写游戏框架，在性能上已经毫不亚于C++框架，可是后者你们都懂，中关村程序员听说平均寿命50多岁，很大的一部分缘由是由于这个。

之后的路怎么走？

    混合型编程会是之后的主流，由于没有哪一个语言是完美的，包括被众多“朝圣者”所推崇的Go,若是咱们能根据本身的业务场景，选对合适的语言，那不敢说事半功10倍，至少事半功倍应该是有的，因此不要被主流语言(Java,C++)禁锢了咱们的世界，局限了咱们的创新，若是能作到轻松愉快的开发，那这个世界该多美好！！