转: 基于netty+ protobuf +spring + hibernate + jgroups开发的游戏服务端

from: http://ybak.iteye.com/blog/1853335

基于netty+ protobuf +spring + hibernate + jgroups开发的游戏服务端

游戏服务器

半年前跟朋友开始创业做手机游戏.我负责一个人开发服务端,这是一个卡牌类多人在线回合制对战网游.开始时第一考虑的是能快速出实现需求.其次是功能的可扩展性(应对频繁变更的需求),再次才是服务器性能.

目前游戏开发的主流语言仍是C++,但因为自己最熟悉的是java,转C++的成本太高,且国内页游服务器,已经开始大规模应用java作为后端服务器.最终还是确定使用java来开发.

这里,有两条路可选,1是使用现有的服务器作扩展,2是自己开发服务器.

市面上的成熟的java 游戏服务器寥寥无几,选择并不像web框架那样丰富,可选的收费服务器以smartfox为代表.还有一些开源的但充其量只能作为demo的框架(比如menacher).当时网易的pomelo也还没有出现.

虽然smartfox宣传有很多成功案例.但看了文档后.发现smartfox最成功的案例是棋牌类游戏和社交类游戏.这和我们要开发的卡牌类RPG手游的游戏交互方面还是有很大的差异.而且smartfox对于游戏的逻辑封装过多.比如基本的概念就是进入游戏房间等.这种封装并不适合于我们要开发的游戏类型.所以购买smartfox没有太多的性价比.果断放弃之.

接下来就是自己开发游戏服务器的socket server了.

在实现socket server时,先参考了两个开源的游戏服务器实现.一个是永恒之塔的开源私服实现aionxemu,另一个是简单的socket server实现menacher.

我在看了许多aionxemu的代码实现后.发现这些代码编写开发者一定都是多年的编程老手.代码不光实现了数量庞大的游戏服务接口,还在可扩展性(OO方面)和性能优化上做了很多考究的设计.aionxemu游戏服务器是分为gameserver loginserver和chatserver在gameserver中,接口协议的解析和序列化直接使用的是java nio来操作字节流.直接使用java nio比较繁琐,而操作字节流解析和封装协议也存在同样的问题.虽然能提高性能,但在开发成本和可维护性上有一定弊端,不适合目前我们对进度要求十分紧迫的情况.值得一提的是:aionxemu虽然只是一个私服,但其中具有完整的mmorpg的逻辑实现. 对于我们游戏中的逻辑开发具有相当高的借鉴意义.

menacher中使用了netty作为NIO操作类库,在其代码中展示了netty的简洁性.比较有意思的是menacher使用了jetlang作为游戏业务事件驱动的reactor处理框架,可以方便的提供逻辑的扩展并提供性能调整配置.但遗憾的是menacher并没有在服务器的横向扩展上做太多的考虑..

在参考了以上两个实现,再结合项目的实现情况(服务器提供的服务接口可能多达100多个,而且这些接口后续出现变更),在协议处理上我选择了protoc buffer. Protbuf的跨平台使使用C++的客户端可以方便的序列化协议对象.使用客户端和服务器双方更关注于游戏协议,而非字节流的处理细节.有利于客户端和服务端快速交流. 最后在socket server上采用了netty+protbuf两个框架来实现.netty负责socket处理,protbuf负责处理游戏协议解析.
协议的基本结构如图:


protobuf的客户端消息协议基本如下所示.

Java代码


message PBClientPacket {

required PBClientRequestType clientRequestType = 1; //请求类型

optional bytes requestData = 2; //请求数据

}

enum PBClientRequestType {

DUMMY_REQUEST = 0; // PBDummyRequest

UPDATE_REQUEST = 1; // PBUpdateRequest

REGIST_REQUEST = 2; // PBRegistRequest

LOGIN_REQUEST = 3; // PBLoginRequest

......

}

....

message PBDummyRequest {

optional string payload = 1;

}

message PBUpdateRequest {

required string clientVersion = 1;

......

}

......

protobuf的服务端消息协议基本如下所示.

Java代码


message PBServerPacket {

required PBPayloadType payloadType = 1; //服务端报文类型

optional PBResponseCode code = 2; //

optional string desc = 3; //

optional bytes payloadData = 4; //此字段中包含服务端返回的响应内容

}

enum PBPayloadType {

DUMMY_RESPONSE = 0;

UPDATE_RESPONSE = 2; //PBUpdateResponse

......

}

enum PBResponseCode {

OK = 0;

ERROR_UNKOWN = 1;

SERVER_ERROR = 2;

......

}

message PBUpdateResponse {

optional string resourceURL = 1;

optional bytes resoruces = 2;

......

}

客户端和服务器端的消息结构类似.,第一个字段表示消息类型,程序在知道消息类型后.就可以根据协议来化序列化后面的报文字段.在具体的请求对象外再封装一层统计的交互对象,会有利于netty与protobuf的集成.

netty本身提供的protobuf demo展示了如何方便的与protobuf的集成方式.

对于每种客户端消息,需要找到对应的业务逻辑处理单元.而作为JavaEE开发者,习惯于使用spring来管理这些逻辑处理单元.在spring管理的bean上可以,轻松的添加业务监控功能.服务逻辑上需要使用一种方法来将消息和业务bean映射起来.这里使用了一种比较讨巧的方式来处理,将消息类型作为bean的名称.



比如对于clientRequestType类型为LOGIN_REQUEST的报文.定义了LoginRequestHandler来处理:

Java代码


@Component("LOGIN_REQUEST")

public class LoginRequestHandler extends AbstractRequestHandler {

@Override

public void handle(ByteString packetData, Channel channel) throws InvalidProtocolBufferException {

PBLoginRequest request = PBLoginRequest.parseFrom(packetData);//反序列化请求

.......

}

}

这样在服务器收到报文后.可以方便的根据报文类型选择对应的handler来进行处理.

Java代码


@Component

public class RequestDispatcher {

private Map<PBClientRequestType, RequestHandler> handlerMap = new HashMap<PBClientRequestType, RequestHandler>();

public void dispatchClientPacket(final PBClientPacket clientPacket, final Channel channel) {

PBClientRequestType clientRequestType = clientPacket.getClientRequestType();

try {

handlerMap.get(clientRequestType).handleRequestData(clientPacket.getRequestData(), channel);

} catch (BadRequestException e) {

}

}

以下是集成测试中,模拟客户端构造请求报文的代码:

Java代码


PBLoginRequest loginRequest = PBLoginRequest.newBuilder().setUsername(username).setPassword(password).build();

PBClientPacket clientPacket = PBClientPacket.newBuilder().setClientRequestType(PBClientRequestType.LOGIN_REQUEST)

.setRequestData(loginRequest.toByteString()).build();

hannel.write(clientPacket );

TBD