跨服 网游的跨服玩法是如何实现的？“跨域体系”架构设计思路

虽然游戏市场竞争激烈，产品格局变化较大，但游戏行业一直处于稳步增长阶段，无论是在已经开始显现苗头的终端游戏、页面游戏、手游还是HTML5游戏。可以预见，MMOARPG游戏仍将是引领市场的主流趋势，贡献大部分流水，市场仍在以高品质的产品出现。研发团队从未停止对MMO游戏的探索，从支付方式的改变到主题的多样化，下一个时代的视觉效果，以及更成熟的游戏玩法和数字系统。本文主要研究跨服务游戏的探索与实现。

根据2016年《中国游戏产业报告》的数据，随着游戏人口红利的逐渐消失，获取用户的成本依然居高不下，近几年至少增加了十倍以上。目前，页面游的平均导游费用为10~15元/人。手游在15~20元/人，其中在IOS上的费用是30~50元/人。“洗”用户模式效果变弱，用户流失严重，我们先来看看滚动游戏的局限性。滚动洗涤模式有以下缺点:

但是内存占用往往会突破警戒线90%。一旦发现系统分配的内存不足，就会触发自我保护机制进行OOM killer，因此每个JVM进程都需要预留大量的内存，每次维护都要通过脚本修改内存，比较麻烦。

内存占用状态如上所示。服务器更新维护后，内存占用一直上升到一定值，除非下次维护或者系统触发OOM杀手，否则不会回收。

基于阿里JVM 1.8，只要打开-XX:+DeclaseHeappages，CMS就可以在不重启应用的情况下将未使用的Heap返回到系统的物理内存中，这样我们就不需要为JVM预留大量的空，也不用担心被误杀。

以一款处于内测阶段的游戏为例。使用了ALI JVM后，64内存的机器终于向24个新区域开放了。与之前的64G内存的机器相比，单个区域的成本会节省62.5%的机器资源，印象非常深刻。完美解决了内存不足的问题，大大节约了成本。在此，我要感谢阿里巴巴云团队和@顾琨提供的黑技术。如果需要，可以申请成为种子用户。

上图是使用阿里JDK后的锯齿效果。空闲内存会被系统定期回收，这在Oracle JVM中很难实现。

5.服务器分组机制

无向跨服是指任何游戏区域的玩家都可能匹配在一起玩游戏的体验，比如跨服战场，比如跨服副本匹配，如图(分别是服务器分组前后)。

如何在不影响非定向跨服体验的情况下，选择几件衣服做游戏正式区的灰度衣，如何解决新旧衣服玩家战力不在同一起跑线上发展带来的不平衡问题，一度纠结。

比如游戏产品推出了大资料片，想先做灰度测试，让1~4区的玩家先体验新功能，同时可以防止玩家穿上老版本不存在的一件装备，在跨服环境下报告异常。根据操作要求，分组完美解决了以上问题。

6.自动剧院分配机制

定向跨服是指几个国家在一定时期内会参与跨服玩法。它经常被用来在剧院里进行国家间的战斗。如图，需要后台操作；一段时间后，随着玩家的流失，运营需要根据战力调整剧场，对运营人员的要求也比较高。

调整后，基于战区的各种类型的交叉服务可以定制调整时间间隔，全局服务器系统会根据该时间点整个区域的主动战力匹配情况自动调整，使运营商从复杂的配置中解脱出来。

7.跨服务断开连接重新连接机制

例如，由于网络条件，战场系统或团队的副本被删除。如果重新登陆后不能进入，会严重影响战场态势。顺风局可能很快就变成逆风局了，主DPS掉的副本可能过不去。这个机制弥补了这个缺陷。

支持的游戏性

目前我们已经能够支持游戏区任何玩家都可以去任何跨服务服务器玩游戏功能的体验。例如，实现了跨军种团队复制、跨军种战场、跨军种国战、跨军种帝都竞赛、跨军种资源战、群体入侵战、跨军种护航、矿业竞赛等。

它还支持玩家在这项服务中的跨服务交互，比如与其他地区玩家的无缝交互，添加好友和赠送礼物，以及国家拍卖行与世界拍卖行的跨服务交易。甚至支持玩家穿越到另一个游戏区做任何游戏体验。比如1区玩家听说2区西装正在举行亲偷活动，可以去2区观看参与，也可以去任何一个区的中央广场炫耀自己最好的西装。

跨服务在线数据

面向跨服务的游戏包括剧场国家游戏、群体入侵、跨服务的飞镖投注、矿业竞赛、跨服务的帝都竞赛、跨服务的民族战争等。如下图所示，我们可以看到这个游戏玩法的规则:每次活动开始，都会有一波玩家跨服务进来，一旦活动结束，玩家就会离开。四个跨服务流程支持7600个在线玩家。

跨服非定向游戏玩法包括跨服团队副本、跨服战场等。它支持负载平衡，可以随时动态增加跨服务。这些游戏的规则是你可以24小时随时体验和进入，在线相对稳定。八个跨服务流程支持28，000个在线玩家。

技术架构

下图是跨业务通信的拓扑图，是整体架构的核心部分。参见图表了解该部分的描述:

总结

该架构已通过《大闹天宫OL》《诸神黄昏》《暴风王座》《惊天动地》《孙悟空三打白骨精》《英雄主》《俯视上帝》等近两万组服务器验证。，以及团队的技术积累。

本文从当前游戏市场发展的背景出发，提出了设计一个自由交互的“跨域系统”的必要性，进而考虑了实现跨业务架构过程中的设计目标、原则和技术难点，实现了一个用于跨业务通信的高吞吐量RPC通信框架，该框架经历了被动拉模式带来的坑和改为主动推模式带来的便利。此外，在消息组播、流量、消息序列化/反序列化、服务器分组、剧场自动分配、断线重连等多个方面对架构设计进行了分析和深度优化。最后，通过在线实践验证了该架构的可行性，提供了强大的数据支持，整体性能稳定流畅。

关于整体结构的介绍，卖了吧，后续文章和大家分享。请关注建筑的微信官方账号。

作者简介

姜桂龙，从事游戏行业8年，担任各种游戏项目服务器负责人，上海於陵服务器负责人。重点关注游戏服务器架构及优化、监控预警、智能运维、数据统计分析等。