论文部分内容阅读
摘 要：游戏市场竞争激烈，产品格局变动较大，但游戏产业一直处于稳步增长阶段，无论是在端游，页游，手游还是H5游戏。其中，游戏类型中，MMOARPG游戏仍然会是引领市场的主流趋势，贡献着大部分流水，市场上也仍然在不断涌现精品。研发团队对MMO游戏的探索从来未间断过，从付费模式的改变，到题材多元化，次时代的视觉效果，更成熟的玩法及数值体系，本文主要针对跨服玩法上的探索和实现做一些思考和分析，首先挖掘出玩家潜在的跨服需求，然后针对这些需求提出几套实现方案，并进行了对比，最终方案通过几款大型游戏项目得到验证。
关键词：游戏;跨服;架构;RPC
一、概述
根据2020年第一季度《中国游戏产业报告》数据显示，随着游戏人口红利逐渐消失，获取用户的成本居高不下，几年来至少翻了十倍以上，中国游戏用户规模发展缓慢，新用户增长趋于平稳，进入存量竞争阶段。2020年第一季度较2019年第四季度用户规模仅增加200万人，环比增长0.31%。平均导量成本居高不下，“洗”用户模式的效果正在变得微弱，用户流失严重。让我们先来看看滚服玩法的局限性，滚服洗量模式下存在着如下的弊端：
在上述背景下，一款长留存，低流失的精品游戏就成了平台方，渠道商，研发方追捧的目标，设想一下，如果让所有服务器玩家通过“跨域体系”实现自由畅通交互，在此基础上，玩家可以体验到前所未有的“国战系统”一一7X24小时昼夜不停服的国家战争，随时开战;突破单地图承载容量极限的国战对决，带来真正万人国战的刺激体验，形成全区玩家能够互动的游戏社交环境。依托平台运营来打造一款真正意义上摆脱传统游戏运营模式的全新产品，为平台吸纳足够的市场份额，大幅降低流失率。
我们的蓝图是开创“1=1000”模式，让所有玩家，身处一个服务器却如同同时存在于所有服务器，这种打破服务器屏障的设定，杜绝了游戏出现“被迫滚服”现象出现，玩家不用再担心鬼服人烟稀少，不用担心交易所一无所有，所有的数据共享，让玩家轻松Hold住全世界。
项目组面临的现状是游戏各种档期计划、宣传推广安排都已经就绪，开发不能因引入跨服机制而导致所有完成度100%的功能都要去分别去增加跨服的支持，而技术人员在跨服功能开发这块经验的积累上也不充分。
技术小组分析了时下项目的现状，跨服业务需求及现有的框架结构，明确了几点原则：
（1）为了实现跨服，游戏代码从底层架构到上层业务逻辑的代码改动成本尽量降低
（2）业务逻辑里尽量少关心或者不用关心是否在本服或者跨服，降低开发人员的跨服功能开发复杂度，提高开发的效率，缩短开发周期。
那么，我们需要解决哪些技术疑点呢？
二、核心技术难点和解决方案的阐述
2.1客户端直连还是服务器转发
（1）如果直连，那么，跨服玩法时客户端要维持两个连接，在跨服里，要模拟玩家登陆，绑定session的过程，游戏服和跨服两边要同时维护两份玩家数据，如何做到数据的同步？跨服要暴露给玩家，需要有公网访问IP和端口。对客户端连接管理来说较复杂。
（2）如果通过大区服务器消息转发，那么，服务器之间做RPC通信，连接管理，消息需额外做一步跳转，性能能否满足？跨不跨服，对于客户端来说透明，跨服隱藏在大区之后，更加安全，不需再浪费公网IP和端口。
综合考虑了下，采用了（2）方案。
2.2 RPC框架设计
那么，我们需要先准备一套高性能轻量级的RPC框架。业界有很多典型的RPC框架，比如Motan、Thrift、gRPC、Hessian、Hprose，Wildfly，Dubbo，DubboX，为什么我们还要重复造轮子呢？综合考虑了下，框架要满足以下几点业务需求：
·该框架要简单、易用、支持高并发的跨服请求;
·根据现有的游戏服务器框架，会有很多定制化的场景;
·支持同步请求，异步请求，异步回调CallBack;
·要有服务发现的功能，要有Failfast能力;
·具备负载均衡，分组等路由策略。
基于有以上的诉求，结合团队以前的开发经验，于是就决定自主研发。我们选用的技术栈有Netty、ApacheCommons Pool、Redis等。
框架分为服务提供方（RPC Server）、服务调用方（RPcClient）、注册中心（Registry）三个角色，基于Redis为服务注册中心，通过其Pub/sllh实现服务动态的注册和发现。Server端会在服务初始化时向Registry注册声明所提供的服务;Client向Registry订阅到具体提供服务的Server列表，根据需要与相关的Server建立连接，进行RPC服务调用。同时，Client通过Registry感知Server的状态变更。三者的交互关系如下图：
2.2.1、RPC请求的有序性
连接池在设计过程中，比较重要的是要考虑请求的顺序性，也就是先请求的先完成。如果玩家的跨服请求通过不同的RPC连接并发执行，就有可能单个玩家请求因错序而导致逻辑矛盾，比如玩家移动，见图3
玩家移动是很频繁的，如果A请求让玩家从位置1移动到位置2，B请求从位置2移动到位置3，有可能B请求先被跨服接收处理，这就会产生逻辑问题。
那么，如何做到请求的有序性呢？其本质是让同一份数据的访问能串行化，方法就是让同一个玩家的跨服请求通过同一条RPC连接执行，加上逻辑上的有效性验证，如图4所示：
2.2.2、同步RPC实现细节
限于篇幅，这里只展示同步请求的RPC连接池实现，同步请求的时序图如图5：
上图为进入跨服战场的一次同步请求，场景切换控制器StageControllAction发起进入跨服战场的请求applyChangeByBattlefield（），场景管理器首先要调用登录跨服的RPC请求GameRpcClient.10ginCrossServer（LoginCrossServerReq）。 测试场景为分别在连接数在1，8，并发数1，8，数据大小在22byte，94byte，2504byte情况下，做测试，消息同步传输，原样返回，以下是针对同步请求压力测试的结果（取均值）：
2.3服务器之间推拉策略选择
2.3.1被动拉取模式（Pull）
由于我们的游戏服务器和跨服服务器代码基本一致，所以只要能在跨服中获得游戏功能所要的数据，那么，就能完成任何原有的功能，并且改造成本基本为零，我们选择了被动拉取。
这里要提出一个概念：数据源的相对性，提供数据方，c向B请求一份数据，B是c的数据源，B向A请求一份数据，A是B的数据源。
一个玩家跨服过去后，往游戏原服拉取数据的细节图如图7，玩家先跨服过去，loginCrossServer（LoginCrossServerReq），然后，在用到任意数据时（主角，技能，坐骑，装备，宠物等），反向同步请求各个系统的数据。
我们的实现如图8所示：
关于被动拉取的优缺点介绍，在下文另有论述。总之，由于被动拉取的一些我们始料未及的缺陷存在，成为了我们服务器端开发部分功能的噩梦，从选择该模式时就埋下了隐患。
2.3.2主动推送模式（Push）
为了解决了上面碰到的一系列问题，
并且还能坚持最初的原则，我们做了如下几点优化，优化方案有如下几点：
·如果玩家在本服，和调整前一样的处理流程，如果玩家在跨服，客户端请求的指令，发布的事件，异步事件需要在场景Stage线程处理的，就转发到跨服，需要在其他个人业务线程（bus），公共业务线程（public）处理的，仍旧在本服处理。
·场景业务线程不再允许有DB操作。
·内部指令的转发、事件分发系统、异步事件系统要在底层支持跨服。
·玩家在登录本服时就会构建PlayerTemplate，
场景用到的数据会实时更新，玩家去跨服，则会把场景中用到的数据PlayerTemplate主动推送给跨服。主动推送模式图示显示如图9所示。
如下图，举个例子，在跨服怪物死亡后，会抛出MonsterDeadEvent事件，在跨服进程直接处理场景的监听对应的逻辑：场景中道具掉落，尸体处理;其他的监听逻辑抛回游戏服处理，根据这事件，任务模块处理完成任务，获得奖励;成就模块处理完成成就，获得奖励;主角模块获得经验，金币等奖励;活动模块处理完成活动，获得奖励。
2.4其他方面的优化
2.4.1消息组播机制
消息组播的优化，在跨服，来自同一服的全部玩家广播从分别单独消息转发，改成一个消息发回本服，然后再广播给玩家（比如来自同一个服n个玩家，原本广播一条消息，服务器之间之间要处理n个RPC消息，现在只需要处理1个消息，降到了原先的1/n）。
2.4.2通信数据量
一个完整的PlayerTemplate模版数据由于包含了玩家在场景里用到的所有数据，比如角色、宠物、坐骑、装备、神器、法宝、时装、技能、翅膀等等，数据量比较大，平均能达到5KB左右，需要在服务器之间传输时做zlib压缩，比如，做了压缩后，11767 Byte的玩家数据能压缩到2337Byte，压缩率可达到19.86%。
2.4.3序列化/反序列化
改造前，所有的请求都需要先在本服做AMF3反序列化，如果请求是需要转发到跨服的，再通过JSON序列化传输给跨服，在跨服通过JSON反序列化，最终该请求被处理。
但实际上，中间过程JSON序列化和反序列化似乎是没有必要的，经过改造，对需要转发给跨服的请求，在本服先不做ANF3反序列化，发送到跨服后再处理，这样就少了一次JSON的序列化和反序列化，同时收益了另外的一个好处：降低了传输的字节。
2.4.4服务器分组机制
不定向跨服是指任意游戏区的玩家都有可能匹配到一起进行游戏玩法的体验，比如跨服战场，比如跨服副本匹配。如何在游戏正式大区中选择几个服做灰度服，又不影响不定向跨服体验;以及如何解决新老服玩家战力发展不在同一起跑線而导致的不平衡问题曾一度让人纠结。
比如游戏产品推出了大型资料片，想先做下灰度测试，让1-4区的玩家先做下新功能的体验，同时又能防止玩家穿了一件旧版本不存在的装备而在跨服环境下报异常，如图13，根据运营需求通过分组，就很完美的解决了上述问题。
2.4.5跨服断线重连机制
比如战场系统或组队副本，由于网络状况而掉线，如果重新登录后，没法进入，将会严重影响战场的战况，顺风局马上就可能会变成逆风局，主力DPS掉线副本就有可能通不了，这个机制就弥补了这块的缺陷。
2.5跨服架构
图14为跨服通信拓扑图，是整体架构的核心部分，关于这部分的说明如下图，
此套架构历经了《大闹天宫OL》、《诸神黄昏》、《暴风王座》、《惊天动地》，《三打白骨精》、《英雄领主》、《封神霸业》等产品先后近20000组服务器运行的验证和团队的技术积累，使用该架构的产品列表如下：
其中图16为游戏《暴风王座》某个跨服玩法的截图，以看出，该游戏当时具有很高的人气。当时的最高日活跃为650467，最高在线人数为143319，有着非常出色的跨服性能数据表现。
三、总结
本文从当前游戏市场发展的背景出发，提出了设计自由交互的“跨域体系”的必要性，然后在实现跨服架构的过程中对设计目标、原则、存在的技术难点进行了思考，实现了一套用于跨服通信的高吞吐的RPC通信框架，先后体验了被动拉取模式带来的坑，和改成主动推送模式带来的便利。并且，对该架构设计在消息组播，通信量，消息序列化/反序列化，服务器分组，断线重连等进行了多方面机制的分析及深度优化，最后上线实践做了可行性验证，提供了强有力的数据支持，总体表现稳定流畅。
关键词：游戏;跨服;架构;RPC
一、概述
根据2020年第一季度《中国游戏产业报告》数据显示，随着游戏人口红利逐渐消失，获取用户的成本居高不下，几年来至少翻了十倍以上，中国游戏用户规模发展缓慢，新用户增长趋于平稳，进入存量竞争阶段。2020年第一季度较2019年第四季度用户规模仅增加200万人，环比增长0.31%。平均导量成本居高不下，“洗”用户模式的效果正在变得微弱，用户流失严重。让我们先来看看滚服玩法的局限性，滚服洗量模式下存在着如下的弊端：
在上述背景下，一款长留存，低流失的精品游戏就成了平台方，渠道商，研发方追捧的目标，设想一下，如果让所有服务器玩家通过“跨域体系”实现自由畅通交互，在此基础上，玩家可以体验到前所未有的“国战系统”一一7X24小时昼夜不停服的国家战争，随时开战;突破单地图承载容量极限的国战对决，带来真正万人国战的刺激体验，形成全区玩家能够互动的游戏社交环境。依托平台运营来打造一款真正意义上摆脱传统游戏运营模式的全新产品，为平台吸纳足够的市场份额，大幅降低流失率。
我们的蓝图是开创“1=1000”模式，让所有玩家，身处一个服务器却如同同时存在于所有服务器，这种打破服务器屏障的设定，杜绝了游戏出现“被迫滚服”现象出现，玩家不用再担心鬼服人烟稀少，不用担心交易所一无所有，所有的数据共享，让玩家轻松Hold住全世界。
项目组面临的现状是游戏各种档期计划、宣传推广安排都已经就绪，开发不能因引入跨服机制而导致所有完成度100%的功能都要去分别去增加跨服的支持，而技术人员在跨服功能开发这块经验的积累上也不充分。
技术小组分析了时下项目的现状，跨服业务需求及现有的框架结构，明确了几点原则：
（1）为了实现跨服，游戏代码从底层架构到上层业务逻辑的代码改动成本尽量降低
（2）业务逻辑里尽量少关心或者不用关心是否在本服或者跨服，降低开发人员的跨服功能开发复杂度，提高开发的效率，缩短开发周期。
那么，我们需要解决哪些技术疑点呢？
二、核心技术难点和解决方案的阐述
2.1客户端直连还是服务器转发
（1）如果直连，那么，跨服玩法时客户端要维持两个连接，在跨服里，要模拟玩家登陆，绑定session的过程，游戏服和跨服两边要同时维护两份玩家数据，如何做到数据的同步？跨服要暴露给玩家，需要有公网访问IP和端口。对客户端连接管理来说较复杂。
（2）如果通过大区服务器消息转发，那么，服务器之间做RPC通信，连接管理，消息需额外做一步跳转，性能能否满足？跨不跨服，对于客户端来说透明，跨服隱藏在大区之后，更加安全，不需再浪费公网IP和端口。
综合考虑了下，采用了（2）方案。
2.2 RPC框架设计
那么，我们需要先准备一套高性能轻量级的RPC框架。业界有很多典型的RPC框架，比如Motan、Thrift、gRPC、Hessian、Hprose，Wildfly，Dubbo，DubboX，为什么我们还要重复造轮子呢？综合考虑了下，框架要满足以下几点业务需求：
·该框架要简单、易用、支持高并发的跨服请求;
·根据现有的游戏服务器框架，会有很多定制化的场景;
·支持同步请求，异步请求，异步回调CallBack;
·要有服务发现的功能，要有Failfast能力;
·具备负载均衡，分组等路由策略。
基于有以上的诉求，结合团队以前的开发经验，于是就决定自主研发。我们选用的技术栈有Netty、ApacheCommons Pool、Redis等。
框架分为服务提供方（RPC Server）、服务调用方（RPcClient）、注册中心（Registry）三个角色，基于Redis为服务注册中心，通过其Pub/sllh实现服务动态的注册和发现。Server端会在服务初始化时向Registry注册声明所提供的服务;Client向Registry订阅到具体提供服务的Server列表，根据需要与相关的Server建立连接，进行RPC服务调用。同时，Client通过Registry感知Server的状态变更。三者的交互关系如下图：
2.2.1、RPC请求的有序性
连接池在设计过程中，比较重要的是要考虑请求的顺序性，也就是先请求的先完成。如果玩家的跨服请求通过不同的RPC连接并发执行，就有可能单个玩家请求因错序而导致逻辑矛盾，比如玩家移动，见图3
玩家移动是很频繁的，如果A请求让玩家从位置1移动到位置2，B请求从位置2移动到位置3，有可能B请求先被跨服接收处理，这就会产生逻辑问题。
那么，如何做到请求的有序性呢？其本质是让同一份数据的访问能串行化，方法就是让同一个玩家的跨服请求通过同一条RPC连接执行，加上逻辑上的有效性验证，如图4所示：
2.2.2、同步RPC实现细节
限于篇幅，这里只展示同步请求的RPC连接池实现，同步请求的时序图如图5：
上图为进入跨服战场的一次同步请求，场景切换控制器StageControllAction发起进入跨服战场的请求applyChangeByBattlefield（），场景管理器首先要调用登录跨服的RPC请求GameRpcClient.10ginCrossServer（LoginCrossServerReq）。 测试场景为分别在连接数在1，8，并发数1，8，数据大小在22byte，94byte，2504byte情况下，做测试，消息同步传输，原样返回，以下是针对同步请求压力测试的结果（取均值）：
2.3服务器之间推拉策略选择
2.3.1被动拉取模式（Pull）
由于我们的游戏服务器和跨服服务器代码基本一致，所以只要能在跨服中获得游戏功能所要的数据，那么，就能完成任何原有的功能，并且改造成本基本为零，我们选择了被动拉取。
这里要提出一个概念：数据源的相对性，提供数据方，c向B请求一份数据，B是c的数据源，B向A请求一份数据，A是B的数据源。
一个玩家跨服过去后，往游戏原服拉取数据的细节图如图7，玩家先跨服过去，loginCrossServer（LoginCrossServerReq），然后，在用到任意数据时（主角，技能，坐骑，装备，宠物等），反向同步请求各个系统的数据。
我们的实现如图8所示：
关于被动拉取的优缺点介绍，在下文另有论述。总之，由于被动拉取的一些我们始料未及的缺陷存在，成为了我们服务器端开发部分功能的噩梦，从选择该模式时就埋下了隐患。
2.3.2主动推送模式（Push）
为了解决了上面碰到的一系列问题，
并且还能坚持最初的原则，我们做了如下几点优化，优化方案有如下几点：
·如果玩家在本服，和调整前一样的处理流程，如果玩家在跨服，客户端请求的指令，发布的事件，异步事件需要在场景Stage线程处理的，就转发到跨服，需要在其他个人业务线程（bus），公共业务线程（public）处理的，仍旧在本服处理。
·场景业务线程不再允许有DB操作。
·内部指令的转发、事件分发系统、异步事件系统要在底层支持跨服。
·玩家在登录本服时就会构建PlayerTemplate，
场景用到的数据会实时更新，玩家去跨服，则会把场景中用到的数据PlayerTemplate主动推送给跨服。主动推送模式图示显示如图9所示。
如下图，举个例子，在跨服怪物死亡后，会抛出MonsterDeadEvent事件，在跨服进程直接处理场景的监听对应的逻辑：场景中道具掉落，尸体处理;其他的监听逻辑抛回游戏服处理，根据这事件，任务模块处理完成任务，获得奖励;成就模块处理完成成就，获得奖励;主角模块获得经验，金币等奖励;活动模块处理完成活动，获得奖励。
2.4其他方面的优化
2.4.1消息组播机制
消息组播的优化，在跨服，来自同一服的全部玩家广播从分别单独消息转发，改成一个消息发回本服，然后再广播给玩家（比如来自同一个服n个玩家，原本广播一条消息，服务器之间之间要处理n个RPC消息，现在只需要处理1个消息，降到了原先的1/n）。
2.4.2通信数据量
一个完整的PlayerTemplate模版数据由于包含了玩家在场景里用到的所有数据，比如角色、宠物、坐骑、装备、神器、法宝、时装、技能、翅膀等等，数据量比较大，平均能达到5KB左右，需要在服务器之间传输时做zlib压缩，比如，做了压缩后，11767 Byte的玩家数据能压缩到2337Byte，压缩率可达到19.86%。
2.4.3序列化/反序列化
改造前，所有的请求都需要先在本服做AMF3反序列化，如果请求是需要转发到跨服的，再通过JSON序列化传输给跨服，在跨服通过JSON反序列化，最终该请求被处理。
但实际上，中间过程JSON序列化和反序列化似乎是没有必要的，经过改造，对需要转发给跨服的请求，在本服先不做ANF3反序列化，发送到跨服后再处理，这样就少了一次JSON的序列化和反序列化，同时收益了另外的一个好处：降低了传输的字节。
2.4.4服务器分组机制
不定向跨服是指任意游戏区的玩家都有可能匹配到一起进行游戏玩法的体验，比如跨服战场，比如跨服副本匹配。如何在游戏正式大区中选择几个服做灰度服，又不影响不定向跨服体验;以及如何解决新老服玩家战力发展不在同一起跑線而导致的不平衡问题曾一度让人纠结。
比如游戏产品推出了大型资料片，想先做下灰度测试，让1-4区的玩家先做下新功能的体验，同时又能防止玩家穿了一件旧版本不存在的装备而在跨服环境下报异常，如图13，根据运营需求通过分组，就很完美的解决了上述问题。
2.4.5跨服断线重连机制
比如战场系统或组队副本，由于网络状况而掉线，如果重新登录后，没法进入，将会严重影响战场的战况，顺风局马上就可能会变成逆风局，主力DPS掉线副本就有可能通不了，这个机制就弥补了这块的缺陷。
2.5跨服架构
图14为跨服通信拓扑图，是整体架构的核心部分，关于这部分的说明如下图，
此套架构历经了《大闹天宫OL》、《诸神黄昏》、《暴风王座》、《惊天动地》，《三打白骨精》、《英雄领主》、《封神霸业》等产品先后近20000组服务器运行的验证和团队的技术积累，使用该架构的产品列表如下：
其中图16为游戏《暴风王座》某个跨服玩法的截图，以看出，该游戏当时具有很高的人气。当时的最高日活跃为650467，最高在线人数为143319，有着非常出色的跨服性能数据表现。
三、总结
本文从当前游戏市场发展的背景出发，提出了设计自由交互的“跨域体系”的必要性，然后在实现跨服架构的过程中对设计目标、原则、存在的技术难点进行了思考，实现了一套用于跨服通信的高吞吐的RPC通信框架，先后体验了被动拉取模式带来的坑，和改成主动推送模式带来的便利。并且，对该架构设计在消息组播，通信量，消息序列化/反序列化，服务器分组，断线重连等进行了多方面机制的分析及深度优化，最后上线实践做了可行性验证，提供了强有力的数据支持，总体表现稳定流畅。