我们在进行服务器性能测试的同时也需要关注 服务器的架构 和 容灾需求，这样才可以保证服务器能够既满足性能需求的同时又保证服务器能够稳定运行和保障数据安全。本篇文章记录一下 容灾测试 相关的知识点。
1、容灾指标
- 一个好的服务器架构在设计时不仅需要根据游戏类型和业务需求来评估，还需要将 容灾 考虑进去，以下罗列了一些 容灾 相关的指标（非完全）：
- 节点不能存在单点故障，即某个节点宕机后不影响其他节点的正常运行，当宕机节点启动后，可以重新连接至其他节点并正常处理业务功能。
- 节点需要支持 可快速拉起，即某个节点宕机后可以被快速重新启动，并且业务功能和关联的节点能够正常接入而不受影响。
- 服务的数据丢失不可超过5分钟，且 核心数据（或关键数据）不可丢失，必须及时入库，最好还可以支持通过日志或者其他形式的记录进行数据的快速恢复。
- 节点最好可以防单点风险，即至少需要主从备份或者集群来规避单点风险，当这个节点宕机后，还有其他的节点可以来担任这个节点任务功能，而不会阻断整个业务。如果节点支持快速拉起也可以防单点风险。
- 节点最好支持 热更新，可以在用户无感知的情况下进行异常数据或者功能的修复更新。现在很多游戏都怕用户流失，也许一次停服更新就会有一批用户流失。
2、架构与容灾
集中式架构
服务器只有一个进程，所有的逻辑都在单个进程里面处理，这是早期的游戏服务器架构。一旦出现严重的Bug可能导致服务器崩溃或者数据丢失，那么将影响到全部的玩家，因此风险非常高。另外由于是单进程的，全部逻辑都在一个进程里处理，承载人数也不会太高。
分布式架构
分布式服务器架构将不同的业务放在不同的节点上面处理，这样就可以避免一个节点故障导致全部业务无法处理。分布式服务器架构的设计会根据不同的游戏类型选择不同的方式，但总的来说是会根据业务人数承载和 容灾 要求进行设计。因此上面这副图只是想表达一下分布式架构的节点情况，下面举例简单介绍一下，由于这块其实是公司的内部技术核心，因此我也是随便画的一些图，大家别介意！
MMORPG类型的架构图
客户端连接这个区的网关，由网关将数据转发给逻辑服（游戏服），逻辑服对场景中战斗和其他个人业务处理后同步给客户端。这里的逻辑服也可以是一个集群，客户端无需知道自己具体在哪个进程里面。但如果需要处理多玩家之间的交互业务时就需要用到公共服，例如组队、公会、聊天、匹配，因为玩家在不同的进程里面，逻辑服需要找到这些玩家具体在哪个进程以便处理业务。DB服则负责将每个逻辑服的数据读写到数据库。上图中单个逻辑服宕机，不会影响其他逻辑服的玩家体验游戏。其他服也是一样。当然这里说的比较简单，真正的逻辑其实非常复杂，而且很有可能还会引入更多的节点来确保整个架构能够协作完成任务。
ARPG类型的架构图
对比MMORPG的架构图发现这里多了战斗服集群，ARPG游戏会比较关注的战斗中的打击感，对战斗表现这块要求比较高，因此将战斗业务独立出去进行业务解耦，也可以提高整体的承载能力。另外一般ARPG游戏都是通过组队进入副本战斗，当玩家进行副本战斗时，其实只是跟战斗服进行交互，而不会对其他服产生影响。单个战斗服的宕机只会让这个进程的玩家退出战斗，其他战斗服的战斗则可以正常进行。另外如果战斗服是一个更大的集群，全部区都共用这些节点，那么可以很好的利用资源和跨服战斗的实现。
3、总结
我们在性能测试的时候需要去理解服务器的架构，知道不同的节点承担的功能业务，这样在设计压测场景时才知道会对哪些节点产生性能压力，好进行性能评估。另外我们也需要考虑服务器是否满足容灾需求，这样才能更好的判断服务器是否能够上线完成使命。 服务器架构需要很深的学习和理解实践，我的能力也只能简单的进行表面的总结，希望对大家有帮助。
源自公众号 游戏测试开发