基于 node.js的高可扩展游戏服务器框架设计与实现

周永昶zhouyongchang@corp.netease.com

提纲• Node.js与游戏服务器• 游戏服务器框架的可扩展性

– 游戏的可扩展性– 框架的可扩展性

Node.js与游戏服务器• Pomelo

– 定位• Web ，社交， Mobile 游戏服务器

– 目标• 简化游戏开发

https://github.com/NetEase/pomelo

Node.js与游戏服务器

• 什么是 node.js– Node.js is a platform built on Chrome's JavaScript runtime for

easily building fast, scalable network applications.

• Node.js 特性– 服务器端 js

– 事件驱动，异步 IO

– 单线程– 轻量– 快速开发

Node.js与游戏服务器

• 为什么用 node.js

– 优势• IO

• 可扩展性• Javascript

• 社区

– 不足• CPU 密集计算

游戏服务框架的扩展性

• 为什么扩展？• 如何扩展？

– 游戏服务器的特性– 框架的特性

游戏服务器的扩展性• Web服务器

– 短连接– 无状态– 无限水平扩展

游戏服务器的扩展性• 游戏服务器

– 长连接– 有状态– 响应时间 ~100ms

– 有策略的扩展

游戏服务器的扩展性• 单服架构

– 所有处理均在一个进程内完成– 优点：简单– 缺点：扩展难度较大

游戏服务器的扩展性• 模块化架构

– 将场景分离出来– 游戏世界随场景进行扩展– 设计和维护复杂

游戏服务器的扩展性• BigWorld架构

– 无缝地图，无限大的世界– 强大的负载均衡

游戏服务器的扩展性• 游戏服务器架构发展趋势

gateway

auth

chat

trade

db

AI

path-finding

游戏服务器的扩展性• 扩展的策略

– 多进程单线程• 避免线程间的并发问题• 单一进程负责单一服务• 进程间通过消息进行通讯• 以服务为单位进行功能扩展• 使得游戏世界的扩展更容易

游戏服务器的扩展性• 扩展的策略

– 服务器的类型与数量• 服务器类型为模板• 服务进程为实例• 以实例的数量进行水平扩展• 更合理的分配资源

游戏服务器的扩展性• 扩展的策略

– 场景的分区策略• 避免分布式的状态同步• 以场景为单位分区• 场景内所有状态在同一个进程（玩家，怪物， NPC 等）• 无状态的服务可以分离出来（寻路等）

游戏服务器的扩展性• Demo

http://pomelo.netease.com/lordofpomelo/

游戏服务器的扩展性• 运行时进程结构

游戏服务器的扩展性• 小结

– 游戏服务器是一个整体– 将问题分解，简化– 灵活扩展，合理分配资源– 从头开发比较复杂

框架的扩展性• 设计目标

– 支撑游戏服务器的架构模型– 简化游戏服务器开发

框架的扩展性• 考虑的问题

– 服务器整体规划– 单个服务进程的规划– 业务逻辑的实现和扩展– 框架的通用性

服务器的整体规划• 服务器整体规划

– 服务进程的类型• 可能会有很多种类型的进程• 不同的类型可能有不同的特性

– 服务进程的数量• 不同类型的进程可能分配不同的数量

提取服务器的共性

服务器的整体规划• 服务器的抽象

frontend

frontend

backend

backend

backend

backend

forward message

push messageby channel

rpc

master

服务器的整体规划• Frontend Server

– 承载客户端连接– 维护 session 信息– 将请求分发给后端服务器– 向客户端推送消息

服务器的整体规划

websocket rpc

before after

dispatcher

handler remote

session

filter

服务器的整体规划• Backend Server

– 接收前端分发的请求– 实现业务逻辑– 提供远程服务– 通过 channel 向客户端推送消息

服务器的整体规划

rpc

before after

dispatcher

handler remote

channel

filter

服务器的整体规划• 服务类型的定制

frontend backend

基于 websocket 的 server 提供 rpc 服务的 server

area

chat

status

connector

服务器的整体规划• 实现策略：惯例优先

– 按服务器类型划分目录– handler 实现请求处理逻辑– remote 实现远程调用接口– 一个工程管理所有代码– 开发者只要填空就可以了

server type

服务器的整体规划• 配置文件指定实例数量

服务进程的规划• 单个服务进程的规划

– 进程对外的服务能力– 服务的能力应该怎么获得– 能力的复用：继承 or 组合

服务进程的规划• 组件系统

– 组件是服务的功能单元– 将组件组合到一起让进程具有相应的能力– 组件间通过一个统一的上下文进行协作– 将大软件分解为小模块

服务进程的规划• 基于组件的扩展

app

handler

rpcproxy

rpcserve

r

connector

client

remotepeer

client

client

服务进程的规划• 组件的生命周期

服务进程的规划• 不同层次的抽象

connector

area chat status

frontend

backend

core

container

component

业务逻辑的实现与扩展• 业务逻辑的实现

– 客户端请求的处理– RPC 的处理

客户端请求• 服务流程的扩展

– 业务逻辑与前 / 后置逻辑分离– Handler 实现业务逻辑– Filter 负责前 / 后置逻辑，是服务流程的扩展点

RPC

• RPC的作用– 服务器间通讯的基础– 隐藏底层通讯的细节

• 考虑的问题– 多进程间通讯– 路由控制– 协议切换

RPC

• RPC Client

RPC

• RPC Server

Q&A