rpc设计的再次思考20251215(以xdb为核心构建游戏框架)

1.服务提供者注册的方式

复制代码

// 表明这是一个服务提供者，ServerType 和 ServerId从application.properties中读取
// 而且只有当当前服务是Game时，才生效。 或者 条件注解???
@RpcProvider(type=ServerType.Game)  
public class GameProvider{

   @MsgReceiver(MsgXxx.XxxMsg.class)
   public login(RpcMsgParam param){
        // 获取对方请求的参数
        MsgXxx.XxxMsg msg = param.getMsg();

        // 主要用于返回数据给服务消费者，这样子何时返回就无所谓了
        Channel channel = param.getChannel();

        // TODO 进行业务处理，并且根据Channel进行数据返回。
   
}

思考：

rpc的用途仅仅是用于进程间通信，如：游戏服和游戏服，Web服和游戏服，游戏服和战斗校验服。

如果是本服的，则是线程间通信，比如：逻辑线程和地图服务在一个进程内这种开发方式，则另外指定线程间通信。

同时解决了dubbo rpc的必须是同步调用的缺陷，而我们采用xdb后，其实是可能在事务内提交成功时，才进行我们的处理。

2.暴露出的3种接口

复制代码

// API1: 异步调用(比如：游戏服和游戏服通信，游戏服和战斗服通信)
RpcContext.asyncCall(serverId, xxxAsk, XxxAnswer.class)
     .whenComplete((answer, exception)->{

     });


// API2: 同步调用(主要是: 比如: 充值web服发货通知游戏服给道具之类的)
XxxAnswer answer = RpcContext.syncCall(serverId, xxxAsk, XxxAnswer.class);


// API3: 仅仅是通知，无需返回
RpcContext.send(serverId, xxxAsk);

思考：

关键之处就是：获取serverId, 想查询一个玩家信息这种，根据玩家id其实是知道serverId的。

web服和联盟服之类的，这种是从注册中心获取的。

3.通信协议和编解码器

使用rj那种，比较简单的处理，只需要指定包头包体长度即可。

消息id 和 class的映射，我采用英雄传说中的。