尽管游戏市场很猛烈，并且产品结构发生了很大变化，但游戏行业一直处于稳定的增长阶段，无论是在电脑游戏，网络游戏，手游还是HTML5游戏中最初展示标志。可以预见的是，在游戏类型中，游戏仍然是领导市场的主流趋势，贡献了大部分步骤，而且高质量的产品仍在市场上出现。研发团队对MMO游戏的寻觅从未停止过。从付费模型的变化到主题的多元化，下壹个时代的视觉效果以及更成熟的游戏模式与数值系统，本文主要关注跨服务器游戏模式的寻觅与实施。

根据2016年“中国游戏行业报告”的数据，随着游戏人口股息的逐渐消失，获得用户的成本仍然很高，并且在过去几年中至少增加了十倍。目前，网络游戏的平均启月成本为10至15元/人，手游为15至20元/人，其中iOS的成本为30至50元/人。 “洗”用户玩法的效果变得虚弱，用户损失是严重的。让大家首先看一下滚动服务器游戏模式的局限性。在滚动服务器WASH玩法下，有以下缺点：

在上述情况下，具有长期保留与低损失的高质量游戏已成为平台派对，渠道供应商与研发派对的流行目标。想象一下，如果全部服务器播放器都可以通过“跨域系统”实现自由而平稳的互动，那么玩家可以体验到前所未有的“国家战争系统” - 一场日夜不断地服务的国家战争，并在任何时候最初；一场打破单一地图的容量限制的全国战争将带来一万人的全国战争，形成壹个游戏社交环境，在该环境中，整个地区的玩家可以互动。依靠平台运营，大家将创建一种新产品，该产品真实摆脱了传统的游戏操作模型，吸收了足够的市场份额，并大大降低了流失率。

大家的蓝图是创建“ 1 = 1000”玩法，以便全部播放器都在一台服务器中，但它们似乎同时存在于全部服务器上。破坏服务器屏障的这种配置消除了游戏中“被迫投降”的现象。玩家不再需要担心幽灵服务器的稀疏人群，不必担心交换没有任何东西，全部数据共享都使玩家可以轻松地拥有全世界。

当时项目团队面临的当前情况是游戏的时间表与促销安排已经预备好了。两个月后，该专属项目将按时在企鹅平台上启动。由于引入了跨服务器机制，无法实现发展，并且必须分别提升全部完成水平的功能。技术人员没有积累跨服务器功能开发的经验。

技术团队解析了该项目的当前状况，跨服务业务需求与现有框架结构，并阐明了几个守则：

客户端直接连接或服务器转发

计划A直接连接。如果您直接连接，则客户在播放跨服务器时必须保持两个连接。在交叉服务器中，有必备SIM玩家登录与绑定过程。游戏服务器与跨服务器必须同时维护两个玩家数据。怎么同步数据？要将跨服务器暴露于玩家，您需要拥有公共网络访问IP与端口。客户连接管理更为复杂。

计划B，给前。如果消息是通过区域服务器转发的，则需要在服务器之间执行R电脑通信与连接管理，并且需要将消息重定给壹个额外的流程。可以满足性能吗？交叉分类与服务器对客户透明。交叉观念隐藏在该地区后面，使其更加安全，而不会浪费公共IP与端口。

在综合思考之后，采用了B计划。

1。R电脑框架设计标准

因此，大家需要首先预备壹个高性能与轻巧的R电脑框架。该行业中有许多典型的R电脑框架，例如Motan，GR电脑，Dubbo，为啥子大家仍然需要从头创建轮子？经过综合思考，该框架必须满足以下业务需求：

根据上述标准，并结合了团队以前的发展经验，我决定独立发展。大家挑选的技术堆栈包括Netty，Pool，Redis等。

该框架分为三个人物：服务提供商（R电脑），服务呼叫者（R电脑）与注册中心（）。基于Redis，它是壹个服务注册中心，并运用其酒吧/子来实现动态注册与发现服务。终端将在初始化服务时声明提供向注册的服务；订阅提供的特定服务列表，根据需要建立和相关服务的连接，并进行R电脑服务调用。同时，国家通过感知到了。这三个之间的相互作用显示在图中：

通过提供路由政策，负载平衡政策与分组政策。有能力确保R电脑服务的高度可用性。

2。R电脑请求的顺序

在连接池的设计过程中，思考请求的顺序，即完成第壹个请求的顺序更为重要。如果播放器的跨服务器请求通过不同的R电脑连接同时执行，则单个玩家请求也许会导致由于错误的顺序（例如播放器移动）而导致逻辑矛盾，请参见图2：

玩家经常移动。如果壹个标准将播放器从位置1转移到位置2与B请求从位置2转移到位置3的请求，则也许首先在服务器上接收与处理B请求，这将导致逻辑​​问题。

那么，怎么实现有序的请求？本质是使访问相同的数据序列化。该方式是允许同一玩家的跨服务器请求通过相同的R电脑连接执行，以及逻辑验证，如图3：

3。同步R电脑实现详细信息

由于空间限制，大家将仅讨论用于同步请求的R电脑连接池的实现。同步请求的定时图显示在图中：

上图显示了进入跨服务器战场的同步请求。场景切换控制器启动了输入跨服务器战场IELD（）的请求。场景管理器首先需要调用跨服务器R电脑请求。（）。跨服务器R电脑请求的工作流量如下：

此请求的第一步是从连接池中获取连接=。（），然后启动同步请求。（），等待直到结果返回，然后将资源返回到连接池。

让大家专注于代码实施：

测试方案是在1、8，1、8与数据大小为1、8时的连接数量进行测试，并且该消息同步传输并按原样返回。以下是同步请求的压力测试的结果（以平均值为单位）：

服务器之间的主动推或被动拉力

1。被动拉玩法（拉）

由于大家的游戏服务器与跨服务器服务器代码基本相同，只要大家可以获取跨服务器中游戏功能所需的数据，就可以完成任何原始功能，并且修改成本基本上为零。大家挑选了被动拉力。

在这里，大家需要提出壹个概念：数据源的比较论。

数据提供商C标准B，B是C，B的数据源，B请求来自A的数据副本，A是B的数据源。

玩家越过服务器后，将数据拉入游戏原始服务器的详细信息如图所示：

玩家首先越过服务器，（），然后，当运用任何数据（主角暴风王座，技能，坐骑，设备，宠物等）时，它们会反给同步每个系统的数据。

大家的实现如下图所示：

查看事件分布代码的转换：

如下图所示，例如，在跨服务器怪物死亡之后，将投掷事件，跨服务器过程将直接处理场景监视的相应逻辑：

在场景中，道具被丢弃并处理了尸体；其他监视逻辑被扔回游戏服务器进行处理。根据此事件，任务模块处理任务并获取奖励；成就模块处理成就并获取奖励；主角模块获取了经验，金币与其他奖励；活动主题模块处理活动主题并获取奖励。

在其他方面的优化1。消息多播机制

消息多播的优化是，在跨服务器中，来自同一服务器的全部播放器从各个消息中广播以将消息发送回该服务器，然后将其广播到播放器（例如，来自同一服务器的N播放器的n个播放器播放了一条消息，而N R电脑消息开始只需要处理壹个消息，但开始只需要处理壹个消息，而该消息只需还原到原始1/n）。

2。通信数据量

壹个完整的模板数据包含场景中玩家运用的全部数据，例如人物，宠物，安装，设备，工件，魔术武器，时尚，技能，机翼等，数据量比较较大，平均约为5KB。在服务器之间传输时，需要ZLIB压缩。例如，压缩后，可以压缩11767字节的播放器数据，压缩率可以达到19.86％。

3。序列化/次要化

在转换之前，全部请求都需要在此服务器上进行应对。如果需要将请求转发到跨服务器，则将通过JSON序列化将其传输到跨服务器，并通过JSON在交叉服务器上进行序列化，并将处理该请求。

但是实际上，似乎在中间过程中的JSON序列化与避免化似乎是不必备的。修改后，对于需要转发到交叉服务器的请求，该服务器首先不会执行AMF3避难所，并且在处理之前将发送到跨服务器。这将减少JSON的序列化与避免序列化，同时，它将受益另壹个好处：它将减少传输字节。

4。内存运用优化

当前，JVM只能在JVM停止运行直到下壹个从头启动时释放内存。因此，为了防止浪费资源，各种类型的跨服务器服务器与游戏服务器需要配置不同的启动参数。启动参数的配置基于大家自己设定的公式，如图所示。

但是，内存运用情况通常会突破警告线的90％。由于一旦系统发现系统中没有足够的内存分配，它将触发自我保护机制并执行OOM，因此需要为每个JVM过程保留大量内存，并且每次维护时，脚本与修改内存也很麻烦。

内存运用状态如上图所示。升级服务器与维护服务器后，内存运用量会继续上升，直到将其保持一定值，并且除非下壹个维护或系统触发OOM，否则不会回收。

基于 JVM 1.8，只要启用-XX：+，CMS就可以将未运用的堆返回到系统的物理内存而无需从头启动应用程序。这样，大家不需要为JVM预留很多空间，而且大家不再需要担心会因偶然而杀死。

以内部测试阶段为例。运用ALI JVM后，64个内存设置计算机最终放开到24个新区域。和之前的64G内存机相比，如果单个单元只能存储9个独立的游戏区域，则单个区域的成本将节省62.5％的机器资源，这是特别等于大的。它最佳地化解了频繁的记忆紧密度的问题，并大大节省了成本。在这里，大家非常感谢阿里巴巴云团队与@kungu提供黑色技术。如果您有任何需求，则可以申请成为种子用户。

上图显示了运用Ali JDK后的曲折效应。怠速记忆将在每个特定时间段内被系统回收，这在JVM中很难做到。

5。服务器分组机制

无方给的跨服务器意味着任何游戏区域的玩家都可以将游戏经验匹配，例如跨服务器战场，例如跨服务器副本匹配，如图所示（分别表示服务器分组之前与之后）。

怎么在官方游戏区域中挑选多个服务器用作灰度服务器，而不会影响未指给的跨服务器体验，以及怎么由于一段时间缺乏相同的起始人线而造成了新的与老式服务器玩家的战斗力的发展而造成的不平衡。

例如，游戏产品已经推出了壹个大型扩展包。我想先进行灰度测试，以便第1至4区中的玩家可以首先体验新功能，和此同时，它可以防止玩家佩戴旧版本中不存在的设备并在跨性别环境中报告异常。通过根据操作需求进行分组，上述问题得到了最佳的化解。

6。自动战区分配机制

有针对性的跨服务器是指将在一定时间内参加跨服务器游戏模式的几个国家。它通常用于战区中的国家之间的战斗。如图所示，需要在后台设置操作；一段时间后，随着球员的损失，操作需要根据战斗力调整战区，这需要对操作人员的高标准。

调整后，可以自定义基于战区的每个跨服务器类型以调整时间间隔。在时间点， （）系统将根据整个区域的主ACT战功率匹配自动调整，从而使操作员可以摆脱复杂的设置。

7。跨服务器断开机制

例如，由于网络条件，战场系统或团队地牢被断开。如果您再次登录后无法进入，它将严重影响战场的状况。顺风游戏也许会立即成为逆风游戏，而主要的DPS掉落的地牢也许无法通过，这种机制将弥补该领域的缺点。

支持的游戏模式

目前，大家可以支持任何游戏区域的玩家，以在任何跨服务器服务器上体验游戏功能。例如，已经实现了跨职务团队地牢，跨服务战场，跨服务国家战争，跨服务帝国城市战役，跨服务器资源战争，昆虫群入侵战争，跨服务伴游，采矿竞赛等。

它还支持玩家在该服务器上的服务器上进行互动，例如和其他地区的玩家聊天，添加兄弟，提供礼物等，以及国家拍卖行与世界拍卖行之间的跨服务器贸易。它甚至支持玩家前往另壹个游戏区域以拥有任何游戏体​​验。例如，第1区的球员传闻第二个区域正在举行新娘抢赛活动主题。您可以跑到2区观看与参加，还可以跑到任何区域的中央广场，以炫耀您的完美西装。

跨服务器在线数据

跨服务器的目标游戏包括战区中的国家游戏模式，昆虫群入侵，跨服务器伴游，采矿比赛，跨服务器帝国城市比赛，跨服务器国家战争等。如下图所示，大家可以看到该游戏模式的规则：每次启动比赛时，越野赛都会发挥玩家的浪潮。事件结束后，玩家就会离开。这4个跨服务器步骤支持7,600名在线玩家。

非目标的跨服务器游戏模式包括跨服务器团队地下城，跨服务器战场等，它们支持负载平衡，并可以随时动态增加跨服务器流量。这些游戏模式的规则是，您可以每日24小时在任何时间体验并输入，并且在线比较稳定。 8个跨服务器步骤支持28,000名在线玩家。

技术架构

下图是跨服务器通信拓扑图，该图属于整体体系结构的核心部分。有关此部分的描述，请参阅图表：

我将密切关注整体结构的说明，并在随后的文章中和您同享。请注意建筑官方帐户。此外，该建筑进行了验证与测试，并测试了近20,000套服务器连续运行的服务器，包括“天堂中的魔术财富”，“ the ”，“地球震动”，“骨头精神的三场战斗”，“英雄之王”，“英雄之王”与“神和神”。

作者的说明

Jiang 从事游戏行业已有8年了，并且一直是许多游戏项目的主要服务器与上海服务器的负责人。注意游戏服务器架构与优化，监视与预警，智能操作与维护，数据统计与解析等。