无论刮风还是下雨,太阳照常升起。——雷欧娜
现在很多游戏都有跨服玩法,一个游戏中又可能有多种跨服玩法,比如跨服矿战、跨服帮战、跨服聊天、跨服夺宝等等。根据这些玩法类型,需要将服务器标记为矿战服、帮战服、聊天服、夺宝服等等,然后在活动开启或报名时,需要将游戏服分配至相应的跨服,比如每10个游戏服分配至1个聊天服,每3个游戏服分配至1个矿战服,即在分配时是需要知道相应类型跨服和游戏服数量及状态的,这就存在了服务器管理问题。在各种类型的服务器启动时,需要将自己的服务器类型统一注册到某个“中心服”上,以供相应玩法分配。
上述的跨服和游戏服,并没有严格意义上的不同物理机区分,也没有严格意义上的不同应用(或叫进程)区分。即游戏服、各类跨服是可以共存在某台物理机上的,并不是每种服务器各占一台物理机。而游戏服和其他跨服通常是分开进程启动的,比如游戏服是一个进程,其他跨服既可以共用一个进程启动,也可以分进程启动,共用一个进程启动,就相当于这个进程包含所有的跨服功能了。
在《Java游戏跨服实现》一文中,给大家展示了如何跨服通信,其中也提到了如何手写服务发现,它需要在自己的服务器启动时,把自己服的ip端口服务器id服务器类型等信息,告诉一个“中心服”;如果这个游戏服被合并了不用了,那也要告诉“中心服”,不然别的分配的跨服以为它还存在的,所以中心服也要有种机制,需要知道哪个端失联了;而游戏服也需随时知道它连的“中心服”或“跨服”是否也失联了;此外,在重要的跨服玩法开启前,最好有办法能提示或直接显示哪个重要的跨服没开启来,从而有时间采取措施让该玩法再次按时开启。在《Java游戏跨服实现》中,采用了Hessian+Jetty组合的方式实现了跨服通信,这使得手写这种跨服管理也变得比较容易起来。
但现在是有框架直接专门做这个事情的,我们只需简单了解它的用法和api,就可以实现上述服务管理,比起自己手写可能没考虑周全的地方更靠谱一点。下面将介绍如何使用zookeeper管理这些游戏跨服。
ZooKeeper 是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
ZooKeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。
服务生产者将自己提供的服务注册到 ZooKeeper 中心,服务的消费者在进行服务调用的时候先到 ZooKeeper 中查找服务,获取到服务生产者的详细信息之后,再去调用服务生产者的内容与数据。
摘自:ZooKeeper概念详解,最全整理
游戏中应用zookeeper大致流程如下(windows下示范,linux操作类似):
1.在某台服务器上安装和启动zookeeper server,如我用的zookeeper版本为zookeeper-3.4.14,解压,将它随意放某个盘符下;
2.进入zookeeper-3.4.14\conf目录下,复制其中的zoo_sample.cfg,改名zoo.cfg,zookeeper server默认读此配置文件,打开zoo.cfg,简单添加或修改如下配置:
数据路径:dataDir=D:/zookeeper-3.4.14/data (修改)
日志路径:dataLogDir=D:/zookeeper-3.4.14/log (添加)
客户端连接数:maxClientCnxns=60 (放开)
3.进入zookeeper-3.4.14\bin,双击zkServer.cmd,即可启动zookeeper server。
以上就是zookeeper server端的启动,在3.相同目录下,我们可以双击zkCli.cmd测试连接zookeeper server端,而我们的游戏服和跨服就需引用相应的zookeeper客户端jar包去连接此zookeeper server端,以让zookeeper server端管理我们的游戏服和跨服。
目前,常用的有三种zookeeper客户端jar包去连zookeeper服务端:
一种是zookeeper官方提供的原生客户端API,因其有多种缺陷很少有人使用;
一种是第三方zkclient客户端,因其社区活跃性,完善性,文档化,异常处理简化,重试机制等难用或不足,用起来比较麻烦;
一种是第三方Curator库,Curator是Apache基金会的顶级项目之一,解决了原生api很多缺陷,简化了使用api,所以用得比较多。
以下即以Curator库,介绍如何将java游戏服和跨服作为zookeeper客户端,被zookeeper服务端发现和管理。
1.引入curator库,如在maven工程下,做如下依赖:
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>2.9.0</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-x-discovery-server</artifactId>
<version>2.9.0</version>
</dependency>
2.配置(读取)zookeeper server地址,如:
zookeeper_address=localhost:2181
3.创建会话,有静态工程方法、Fluent风格、隔离命名空间等方式,以下为静态工程方法创建会话,其中里面的zookeeper_address就为上述2.中的zookeeper_address:
ExponentialBackoffRetry backoffRety = new ExponentialBackoffRetry(1000, 3);
CuratorFramework client = CuratorFrameworkFactory.newClient(zookeeper_address, backoffRety);
client.start();
closeables.add(client);
4.生成服务实例,即将我们的游戏服和跨服变成一个个zookeeper的服务实例,供后续查询服务实例用(即做服务发现)
比如,假设我们的某台服务器是做跨服的,它服务器类型可作为中心服、矿战服、帮战服,即该服务器又可做中心服,又可做矿战服和帮战服,可如下定义:
List<ServerType> serverTypeArr = new ArrayList<>(Arrays.asList(ServerType.CENTER_SERVER, ServerType.FACTION_SERVER, ServerType.MINE_SERVER)); //实际项目中读取配置文件
ServerType[] serverTypes = serverTypeArr.toArray(new ServerType[0]);
for (ServerType serverType : serverTypes) {
registerService(client, serverType);
}
private static void registerService(CuratorFramework client, ServerType serverType) {
try {
//生成服务实例
ServiceInstanceBuilder<ServerModel> sib = ServiceInstance.builder();
ServerModel model = ServerModel.build(serverType, getServerId(), getUrl());
sib.address(model.getUrl());
sib.id(model.getId());
sib.name(serverType.name());
sib.payload(model);
ServiceInstance<ServerModel> instance = sib.build();
//添加服务实例
ServiceDiscovery<ServerModel> serviceDiscovery = ServiceDiscoveryBuilder.builder(ServerModel.class)
.client(client).serializer(new JsonInstanceSerializer<ServerModel>(ServerModel.class))
.basePath(ZkNames.SERVICE_ROOT).build();
// 服务注册,即成为服务提供者
serviceDiscovery.registerService(instance);
serviceDiscovery.start();
log.info("ZOOKEEPER注册成功");
} catch (Exception e) {
log.error("ZOOKEEPER注册服务出错", e);
}
}
5.写到这里时,双击zookeeper-3.4.14\bin目录下zkServer.cmd,查询上述ZkNames.SERVICE_ROOT节点,即可发现已成功注册了中心服、矿战服、帮战服。
[zk: localhost:2181(CONNECTED) 1] ls /test_service
[FACTION_SERVER, MINE_SERVER, CENTER_SERVER]
再写启动发现服务,注意它与添加服务实例的区别,添加服务实例多了句serviceDiscovery.registerService(instance);意为服务提供者,而下述发现服务,是作服务查询用的,相当于就是zookeeper的客户端,用于后续查询其他服务器信息。
private static void discoveryService(CuratorFramework client) {
try {
serviceDiscovery = ServiceDiscoveryBuilder.builder(ServerModel.class)
.client(client).serializer(new JsonInstanceSerializer<ServerModel>(ServerModel.class))
.basePath(ZkNames.SERVICE_ROOT).build();
serviceDiscovery.start();
closeables.add(serviceDiscovery);
log.info("启动发现服务成功");
} catch (Exception e) {
log.error("启动发现服务出错", e);
}
}
写了服务发现后,如果要找其他跨服信息,直接作如下调用即可。
serviceDiscovery.queryForInstances(serverType.name());
6.在《Java游戏跨服实现》一文中,我们调用远程接口是如下调用的:
IReqCrossServerHandler handler = CrossHandlerProxy.getProxy(IReqCrossServerHandler.class, "http://192.168.1.5:33222/HessianService");
RespVo respVo = handler.fight(new ReqVo(1001, 2001));
System.out.println("respVo:" + respVo);
注意其中的"http://192.168.1.5:33222/HessianService",当我们用zookeeper实现了服务发现与治理后,便可用serviceDiscovery.queryForInstances(serverType.name());获得跨服ip端口信息,代入上述方法,变为
IReqCrossServerHandler handler = CrossHandlerProxy.getProxy(IReqCrossServerHandler.class, serverModel.url );
RespVo respVo = handler.fight(new ReqVo(1001, 2001));
System.out.println("respVo:" + respVo);
即实现了跨服调用。
网友评论