SLG是重生态边界和导量策略的游戏，游戏到了中后期，为了维护玩家的新鲜感，扩大社交范围，提升留存和付费。会伴随各种各样的跨服玩法。其中以KvK(Kingdom vs Kingdom)持续时间最长(一个月左右)，最为复杂(玩家可以在KvK中参与城建、活动、联盟等各种玩法，与原服的体验很接近)。本文以KvK为出发点，聊聊关于SLG跨服模型的一些实践和思考。
在此之前，有必要对游戏中常见的跨服、合服、迁服几个概念进行区分:
- 跨服: 生态的摩擦和碰撞
- 合服: 生态的融合和重组
- 迁服: 生态的流动和微调
KvK跨服战场活动的简单示意图如下:
对玩家而言，体验最好的KvK玩法应该是轻量的，即玩家可随时自愿加入和退出，KvK战场活动持续期间，原服和KvK服都可以有玩家在玩。并且玩家切换战场的成本应该最小化，如联盟关系、活动进度、邮件、聊天等数据都应该尽可能保留。
以下聊聊我们在实际项目中，对KvK跨服的三种理解(领域模型)和实现，并简单以Model1，Model2，Model3区分。
Model1 将KvK实现为飞服
服务器框架早期基于一个依赖赛季合服(冷数据处理)进行KvK的项目，因此框架早期并未对跨服模型做过多考虑，单个服务器的活动、联盟、地图、城建相关数据，均内聚在一个Game节点上。在之后的项目开发到中期的时候，发现想要实现竞品级别的KvK(尤其是保留活动和联盟数据)，成本非常高。因此有的项目综合考虑，选择了通过玩家飞服的方式来实现KvK。这种思路的核心是将KvK战场看做一个完整的服务器生态(Game节点)，在玩家进入KvK战场时，需要进行数据清洗、剥离、迁移和恢复:
- 玩家数据: 剥离打包原服玩家数据并迁移到新服，如果想对原服生态造成的影响尽可能小(如想保留一份玩家数据镜像在联盟、排行榜等系统，避免原服快速过于”冷清”，或者是想管理一些原服强相关的玩家数据)，需要谨慎处理数据的清洗、迁移和合并。另外玩家在原服地图上是消失的，避免产生玩家交互引发数据变更
- 活动数据: 对活动数据做剥离和恢复(尤其是个人活动)，对于非个人活动而言，由于各服活动投放内容和进度不一样，很难跨地图保留(但可以回原服之后恢复)。并且由于活动本身的多样性性和灵活性，这个过程很容易产生各种BUG
- 联盟数据: 联盟数据与各系统的耦合较重，很难扩展为跨服联盟，因此玩家进入KvK服后，联盟关系会丢失，玩家在KvK服需要新建联盟，但为了保留原服生态，玩家在原服的联盟中会存在一个”镜像玩家”，同时也让跨服玩家回来(经过数据合并)也不需要重新加入联盟
- 服务器关系: 从玩法上而言，各个玩家并不算是真正迁入了KvK服(玩家所属服务器仍然为原服，否则很难制造生态摩擦)，因此玩家身上本质有两个字段，原服和KvK服，部分业务逻辑需要围绕这两个字段特殊处理，如登陆流程、两个全服聊天频道等
- 其他功能: 如聊天、邮件、以及其他需要单独跨服的功能，都需要单独评估，做数据剥离迁移
Model1示意图如下:
这种方案的优势:
- 延迟跨服决策，前期开发效率高
- 单服大部分业务数据都在单节点内部，数据一致性高，并支持滚动部署(单个服务器只停服几分钟)
劣势:
- 对跨服玩法的原生支持比较差，如部分活动数据，联盟关系这类数据很难保留
- 基于各种考虑，最终的实现可能并不是纯粹的数据迁移，而是原服和KvK都有部分玩家数据，需要谨慎处理数据的清洗、剥离和合并
- 之后每添加一个(或想要从已有玩法切换为)跨服玩法，都要单独考虑数据的剥离和迁移，开发成本高，且容易产生各种BUG
- 对于其他更轻量的跨服地图玩法，如GvG(持续一小时左右的地图副本)，需要额外做跨服地图副本或迁服机制，无法复用KvK服逻辑(没必要做数据迁移)
Model2 将KvK实现为跨服
鉴于Model1.0的一些经验，也有项目开始提前规划对跨服业务进行重构和拆分，即将联盟、活动这类跨服系统(需要在跨KvK战场时保留的系统)从原服抽离出来单独维护。如此玩家在进出KvK时，可以保留活动和联盟数据，同时玩家数据迁移也更轻量。
Model2示意图如下:
这种思路的主要考虑点:
- 跨服活动: 解耦活动系统，支持多个服务器可以参加同一个活动(可以考虑实现为KvK服的活动，或者参与KvK的Server Group的活动)
- 跨服联盟: 解耦联盟系统，支持一个联盟的玩家可以处于不同的服务器上
- 数据迁移: 仍然要考虑玩家数据(主要是养成相关)剥离和迁移过程，及其性能、数据一致性、服务器关系等
- 架构设计: 如数据共享、依赖关系、网络拓扑、负载和部署策略、数据一致性等
优势:
- 相对完整的跨服功能支持
- 数据迁移更轻量
劣势:
- 需要较早地规划业务设计和解耦(尤其是需要跨服的功能)，对于业务已经成型的项目，还考验渐进重构的能力
- 这套思路有点往大服方向走，因此在前期开发效率、部署更新流程、数据一致性方面，也要多做考虑
- 对于更轻量的跨服地图玩法，仍然需要额外实现一套地图副本机制
Model3 将KvK实现为跨地图副本
在Model1和Model2的实现中，主要将KvK服理解为一个相对完整的生态，技术上也用独立的服务器进程来实现。
打个可能不是很恰当的比喻，KvK就像是车主因为某些原因，不得不换辆车:
- Model1: 为车主尽可能把车上装饰物和随身物品打包(数据剥离和迁移)好
- Model2: 将车上的更多影响用户体验的组件，如方向盘(联盟系统)，座位(活动系统)，提前规划为可拆卸替换的(跨服系统)，这样用户在换车的时候，不会感到不适应
而Model3的想法，是重新审视车主需求，即他为什么要换车。可能只是车胎没气了，那么对症下药，换车胎就行了。回到KvK来，KvK的本质是创造一个跨服临时战场，以激活后期生态(而不是合并后期生态)，刺激付费和留存。因此，KvK的本质不是跨服，而是跨地图副本。
Model3图示如下:
注: 联盟、活动、养成可以选择部署在一个节点上(数据一致性和开发效率更高)，也可以部署在不同的节点(如有真正的跨服联盟需求)，但部署边界不等于业务边界，联盟、活动、养成这些系统，从业务设计上应该尽可能解耦，提升可维护、可测试、可扩展性。
Model3模型核心思路:
- 地图副本: 将地图和养成、联盟、活动等玩法解耦，原服大地图也通过副本机制来实现。除了活动和联盟，其他系统可能需要围绕地图进行调整，如排行榜，邮件聊天组，天下大势，养成系统(如果不同地图的养成线有差异)等。MapID和ServerID将是两个不同的概念，一个ServerID的玩家可能在不同的MapID，一个MapID的玩家也可能来自于不同的Server
- 跨地图联盟: 联盟本质不再需要跨服，只需要支持一个联盟的玩家可能处于不同的地图副本上(有不同的势力范围和联盟建筑)，这个要比跨服联盟实现起来更简单很多，也不需要额外的联盟节点
- 跨地图活动: 活动支持跨地图也比跨服更简单。真正的跨服活动，可以按照Map Owner(地图专属活动)，Cross Wrapper(轻度跨服活动)，ServerGroup Owner(重度跨服活动)等多种方案来扩展
- 数据迁移: 玩家的KvK战场切换，本质只是地图切换，只同步极少量地图需要的初始化数据即可，无需再迁移玩家、联盟、活动等数据
如果我们沿着Model2的思路，将Model1切换KvK服要保留的联盟、活动、养成系统这些全部剥离出来，最终可能会发现，唯一不能保留，真正要切换的(车主换车的原因)，只有地图。而联盟、养成系统这类玩法，也并不是真的必须要支持跨服，而是只需支持跨地图。Model3是一种以终为始的方案，是对领域知识充分消化的结果。
优势:
- 进一步精化了领域模型，解决了Model2一些领域模型不恰当导致问题，如需要剥离的跨”服”业务过多、玩家的服务器关系问题、原服和KvK服的活动冲突、KvK服不应该创建联盟、KvK服的动态生命周期等问题
- 用同一套方案处理原服地图、KvK、GvG等玩法，开发效率、复用性、健壮性方面都有优势
- 由于原服地图也拆为了副本，因此想要实现类似飞服(A服玩家可以飞到B服地图上去PK)这种玩法也比较容易，和跨KvK副本是一套机制
- 地图副本可以动态开启，灵活负载，更能满足SLG跨服常态化、轻量化、自动化的趋势
劣势:
- 拆分地图的技术难度，包括性能、数据一致性、依赖关系、部署策略，以及各种异常下的容错与故障恢复等等。尽管地图副本在MMO中是非常成熟的概念，但SLG的离线策略、实时战斗、无极缩放等特性，为这套机制带来了新的内容和挑战
- 需要持续和策划围绕地图副本的概念对各业务系统做必要的调整，持续迭代业务模型
本文并不扩展讨论各种技术实现细节，更多地从业务领域的角度来讨论SLG跨服的实现思路和常见模型。模型没有优劣，只有是否和业务匹配之分，模型如架构，是设计的结果，也是权衡的结果。SLG跨服这类复杂业务而言，前期业务模型设计的优劣将很大程度决定后期架构的可扩展和可维护性。