"《英雄联盟》支撑最高750万同时在…

      今天在CSDN上看到 《英雄联盟》支撑最高750万同时在线用户的聊天服务打造  一文。因为这一年多来，自己主要在做一款IM产品，对其他IM产品比较关注， 所以在此做做笔记和写下读后感。

      1、高性能：“ 支撑750万并发用户，2700万日活跃用户，每秒钟需要处理的消息上万条，每台服务器每天处理消息达十亿条。”，" 每个Chat服务器都可以支撑数百万连接数。"。单服务器能支持的并发连接数和Whatsapp差不多，这个数值还是相当高的，整个服务得优化得很好。

      2、高可用：“ 世界范围内部署的chat服务器达数百台，负责运维人员只有3个"、“99%的可用率”。对此作了很多工作，比如自动化监控和报警、动态代码加载（ 热更新、 更新服务不用重启）、灰度更新、充足的日志、自动化测试。

      3、服务架构：一开始基于开源 XMPP服务 Ejabberd（用Erlang语言编写）。不过后来对erlang进行定制，重写了Ejabberd大部分代码（“ 扩展性、性能和容错机制是个长期奋斗目标，大部分的Ejabberd代码都已经被重写”） ，也偏离了核心的XMPP协议（“   基于性能和新功能等原因，他们不得不偏离核心XMPP协议") 。。。。我觉得早知今日何必当初，估计一开始就用Java写可能还更快。（ps：erlang开发土想也知道很难找）

      4、数据库架构：一开始用Mysql，后来使用 Riak（ “ 开始时选择的MySQL造成了性能、可靠性、扩展性等多方面的问题。比如，数据模式的修改速度匹配不了代码的变更“） 。 每台服务器上都运行了Ejabberd和Riak。

       我觉得比较有启发性的点：

       1、在开发时考虑好逃生通道。” 最近有一次客户端升级造成了无限广播用户状态的问题。着眼Graphite，工程师很快定位到服务器因新客户端上线（带来的新特性）而崩溃。”“ 新功能开发时就会被添加Toggles（on/off ）特性，如果一个功能导致问题产生，工程师可以立刻关闭它。“。 我觉得相比期望代码绝对不出错，预先规划好逃生通道应该更为科学和可行些。前一段看到微信的一个服务端设计——如果发现某个客户端一段时间内流量异常（可能是客户端死循环导致），则向客户端发送一个命令让其强制下线。我觉得也是体现了一样的思路。不完美，but it works.

       2、 在开发时考虑好运维 。具体措施主要就是 自动化监控和报警、 热更新、自动化测试、压力测试、灰度发布这些。虽然概念都知道，可惜知易行难，往往由于人手和时间有限，没有办法去开发 相关 工具。从管理角度来看这些属于”重要但不紧急“的范畴。如果想要做真正优秀的服务，还是得在这方面继续努力。