网上有很多博客讨论erlang做游戏后端开发的优劣，而我自己选用erlang做游戏后端，主要是考虑到下列几点。
轻量级进程
-
业务和进程的自然映射。erlang 轻量级进程（在一个游戏服里，可以同时开十万量级的进程数）和现实世界有很好的映射，一个进程，相当于传统语言（java，c++等）的 对象+时间维度（对象生命周期）。游戏世界里的对象总是有生命周期的，像玩家在线离线，活动开启关闭，商城，战场等等。这样，在进程和实际业务之间往往能有很好的映射，容易建模，也容易理解，可以大大降低项目实现的复杂度。
-
数据隔离。erlang进程实现了数据独立性，每个进程的数据是相互独立的，也是单独做垃圾回收的（回收效率高，不会stop the world）。玩家（每个玩家一个单独进程）数据和业务数据有天然的隔离层，数据之间不会相互影响，出问题的时候有利于做数据跟踪。
优秀的调度系统
-
充分发挥多核优势。用erlang开发的程序，在代码不做特殊处理的情况下就可以充分发挥多核优势，其调度系统默认会把调度任务计数，并分配到每一个核上。当你的游戏是由大量轻量级进程组成（强烈推荐不要有重业务的进程）的时候，你会发现每一个核的使用率基本上都是均衡的。遇到cpu性能瓶颈的时候，只要做硬件升级就可以了，完全不用动代码。
-
平均调度，服务降级。系统进入CPU瓶颈的时候，整个服务会变慢降级，但不会直接崩溃。这样我们可以获得三个好处。一个是当系统出问题的时候，保留了现场，我们可以直接在线上诊断甚至修复。二个是实现进程间的故障隔离，大多数情况，除了出问题的进程和模块，别的进程依然可以正常使用。最后是消息堆积会成为进程出现问题的一个很好的指标，通过监控进程的消息堆积，我们可以判断进程的健康状况。
对分布式良好的支持
-
开展跨服业务。架构上很容易实现对业务层隐藏节点信息，使得跨服进程通信和节点内进程通信保持一致，业务层面可以像和本地进程交互一样实现跨服逻辑。比方跨服竞技和本地竞技，完全可以用同一套代码实现。
-
拆分业务性能瓶颈。比方战斗进程，一般都是比较消耗cpu资源的，但也往往是比较独立的进程，如果服务器有压力，就可以考虑把战斗进程单独部署到另一台机器。得益于erlang对分布式的良好支持，这个拆分甚至可以在项目的后期进行。
天然支持热更新
做游戏，热更新是必不可少的一环。erlang原生支持代码热更新，同时，因为是函数式编程，数据和业务代码逻辑是天然分离的，程序员在业务实现上就不可能把数据和业务混在一起，所以热更新会非常的自然，虽然同样会有一些要特别注意的地方。
优秀的在线监控，调试支持
-
在线调试，recon对系统的在线操作进行了良好的封装，对在线获取信息，在线调bug，在线修复bug都有很好的支持。
-
完善的监控，基于recon可以对所有的进程进行定期监控（比方30秒一次输出进程，内存，cpu使用，消息队列等信息）。特别是对消息队列的监控，消息队列的堆积往往反映了服务的瓶颈，通过这些监控信息，可以分析在线运行的健康状况和可能出现瓶颈的地方。系统出问题的时候也可以作为分析的主要依据。
