如今的游戏开发，不搞个跨服玩法都不好意思说在做游戏了（当然，也跟游戏类型有关，一些轻度休闲游戏可以排除在外）。跨服玩法的设计，可以进一步激发玩家追求高战力的虚荣心，也可以汇聚玩家数量，避免单服日活跃低呈现死服现象。
不同服务器的玩家，由于数据不在同一个进程里，所以无法直接交互。跨服设计的目标，就是将不在同一个游戏进程的玩家拉到同一个服务器进程。
跨服玩法的技术本质其实是跨进程通信。服务器A跟服务器B进行数据交换。java常用的进程间通信有http，rpc，webservice，消息队列等等。
而跨服游戏设计最常用的是采用RPC以及原生socket通信。本文主要来讲述这两种方式的通信方式的区别。
rpc跨服通信
RPC（远程过程调用），简单来说，就是一个进程A向另外一个进程B请求服务。进程A调用进程B的服务，就好像在调用自己进程的服务方法一样，无需关心内部的实现细节。RPC的使用demo如下面所示：
@RpcService(name = "HelloService")
public class HelloServiceImpl implements HelloService {@Override@RpcInvokerpublic String sayHi(String request) {return "hi，" + request;}}客户端只需要引用HelloService接口，其实现HelloServiceImpl由服务端提供实现。客户端可以直接以调用本地服务接口的方式调用服务提供者的功能。
rpc的优缺点
优点：
- 简单易用：RPC隐藏了底层通信细节，使用起来简单方便。
- 提高效率：RPC可以将远程调用过程封装成一个接口，并通过一定的序列化和反序列化机制将数据进行传输，减少通信开销，提高效率。
- 提高可维护性：RPC将远程服务封装成接口，可以提高代码的可维护性和可拓展性。
- 跨语言支持：RPC协议通常是跨语言的，可以实现不同语言之间的通信和调用。
缺点：
- 依赖网络：RPC需要依赖网络进行通信，网络不稳定或延迟会影响调用效率和可靠性。
- 难以跟踪问题：由于RPC调用是在不同的进程上进行的，一旦出现问题，调试和跟踪问题会比在本地调用困难。
- 安全性：RPC通信可能会存在安全隐患，需要额外的安全机制来确保通信的安全性。
- 版本兼容性：当服务端接口发生变化时，客户端需要做相应的升级或兼容处理，增加了开发和维护的难度。
总体来说：
RPC在简化开发、提高效率、可维护性和跨语言支持方面具有明显优势，但同时也存在配置复杂、依赖网络、难以调试和安全性等缺点。在使用RPC时，需要根据具体需求和情况进行权衡和选择。
socket通信
rpc专注于面型服务，而socket则是面向底层传输通信。类似于http的请求——响应模式，客户端发送一个请求消息给服务器，服务器处理之后给予一个响应消息。
socket的优缺点
优点：
- 简单易用：Socket编程提供了一种简单而直接的方式来实现网络通信，使得开发者可以自有地创建客户端和服务器端进行通信。
- 灵活性：Socket提供了底层的网络通信接口，允许开发者自定义通信协议和数据格式，从而可以满足各种不同的需求。
- 跨平台性：由于Socket是基于TCP/IP协议的，因此可以在不同的操作系统和平台上进行通信，具有较好的跨平台性。
- 实时性：Socket通信可以实现实时性要求较高的应用，如在线游戏、实时聊天等。
缺点：
- 复杂性：在Socket编程中，开发者需要处理网络通信的各种细节，包括连接管理、数据传输、数据编解码，数据粘包拆包、异常处理等，相对比较复杂。
- 性能：Socket通信的性能受到网络环境和负载的影响，可能出现延迟或带宽受限的情况，影响通信效率。
- 安全性：Socket通信的安全性相对较低，需要额外的加密和认证机制来确保通信的安全性。
总体来说：
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 {}}具体代码可参考笔者的游戏服务器开源框架
jforgame游戏服务器开源框架
)
