看完这篇技术干货，说不定能帮助你的产品避开炸服雷区。
《使命召唤手游》服务器主程序Jerry
以下为分享内容，经葡萄君整理，有调整和删节。
大家好，我是Jerry，来自天美J3工作室，现在担任《使命召唤手游》服务器主程。很高兴有机会和大家聊一聊有关服务器架构设计的话题。
今天这个话题，想必大家都会有所关注：游戏上线后出现炸服，可能是因为哪些原因？在游戏设计之初，我们需要注意哪些问题，才能避免或减少炸服发生？
那什么是炸服？我相信大家都听说或经历过这样的情况，游戏刚开服的时候，由于玩家特别热情，可能出现登录不上、频繁卡顿，甚至反复重连的情况，严重时可能会出现数据丢失、回档，而且这些问题往往不能快速得到解决。
从服务器设计的角度看，这些问题一般和下面这些因素有关：服务器架构设计不到位、平行扩容和负载均衡有缺陷、单点容灾考虑得不是特别完善。
一个服务器架构设计不当的案例
我们先从一个案例讲起。这是某款游戏的服务器架构图，我们做了适当的简化。
这款游戏采用了分区分服的部署方式，架构图左边其实是一个区，主要包含登录授权服务，以及连接管理和游戏逻辑。同时，它有一个所有分区公用的对局管理模块，而它的游戏逻辑放在了战斗逻辑进程中，也是各个分区共同使用。
在功能层面，这款游戏的连接管理主要负责玩家的连接登录，游戏逻辑里包含了数据管理，角色养成等业务逻辑，而对局管理包含组队、匹配、开局逻辑等等，战斗逻辑主要负责局内战斗。
这款游戏在部署上有一个很有意思的点，开发团队认为这款游戏单区承载能力足够，因此打算一个大区用一台高性能物理机、主游戏逻辑用一个进程就搞定了。
这样的架构设计存在什么问题？首先业务耦合度特别高。他们在架构图里虽然把连接管理和游戏逻辑分开了，但实际上这两块在同一个进程中。连接管理和游戏逻辑放在一起可能会导致什么问题？
对于这款游戏来说，游戏逻辑里包含了很多游戏，所以业务逻辑会特别重，出现Bug的概率特别高，如果在线上运营，游戏逻辑可能需要频繁更新，如果将其和连接管理放在一起，会导致更新出现各种掣肘，一旦处理不当，就有可能导致玩家掉线。
其次，他们的对局管理模块包含了很多功能，比如匹配、开局、负载管理等等，由于全局只有一个对局逻辑，所以可能会存在单点容灾的问题。而对局管理和游戏逻辑放在一起，平行扩容方面也会存在问题。同时，由于他们把负载管理和匹配之类的功能放在同一个进程里面，在负载管理上可能也存在一些缺陷。
拓展一点说，在分区分服部署模式中经常会碰到另外一个问题：由于开发者认为游戏是分区分服的，每个区的玩家数量相对会比较少，所以他们只部署一个进程来搞定，从单区的角度来看形成了事实上的单点。
而这款游戏全服共享的「对局管理」只有一个进程，我们认为如果单进程能支撑所有的请求，那么至少应该设计成主备部署的架构。但在游戏上线前，你拿不准用户量会达到什么样的程度。万一你的游戏成了爆款，这种单纯的主备方式有可能满足不了实际的需求。因此，我们推荐将其设计成可以平行扩容的方案。
说到平行扩容，刚才那种事实单点是无法支持平行扩容的。对于这个项目，他们负责服务器设计的同学说，单区承载目标是5K-6K，但随着开发推进，游戏业务逻辑越来越复杂，通过压力测试发现，在这种逻辑架构下，游戏逻辑进程承载的极限只有3K。由于这种架构不支持平行扩容，游戏上线时很有可能发生炸服。
这款游戏的对局管理为什么不支持平行扩容？因为对局管理进程中包含的功能太多了，这些功能在同样的业务逻辑下，对性能的要求可能不一样。如果想要对其中某个功能进行扩容，在这种把所有功能都集成在一起的设计中显然做不到。
除此之外，这款游戏还存在负载均衡的问题，这个和架构设计可能没有太大关系，我们发现，这款游戏的对局管理存在算法缺陷。因为他们没有考虑到一台机器的瞬间负载能力，在新加入「战斗模块」机器时，可能发生雪崩。
因此我们设计负载均衡调度算法时，除了定时上报负载外，一定要设计异常上报机制，负载均衡算法必须能及时处理异常情况，并且实例——对于这款游戏就是战斗模块——必须要有主动熔断机制，避免出现负载本身已经承受不住时，负载调度模块还不断发送开局请求，当然这需要负载调度模块和实例之间互相配合。
同时，我们还需要设计提前预判机制。举个例子，目前我只剩下10%的负载，下一次上报时间可能在3秒以后，如果这3秒内调度模块发送了过多请求，很有可能会导致雪崩。
总体看下来，如果这款游戏以这样的服务器架构上线，万一玩家特别热情，刚才提到的任何一个问题爆发，都有可能引发「炸服」。
在这个案例中，我们指出了很多问题，也相应提供了解决方案，但项目组反馈说，可能没有办法做这样的修改，因为他们在设计之初就把服务器架构限死了，并且服务器底层架构缺乏相关的支持。
那我们在架构设计之初，能不能做一些预见性的设计，规避这样的问题？
服务器架构设计和技术选型怎么做？
接下来我想谈谈游戏服务器架构设计和技术选型要怎么做。
如何选择区服模型？
先看区服模型。一般来说，游戏部署方式分两种，分区分服和全区全服。下图左侧是分区分服的简化模型，右边是全区全服的简化模型。
分区分服模型一般在前端会有一个导航模块，用于区服选择；区与区之间隔离，它们会有各自的DB。区与区之间如果需要通信的话，往往会使用跨服模块。对于一些需要跨服的功能，比如包含所有区的排行榜，可能还会为此增加一个公共DB。这些是分区分服的主要特征。
而全区全服没有分区的概念，但它会有一个中心通信模块，并且整个大区在逻辑上只有一个DB。
这两种部署方式对比下来有一个很特别的现象。从业务逻辑来看，分区分服架构里每个区只画了一个「World」，而全区全服画出了很多业务进程。
也就是说，由于分区分服架构下，大家认为每个区玩家数量比较少，也有可能受限于开发时间、开发资源、技术储备等原因，没有把业务逻辑拆分得足够细，因此一般只有一个「World」，或者把游戏逻辑放在少数几个进程当中。
其实这两个模型并没有明显的高下之分，在实际选择的时候，主要是从业务需求角度出发来选择。如果业务本身存在合服的需求，那采用分区分服的模型自然更加合适。
不过我们看了很多采用分区分服模型的游戏之后，有一些建议：
作为分区分服，其实也可以吸取全区全服的设计经验，避免分区分服原本存在的一些问题。
比如分区分服中单机容量可能受限，我们建议要适当考虑平行扩容相关的设计。像刚才说的单个「world」做平行扩容比较困难，是不是可以把核心逻辑拆分出来？
很多时候，我们会看到分区分服采用真实的物理分区，DB也做了分隔，在合服迁移的时候，成本就相当高，那是不是能采用虚拟分区的方式来处理？在虚拟分区下，我们可以采用组合key，即用玩家的分区ID和Player ID组合，区分他们所属的区服，这样合服时不需要做物理上的数据迁移。
另外，我们需要完善自动化工具，因为分区分服必然会遇到合服的问题，合服可能需要处理数据上的、运营策略上的各种各样的问题，而在设计方案之初完善自动化工具，能够避免早期的架构设计或数据结构的设计，没办法很好地支持自动化的问题。
从游戏服务器设计角度来说，我们建议，如果有可能的话，尽量采取全区全服的设计方式，虽然这对于整个架构设计要求更高，但它有以下几点好处：
首先，后续运营运维成本会比较低，因为它物理上只有一个环境，我们投入的运维人力更可控。
其次，全区全服可以共享机器。我们知道，游戏后台会有很多进程，但每个进程的资源消耗其实不一样。而我们虽然会有很多区，但做运营活动时，每个区参与的用户数量可能会有所区别。如果采用全区全服的方式，我们就可以共享机器资源。
当然，这也会导致对资源调度、动态扩缩容和容灾备份的要求较高。
如何设计全区全服的进程模型？
既然我们建议采用全区全服，那么在全区全服下，进程模型有什么特点？首先是Kiss原则，说白了就是让每个模块负责的功能尽可能单一，让各种模块互相配合，完成一个复杂的系统功能。
因此，在进程模型设计中，我们建议大家根据业务情况，将大功能解耦、拆分成多个进程。在拆分成多进程之后，需要设计一个统一的消息通信。
拆分成多进程有哪些好处？我们先看看如果不拆进程，会出现什么问题。
首先，不拆进程不利于协同开发，因为系统耦合度太高。
现在一款游戏大作，开发团队动辄几十人，多则上百人，其中负责后台开发的团队也有大几十人，这么一个系统，大家都在同一个进程里面写，责任不明晰，出了问题很难判断问题在哪。
其次，后台很多系统、子系统之间性能有差异。比如登录模块在10万PCU下所需的进程数、机器数，可能跟负责对局的模块不一样，聊天模块、活动子系统之间也存在性能差异。如果不拆分进程，就不能做到按需部署，只能很暴力地把进程按某种倍数扩容，这必然会浪费机器资源，甚至有可能增加机器、部署更多进程，都解决不了性能瓶颈。
第三，现在很多游戏都会寻求出海，出海必然会存在地域差异，如果想要提供好的游戏体验，就必须考虑就近部署的问题，如果进程不拆开的话，就近部署其实比较难做。
第四，在容灾上会受到一定限制。因为我们没有把关键子系统拆分出来，而人力成本、机器资源、项目资源都有限，只有将这些有限的资源投放到关键子系统上，才能让我们获得更大的收益。
那么要怎么拆分进程呢？在腾讯内部，有个原则叫「大系统小做」。一个大系统具体要怎么拆分？标准有很多，我们通常会从功能需求、处理流程和通用组件这几块来拆分，比如功能可以拆分成好友、公会、邮件、聊天这几个部分。
如何解决拆分进程可能带来的问题？
同时要注意，拆分可能会带来一些问题。如果我不拆分，就只有几个进程，拆分完以后，可能部署上又使用了全区全服，系统就会变得非常庞大，用到的机器也会非常多，那么监控要怎么做？
我们原来在一个进程内，通过函数调用就解决的通讯问题，变成多进程之后，要用什么方式进行通信，协议要怎么定？
在部署方面，原来只有几个进程，我们把物理机拉过来往上面一丢就可以了，现在这么多的进程，哪些进程应该部署在同一台机器上？它们的数量配比应该是什么关系？系统之间要怎么协作？出了问题要怎么定位？这些都成了问题。
今天我打算就前两个问题和大家进行探讨。
系统之间要怎么样进行通讯？在设计之初，我们要有一个比较好的底层设计框架，也就是刚才架构图里面的Router模块。这个底层框架要负责做系统功能解耦，还要作为各个子系统之间的路由器，并且为容灾和扩容提供基础，所以它本身必须是无状态的。如果它存在太多有状态的数据，那它本身的平行扩容就会成为问题。
同时，因为我们知道不同的业务逻辑、业务特性、性能要求会导致不同业务模块在路由策略方面会有各自的选择，所以它还要支持多种路由策略，这对于我们的平行扩容、容灾备份非常关键。
如何选择后台的路由策略？
接下来我们看看后台的路由策略有哪些？应该如何选择？
我们经常用到的路由方式可能就下面这5种，取模、一致性哈希、随机分配、主备和备份。这些路由方式应该怎么选？
通用原则是对于无状态服务，就是说它只是处理流程，处理完以后不需要保存玩家数据的，我们一般使用随机分配的方式。随机分配有什么好处？如果某台机器挂掉了或网络出现故障，它对后续流程的处理其实不会有太大影响，最多只影响当前处理的逻辑。
取模和一次性哈希一般在有状态服务中使用，因为它需要保持一些数据，这些数据可能在下一步操作中用到，或者某个处理流程可能需要二步或者三步，或者有两、三个协议的请求才能完成，那我们肯定希望这两三个请求放到同一个进程中处理，不然可能会发生问题。比如说对特定的玩家，从结算来说可能是对特定的房间，它们必须要能够路由到一个固定的进程上。
此外，其实还有一种情况，我们工作中发现它有需要在同一个进程中处理，比如对同一个玩家的同一张表进行写DB操作的时候，放在同一个进程中能避免出现写冲突。
而对于「单点」服务——为什么会出现单点？可能是为了避免出现决策困难。比如进行全局负载管理的模块，它本身的性能要求并不是问题，因为它的整体请求数（比如开局请求数）存在一定上限，用一个进程就可以搞定。同时，如果这个进程中做负载管理和分配策略都非常好做，那我们就希望在全服中用一个进程去搞定。
对于这种情况，如果这个进程挂了，或这台机器挂了，我们就不能正常进行下去，这时候就需要用到主备方式或备份方式进行处理。
这里的主备方式和备份方式有什么区别？在主备方式中，两台机器都会接到请求，但同一时间只有主机器进行服务，而对于备份方式，一般只有主机器挂掉以后，备份机器才会进行服务，平时它可能完全不接受这种请求。
这是有关路由的选择，那路由还需要具备哪些特性？
从业务层面来说，我们尽量希望它无感知。这有点难度，但尽量做到。
举个实例，我们写DB时，DB的代理进程通常用的是随机分配的路由策略，因为它是无状态的。但后来我们发现某一段时间里的超时请求特别多，为了查问题，我们临时把DB的路由方式改成了一次性哈希，来定位数据发送到了哪一台DB的代理服务器上。
由于我们在开发的时候，没有假设服务器采取的路由策略，在设计业务逻辑时没有施加限制，因此在实际运营中，我们可以比较容易切换路由策略，处理一些特殊场景。
同时，路由模块还要能够自动处理网络异常，并能识别业务的通讯异常，这才能实现容灾的功能。
上面说的是底层通讯的模块，那部署的时候要怎么做？我们开发时受机器资源的限制，可能用一台机器搞定所有的问题，但游戏实际上线时，我们可能会使用了几十台、上百台甚至上千台机器，怎样把平时的开发和上线部署统一起来？这对于自动化部署能力要求比较高。
要做到自动化部署，我们要设计自动化部署脚本。而从实际经验来看，我们在架构设计方面要有一些先期的考虑。
我们比较推荐大家采用集装箱式的部署。怎么理解这个概念？
不同业务进程的功能和性能可能不一样，有些业务进程是CPU消耗型的，有些业务进程则是内存消耗型的，如果把它们搭配在一起，就能最大程度地利用到机器资源。
我们上线时一般会对同时在线人数进行预测，比如我们认为游戏能做到同时在线100万，但上线之后我们发现同时在线可能要到200万，甚至250万，这时你临时计算进程要扩容多少，是不是简单地按100万到200万去翻倍？这种简单粗暴的方法不一定能解决不了问题，还有可能会浪费掉更多的资源。
因此，在设计之初，我们就要计算不同业务进程的负载能力，区分繁忙的服务和相对空闲的服务，再根据资源消耗情况分配成各种组别，判断不同组别能支撑的用户量，比如这一组能够支撑2万人，那一组可能支持5万人，在实际操作中根据用户量进行扩容。
同时，我们希望做到逻辑部署和物理部署分离，这样游戏上线时可以在实体机器和云上机器中灵活选择。另外，我们还会把实际的IP地址转换成抽象化的业务IP地址，在腾讯内部会采用一种叫做 tbusid 的方式。
平行扩容和容灾要怎么做？
接下来看看平行扩容和容灾具体要怎么操作。
下面这个案例采用了分区分服的架构，评论服全区共享，开发团队认为评论量可控，所以评论服只部署了一个评论模块。在这个架构中，每个大区的玩家都通过公共的路由模块登录评论服进行评论和聊天。值得一提的是，这款游戏计划在海外市场上线。
这种架构有什么问题？首先容灾怎么做？如果评论服挂掉怎么办？其次，开发团队先期认为评论量很少，万一实际评论量太大呢？再然后，这款游戏计划在海外部署，那不同国家和地区的舆论风险怎么控制？因此，这个架构不满足业务发展的需求。
这里有一些用来参考的解决方案，我们认为要允许平行扩容，并且风险要可控，就必须做分频道管理，所以增加一个频道的管理集群，这个频道的管理一般就是采用我们说的主备部署的方式，根据不同国家、地区或者主题分成不同的频道或评论区。
这种方式是不是真正解决了独立扩缩容的问题呢？看上去是，如果频道不够可以加频道嘛。但大家可能没有想到一个问题：
在这种架构下，玩家所有评论和聊天都通过各自大区，经过跨服路由到达各个频道，如果聊天的数据量特别多，对核心玩法和核心模块在消息和包量上存在冲击，如果后期要做运营活动，像以前的大喇叭、小喇叭、全服广播，以及现在可能会用聊天频道做「飞机票」（组队），就可能会遇到问题。
基于上面这些需求，我们希望服务器架构能更进一步。比如像下面这个架构一样，把玩家聊天的消息数据和信令分开，让玩家直接和频道相连，而玩家具体连到哪一个频道通过频道管理的方式去做。这样不管玩家消息量多大，都可以通过扩频道的方式解决。如果用户消息量太大，最多只会导致某个频道挂了或关掉，不会对整个游戏产生影响。
故障隔离要怎么做？
接下来讲讲故障隔离。一款游戏上线时，如果因为某些原因出现了一个Bug，一时半会还定位不出来，这种情况要怎么办？怎样快速屏蔽故障模块，不影响核心功能，故障恢复时还能及时通知到玩家？
我们希望在前端设计一个支持协议路由的模块，同时根据协议或者模块，区分关键流程和非核心流程，再进行区别对待。这样如果在某个请求或模块出现异常，而且短期得不到解决，我们能够尽快线上屏蔽，并知会到玩家，同时模块恢复之后也可以通知到玩家。
在线更新的异常处理怎么做？
还有在线更新的异常处理。此前我关注到有些项目采用了容器部署，更新方式是直接停掉旧的容器，将其替换成新容器，还有些项目更新大厅模块时，会导致部分玩家掉线。如果我们想保证玩家体验，这些都是不能容忍的。那在设计游戏的时候，要怎样避免这些问题？
一般来说，我们认为可以使用共享内存解决。不过，我们之前评审过一些项目，尽管它们使用了共享内存，但使用方式存在一些问题，比如有时把一些绝对指针地址直接存到共享内存里，一旦进程重启，共享内存就会失效。
现在游戏的线上更新，一般是做一些策划配置或活动配置的更新，所以我们希望进程能够有一个通用的支持reload操作的框架，不重启进程，只通过发一个信号的方式通知有些资源需要更新。
对于一些无状态的服务，我们可以考虑支持disable操作，也就是单独禁掉某些进程，比如现在同时有10个服务进程，在承载量允许的情况下，我们可以先禁掉三分之一，对其进行更新再进行灰度发布，这样可以做到不影响玩家的情况下做到线上更新。
削峰的两种常见情况
有时候，我们还需要考虑削峰。有些游戏会做准点在线的活动，特别是端游时代做得比较多一些，就是给在线玩家发送道具，鼓励玩家在某个时间点保持在线。
这对服务器内部的路由包量和流量影响非常大。我们接到这种需求要进行评估，系统能不能扛住？如果系统扛不住，可不可以考虑采用离线发放的方式？如果不能用离线，能不能使用旁路的方式？或者能不能将自动到账改成手动领取？这都可以变相进行削峰。
还有一种情况和配置相关，比如游戏运营会有很多活动配置，玩家也会有很多活动进度相关的数据。很多游戏希望在玩家登录的时候，为其展现各种信息，比如红点提示、活动完成进度什么的。他们希望玩家一登录就做大量的配置拉取，这可能会导致玩家登录流程过长，还会使得服务器的下行流量过大。
对此我们建议客户端采用缓存+指纹的方式，减少对于不变配置信息的拉取。从服务器和客户端交互的协议设计角度来说，我们希望把动态和静态的数据进行分离。
何为动态和静态？比如活动配置其实相对来说是静态的，可能在某个赛季或某个活动期间配置保持不变，而玩家的活动进度是动态的，这块数据其实相对会比较少。我们可以把这两块配置分离，在玩家登录的时候，如果活动配置没有发生变化，就只拉取他们的活动进度。
此外游戏经常会有一些更新，有时为了方便我们会希望直接通过服务器带下去，但其实可以考虑采用CDN来降低成本。
需接入第三方系统时怎么处理？
最后说一下第三方系统。游戏上线时不可避免要接入一些第三方系统，其中可能包括给运营、客服使用的业务受理模块，以及在线广告、支付等第三方系统。
接入第三方系统会存在一些问题，比如它的访问量不可控，比如我们不知道客服调用的频次，也不清楚如果用业务受理系统做web页面的互动，它的量级会有多少。而且第三方系统的协议有可能跟我们的协议不兼容的，在访问权限上也需要进行控制。
从我们的经验来看，建议大家用一个模块对第三方系统集中进行包装，做独立的部署和流控。同时，这个模块还负责做协议的转换及隔离。
这样相当于为游戏系统和第三方模块之间建立一道防火墙。如果第三方系统的流量突破上限，我们可以及时扩容，甚至一定程度地根据实际情况来屏蔽或停止第三方系统的服务。
当然，第三方系统有时会做一些升级的活动，或者性能有可能出现一些问题，如果我们有独立部署的模块，在这个模块做一些针对性的适配，就能避免第三方系统的问题冲击游戏的后台系统。
这些就是我今天分享的内容，谢谢大家。
