一、RpcRouter是干嘛的想象你开了一家“万能代办公司”服务端客户发来一张工单RPC请求上面写着“帮我算一下1122”调用Add函数Dispatcher前台拿到工单一看是 算数据业务 就把工单丢给了RpcRounter算数部门主管RpcRounter主管拿到工单后不会立刻去算他要先做两件事查明册我们公司有“算加法”这个业务吗查找method映射表验参数客户填的参数对吗他说算1122但如果他填了“abc” 22那肯定不行参数校验3.执行校验通过了主管才把具体的数据交给底层的“打工人”具体业务回调函数去执行 最后把结果返回总结RpcRounter的核心任务就是“找方法”和“验参数”二、RpcRounter的数据流转文字架构图 【客户端发来 RPC 请求】 { method: Add, parameters: { num1: 11, num2: 22 } } ↓ ┌─────────────────────────────────────────────────────────────┐ │ 阶段一Dispatcher 分发 (来自上一层的接线员) │ │ 动作识别出 MType 是 RPC请求将 Body(JSON数据) 交给 RpcRouter│ └─────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────┐ │ 阶段二RpcRouter 路由与校验 (本模块核心) │ │ │ │ 动作1提取 method 字段 (如 Add) │ │ ↓ │ │ 动作2查表 hash_mapmethod, describe │ │ ├── 查到了找到 Add 对应的 ServiceDescribe (服务描述) │ │ └── 没查到返回错误方法不存在 │ │ ↓ │ │ 动作3调用 ServiceDescribe 进行参数校验 │ │ ├── 检查 num1 是不是整型(是 11通过) │ │ ├── 检查 num2 是不是整型(是 22通过) │ │ └── 校验不通过返回错误参数格式错误 │ └─────────────────────────────────────────────────────────────┘ ↓ (校验通过提取 parameters 数据) ┌─────────────────────────────────────────────────────────────┐ │ 阶段三业务回调执行 (真正干活的业务函数) │ │ 动作调用注册好的业务函数 (如 Add(num1, num2)) │ │ 结果计算出 33封装成 JSON 响应 │ └─────────────────────────────────────────────────────────────┘ ↓ 【返回给客户端】 { rcode: OK, result: 33 }三、结合图片拆解RpcRouter的内部设计1. 核心数据结构hash_mapmethod, describe在 RpcRouter 的底部有一个非常重要的数据结构它是一个哈希表字典。Key键方法名称比如Add,Translate。Value值ServiceDescribe服务描述对象。为什么需要这个 map当客户端发来method: Add时RpcRouter 需要以最快的速度O(1)时间复杂度找到对应的方法信息而不是用if-else一个个去比对。2. 核心对象ServiceDescribe服务描述图中的上半部分展示了ServiceDescribe包含的四个核心要素。这是参数校验的基石。在服务注册时每个方法都必须提供这个描述方法名称比如Add。参数字段及格式描述规定参数名必须叫num1和num2且必须是整数。参数校验接口提供一个函数专门用来比对客户端传来的 JSON 数据是否符合上面的格式。业务回调函数如果校验通过了该去调用哪个具体的函数来执行真正的加法运算。3. 对外接口onRpcRequest图中右侧的onRpcRequest模块说明 RpcRouter 必须向外暴露一个统一的入口函数供 Dispatcher 调用。当网络上有 RPC 请求过来时Dispatcher 就会触发onRpcRequest然后把 JSON 数据传进来内部开始走我们上面画的“查表 - 校验 - 执行”流程。四、 总结RpcRouter 模块的设计哲学是“先验后行安全第一”。在网络通信中我们绝不能盲目信任客户端传来的数据。如果客户端恶意传入错误的参数比如本该传 int 却传了 char直接执行底层业务函数可能会导致服务端崩溃。因此RpcRouter 强制要求每个注册的服务都必须提供ServiceDescribe服务描述。在收到请求时它利用哈希表快速定位方法并严格执行参数校验。只有符合规范的请求才会被真正放行去执行业务逻辑。这种设计不仅保证了服务端的稳定性也为后续的自动化服务发现和注册提供了数据支撑