游戏核心逻辑设计 - 登录系统

游戏服务器结构演化

逻辑层和基础组件层分离

左边是一个简单的游戏架构，类似于《天天酷跑》，有很多客户端登录到一个服务器上，服务器只有一个进程。随着游戏变得复杂，逐渐演化到右边的结构，也就是对左边结构简单的做了一个分层，这里的world可以理解为逻辑服务器，就是承载游戏逻辑的，然后会抽象出连接服务器和DB数据库。抽象出来的好处是什么呢？例如同时做两个项目的话，其实两个项目很多情况下，它的区别仅仅在于这个world，也就是逻辑服务器这里，而连接服务器和数据服务器应该是可以通用的，这样的话只要做一套，就可以支撑更多的项目。所以这里分为两层，就叫做逻辑层和基础组件层之后，基础组件层是可以多个项目互用的，实际上在腾讯内基础组件层几乎是整个公司用一套的，就节省了大量的人力成本。

逻辑服务器是大规模异构分布式系统

国内的游戏服务器和国外的最大的区别是在：国内的游戏的逻辑是跑在服务器上的，客户端可能逐渐变成一个只是显示表现象的东西，所有牵扯到财产、玩家数据、校验等逻辑都是放在服务器上的，因此导致服务器的逻辑层越来越复杂，单个进程是根本没有办法处理的。

什么是登录系统

玩家通过客户端和服务器建立连接，在服务器各个进程上完成需要的账号和角色数据创建，并进入游戏场景开始游戏的过程称为登录。

搭建登录系统的装备工作

• 实现接入服务器（connect svr）
  简单的方式可直接使用socket完成
• 实现db存储（db svr + mysql）
  将玩家数据转化为db数据存入的过程中，需要独立出db svr，而mysql则作为后端的存储。
• 制定协议（protobuf）
  服务器之间的通信和服务器和客户端之间的通信

由于游戏不断的更新，服务器最终会演化成为一个大规模分布式系统。不同系统之间的进程也会相互通信，它们也需要协议。

为什么服务器会演化成为一个大规模分布式系统，以及作为分布式系统，登录在这个系统中的位置，实际上它处于一个中间层的位置。最底层是组件如接入、存取数据、日志记录等。上层是具体的玩法如副本、竞技场等。中间层则是一些处于上下层之间且可以支撑大规模玩法开发，同时向下可以让整个系统跑起来的类似客户端引擎，这样一个服务器引擎层的概念。

登录系统的基本流程

• 客户端和服务器之间建立或断开连接
• 用户登入或登出
• 创建或删除或修改角色
• 进入或离开场景

使用什么样的设计模式来实现登录系统呢？

状态模式 - 登录状态机

• 多进程分别维护账户登录状态上下文
• 通过网络消息驱动
• 分层状态机设计

简单的登录模型

这里有一个问题，这里为什么叫做引擎层却要跟玩法隔离呢？

游戏服务器大体分为组件层、逻辑引擎层、上层逻辑层。

简单的登录流程

• 消息驱动
• 多层状态机
• 分布式

简单的登录流程

顶层状态机

登录系统的性能问题

服务器物理性能边界：流程、CPU、内存、DB访问

互联网实际线上遇到的性能问题：

• 性能波动：玩家的大规模集中登录、群体传送
• 毛刺和雪崩

性能问题实例：集中登录和群体传递

• 流量
  svr->srv 玩家数据打包迁移
  svr->cli 视野信息同步
• CPU
  大量集中内存操作，若美誉偶平滑策略，就会发生毛刺。如果毛刺导致CPU 100%，就可能出发雪崩。
• 内存
  核心进程聚集大量中转数据
• DB
  集中数据存储

开发效率与高可用性

实际项目大规模并发问题

• 破窗理论：底层框架系统的示范和放大效应，如登录层和逻辑层混合。
• 实现隐藏：分层机制、消息机制

高可用性

• 墨菲定律：如物理机宕机、Scene宕机、DB宕机、网络堵塞、DB过载。
• 基本原则：出错可以回滚，支持重试。

总结

• 游戏服务器基本组成

1. 基础组件：连接、存盘、日志
2. 逻辑服务：分布式多进程系统

• 登录是一个多层分布式状态机

1. 登录的基本流程和状态
2. 需要考虑各种边界情况

• 底层系统要考虑性能、容灾和团队开发问题

1. 四个物理性能边界，毛刺和雪崩可能的产生点。
2. 100%一定会出问题，控制出问题后的影响范围。

• 自己动手实现简单登录框架