逆战server负载均衡的演化
陈明建(jerrychen)
在正式介绍server负载均衡策略演化细节前，我们先一起来看下逆战server的几个关键节点：
上图中箭头曲线展示了负载均衡策略的演进史，柱状图展示了逆战PCU的几个里程碑节点。细心的同学可能已经发现，负载均衡策略的几次调整都在重大里程碑节点来临之前。2011.6内测前，我们于2010.12月正式完成均衡策略的第一次改版；2012.9月不限号测试前，我们完成了策略的第二次改版，这次改版从发起到完成历时较短，但还是顺利通过了60W在线的考验；2013.12月公测前，我们于2013.4月完成了第三次改版，顺利达成129W最高同时在线的目标。
在历次改版中，我们秉承了“边运营边优化”的原则，从实际运营需求出发，以server的稳定性为第一原则，兼顾了可运维和可扩展性。目前回头来看这种策略还是比较成功的，把握了项目的发展脉搏，在特定的项目发展阶段做恰当的事情，避免了过度优化，
我们先来看下逆战server的整体负载均衡策略，目前后台server采用了三级负载均衡策略，分别从用户接入，大厅频道分配，战斗server分配三个场景进行负载引导。具体如下图：
其中login server集群负责用户接入层的负载均衡；zone server集群实现大厅频道功能，与login server相配合，实现频道管理层的均衡；dsagent集群即为战斗server集群，该集群与zone server配合实现战斗server分配的均衡。接入层需要做负载均衡很好理解，但频道和战斗server的负载均衡为何要分开呢？这是另外一个话题，本文暂不涉及，如果有兴趣，线下交流J
三级负载均衡中，dsagent集群是本文要介绍的重点，负载均衡策略演化主要发生在zone和dsagent之间。下面对各阶段采用的策略及其优缺点做个介绍，抛砖引玉。
1. Zone ->dsm模式
在2010年7月前，逆战后台采用这种模式。这种模式中，ds的管理模块dsm作为zone进程的一个类形式存在，并且ds server常驻内存中，采用多副本共用一个进程的方式。由于逆战采用UE3引擎，该引擎client和server端共用一套代码，server端的代码没有针对linux专门进行优化，导致server端在内存使用以及稳定性方面存在很多问题，所以这种方式的问题是显而易见的，实际运营中必然无法满足逆战7*24小时的服务要求。因此在前期demo阶段过后，这种模式就被抛弃，从而有了第一次改版。
2. Zone->dsa, 1->n模式
这种模型中ds由dsagent(简称dsa)管理，每个副本使用一个ds进程，采用类似CGI的服务方式，“用后即焚”，规避了ds进程在linux下不稳定的问题（当然仅仅是规避，ds的稳定性问题花了我们大量的精力来解决）。同时zone不再直接申请ds，而是通过管理dsa的负载信息选择某个dsa来申请ds进程。
这种模式以CGI方式启动副本，对ds的启动时间提出了很高的要求。经过评估，我们发现ds的启动必须在1~3秒内完成，否则就影响到玩家体验，这带来了一个极大的技术挑战。这个技术难题最后在我们的技术大牛jiantang的手上得到完美解决。
从技术封测到开放性测试期间，采用的是上图所示的均衡模型。这期间顺利承担了8W PCU的压力，同时也暴露出该方案的几个缺陷：一是该方案中每个dsa仅为单个zone服务，而玩家在zone上的分布是动态的，这导致在实际运营中某些dsa的利用率很低，某些dsa超负荷运转，这种现象在平时运营中影响不大，但在冲线时影响很大，特别当是当玩家在zone上的分布存在较大不均衡时。二是在线运营时如果要不停服调整dsa的服务对象（zone），则需要手动修改配置，加上dsa的冷却时间较长（需要等待已启动的ds进程全部结束），不能满足在线迅速调配负载的需求。
考虑到这两个缺点，为了能够更好的应对接下来的开放性测试，我们server组同学提出了后面要介绍的第三、四两套方案。经过讨论，大家认为第四套方案应该是最终解决方案，但需要对代码进行较大修改，需要一段时间稳定，在当时紧迫的时间下，最终选择了第三套方案作为过渡方案。
3. Zone->dsa, n->1模式
这种方案作为过渡性方案主要解决方案二中dsa利用率的问题，避免冲线时出现机器数足够，但负载能力不足的现象。该方案中，每个dsa可以为多个zone服务，从而规避了dsa负载浪费的问题。但明显地它存在以下两个缺陷，一是由于dsa上报负载信息是定时的，导致多个zone可能在心跳间隔期间”扎堆”向他们看到的“负载最轻”的dsa发请求，导致该dsa瞬间负载升高，增加请求失败率；二是为了减轻zone的“扎堆”现象，需要对根据zone对dsa进行手动分组配置，在后续开放性测试中，我们发现前期的配置表配置工作很繁重，特别容易出错。
对于第一个缺点，我们采用有限重试的方式进行规避，第二个缺点，采用人工配置 工具检查的方式进行缓解。最终也顺利顶住了60W同时在线的压力。
当然我们的下一个目标是百万在线，开放性测试结束后，这个中间过渡方案也完成了它的使命。
4. Zone->dsc->dsa，n->1->n模式
这套方案是目前逆战正在外网运营的方案，该方案中，我们在zone和dsa之间增加了dscenter管理模块，由dscenter负责管理dsa负载信息，dsa的分组信息，以及zone到ds的申请。也就是引入了中心节点管理来dsa。那dscenter不就成了单点吗？没错，这是这个方案的最大缺陷。不过我们通过备份部署dscenter的方案解决。由于dscenter上的负载信息可以认为是“随时”处于失效状态，因此只要备份dscenter在工作，整个系统就是稳定的。另外，在实际应用中，不同IDC独立部署dscenter及对应的备份dscenter，对机器数较多的IDC再进行dscenter拆分，部署多个dscenter，既减小了dscenter单点的风险，又增加了负载调度的灵活性。
在2013年底的公测中，这个方案顶住了129W 最高在线的压力，其有效性得到了充分验证。
逆战server负载均衡演进史的简单介绍就到这里了。基于第四套方案的细小优化我们还在持续进行中，那会有第四次进化，第五套方案出现吗？看实际运营需求了J