如今的游戏开发,不搞个跨服玩法都不好意思说在做游戏了(当然,也跟游戏类型有关,一些轻度休闲游戏可以排除在外)。跨服玩法的设计,可以进一步激发玩家追求高战力的虚荣心,也可以汇聚玩家数量,避免单服日活跃低呈现死服现象。
不同服务器的玩家,由于数据不在同一个进程里,所以无法直接交互。跨服设计的目标,就是将不在同一个游戏进程的玩家拉到同一个服务器进程。
跨服玩法的技术本质其实是跨进程通信。服务器A跟服务器B进行数据交换。java常用的进程间通信有http,rpc,webservice,消息队列等等。
而跨服游戏设计最常用的是采用RPC以及原生socket通信。本文主要来讲述这两种方式的通信方式的区别。
RPC(远程过程调用),简单来说,就是一个进程A向另外一个进程B请求服务。进程A调用进程B的服务,就好像在调用自己进程的服务方法一样,无需关心内部的实现细节。RPC的使用demo如下面所示:
- @RpcService(name = "HelloService")
- public class HelloServiceImpl implements HelloService {
-
- @Override
- @RpcInvoker
- public String sayHi(String request) {
- return "hi," + request;
- }
-
- }
客户端只需要引用HelloService接口,其实现HelloServiceImpl由服务端提供实现。客户端可以直接以调用本地服务接口的方式调用服务提供者的功能。
优点:
缺点:
总体来说:
RPC在简化开发、提高效率、可维护性和跨语言支持方面具有明显优势,但同时也存在配置复杂、依赖网络、难以调试和安全性等缺点。在使用RPC时,需要根据具体需求和情况进行权衡和选择。
rpc专注于面型服务,而socket则是面向底层传输通信。类似于http的请求——响应模式,客户端发送一个请求消息给服务器,服务器处理之后给予一个响应消息。
优点:
缺点:
总体来说:
Socket在实现网络通信时具有简单易用、灵活性、跨平台性和实时性的优点,但同时也存在复杂性、性能、安全性和编程复杂度等缺点。在使用Socket时,需要根据具体的需求和情况进行权衡和选择。
特别是对于游戏开发来说,需要比较下两者的优缺点
| socket | rpc | |
| 使用方式 | 服务端收到客户端请求包后返回响应包 | 客户端面向服务接口,使用简单 |
| 传输细节 | 双方需要关注数据的传输过程 | 无须关心底层通信 |
| 通信方式 | 全双工,允许数据同时在两个方向上传输 | 单工,只能客户端主动向服务端请求数据 |
| 同步调用 | 客户端调用过程,可以同步调用,亦可异步调用 | 客户端同步调用,会阻塞当前线程 |
笔者认为:说到底,rpc只是在通信传输的上层封装了服务而已,其底层主要是socket。当然,也有底层使用http的实现,例如Hession。游戏服务器使用socket来接受所有客户端的请求,本身有一个非常完善的跨进程通信框架。而不同服务器节点的跨服通信,本质跟客户端与服务器的通信一样的,所以无须再引入第三方rpc框架。而且基于socket的通信,可以实现类似于rpc的请求——响应模式,也可以实现异步的消息回调。参考以下接口
- public class RpcMessageClient {
-
-
- /**
- * 以消息回调的方式请求数据
- * 发送方无须阻塞当前线程
- */
- public static void callBack(IdSession session, Traceable request,
- RequestCallback callBack) throws CallbackTimeoutException {
-
- }
-
- /**
- * 以请求——响应的方式请求数据
- * 发送方必须阻塞当前线程
- */
- public static Object request(IdSession session, Traceable request) throws
- CallbackTimeoutException {
-
- }
-
- }
具体代码可参考笔者的游戏服务器开源框架