RoadMap.md

Regax实时游戏框架设计

需求

服务于 “多人” “实时” 场景或对战类游戏

框架设计

框架设计参照 pomelo，如下图，其中蓝色优先支持:

• 运行架构说明：

  • 客户端通过 Websocket 长连接连到 Connector 服务器群。
  • Connector负责承载连接，并把请求转发到后端的服务器群。
  • 后端的服务器群负责各自的业务逻辑，真实的案例中会有各种类型的服务器，如自动寻路服务器、AI服务器。
  • 后端服务器处理完逻辑后把结果返回给Connector，再由connector广播回给客户端。
  • Master负责统一管理这些服务器，包括各服务器的启动、监控和关闭等功能。

这个运行架构符合几个伸缩性原则：

• 前后端进程分离，把承载连接和广播的压力尽量分出去, 且连接服务器群是无状态的, 因为游戏场景中连接服务器往往会成为性能的热点。
• 进程的粒度尽量小，把功能细分到各个服务器
• 连接服务器和业务逻辑服务器做负载均衡，并支持弹性扩容

游戏服务器和Web服务器

在游戏场景中，连接服务器往往会成为性能的热点，这就是是由于巨大的广播消息所导致的。由于广播消息的数量和玩家数量相比是n^2的关系，这就会导致广播消息数量会随着玩家数量急剧增长

最初的网络服务器是单进程的架构，所有的逻辑都在单台服务器内完成， 这对于同时在线要求不高的游戏是可以这么做的。由于同时在线人数的上升，单服务器的可伸缩性必然受到挑战。

随着网络游戏对可伸缩性要求的增加，分布式是必然的趋势的。

游戏服务器的分布式架构与Web服务器是不同的，以下是web服务器与游戏服务器架构的区别：

• 长连接与短连接。web应用使用基于http的短连接以达到最大的可扩展性，游戏应用采用基于socket(websocket)的长连接，以达到最大的实时性。

• 分区策略不同。web应用的分区可以根据负载均衡自由决定， 而游戏则是基于场景(area)的分区模式， 这使同场景的玩家跑在一个进程内， 以达到最少的跨进程调用。

• 有状态和无状态。web应用是无状态的， 可以达到无限的扩展。 而游戏应用则是有状态的， 由于基于场景的分区策略，它的请求必须路由到指定的服务器， 这也使游戏达不到web应用同样的可扩展性。

• 广播模式和request/response模式。web应用采用了基于request/response的请求响应模式。而游戏应用则更频繁地使用广播， 由于玩家在游戏里的行动要实时地通知场景中的其它玩家， 必须通过广播的模式实时发送。这也使游戏在网络通信上的要求高于web应用。 因此， Web应用与游戏应用的运行架构也完全不同， 下图是通常web应用与游戏应用的不同：

可以看到由于web服务器的无状态性，只需要通过前端的负载均衡器可以导向任意一个进程。 而游戏服务器是蜘蛛网式的架构，每个进程都有各自的职责，这些进程的交织在一起共同完成一件任务。这就是一个标准的分布式开发架构

Roadmap

一期：完成基础分层架构及通信设计

• 基础建设

  • 完成基础分层架构
  • 通信协议：完成客户端/服务端websocket协议支持及Session、Channel基础能力建设
  • 数据服务：内存缓存(Tair)，持久化存储(OB)
  • 工具：集成到chair插件(基于node-cluster做负载均衡)

• 案例

  • 聊天室案例
  • 贪吃蛇多人对战服务端设计

二期： 完善基础建设

• 基础建设

  • 多进程负载均衡
  • 服务监控
  • 工具完善

• 业务服务沉淀

  • AI 服务
  • 房间自动匹配服务
  • 自动寻路服务等

三期： 平台建设

• 业务服务抽象沉淀，建立实时游戏SaaS服务平台

参考

• pomelo架构概览