Nacos 只负责发现服务Spring Boot RPC 还缺哪些调用语义工程判断Nacos 服务发现告诉调用方实例在哪里却没有定义参数怎样传、错误怎样返回、身份怎样传播以及超时怎样治理。找到服务和可靠调用服务是两个不同问题。业务代码如果直接拼 URL、Header 和响应解析每个服务都会形成自己的 RPC 协议后续更换客户端或增加 TraceId 时要全链路修改。MetaLite 在 Nacos 发现能力之上增加 InternalServiceClient统一内部调用协议、上下文 Header 和响应处理。本文先划清注册发现与 RPC 的边界再沿一次内部调用验证这层封装。一、Nacos 负责找实例不负责定义调用语义MetaLite 的内部调用分成三层InternalServiceClient → InternalServiceProxy → NacosInternalServiceProxyImpl → ApacheHttpClient每一层只承担一类职责层次主要职责InternalServiceClient校验请求、填充上下文、解析统一响应InternalServiceProxy隔离注册中心和传输协议NacosInternalServiceProxyImpl选择 Nacos 实例并转换地址ApacheHttpClient连接池、超时、重试与 HTTP 收发这层拆分的关键不是“多写几个类”而是避免业务代码同时知道注册中心、HTTP 客户端和统一响应格式。二、选择一个实例与广播所有实例是两种业务语义普通 RPC 调用只需要一个健康实例。源码通过 NacosNamingService执行InstanceinstancegetNamingService().selectOneHealthyInstance(provider);随后把服务名转换为真正的地址user-service → 10.0.1.23:8081 → http://10.0.1.23:8081但缓存清理、配置刷新等场景不能随机命中一个实例因为每台机器都有自己的本地状态。MetaLite 因此还提供callAllInstanceListInstanceinstanceListnamingService.getAllInstances(provider);它逐个调用服务的全部实例并支持忽略本机。这两个方法不能混成一个“万能调用”查询、写入等普通业务调用应选择一个健康实例清理本地缓存等节点级动作需要广播全部实例广播属于多次独立调用不天然具备分布式事务语义某个节点失败后是继续、重试还是整体失败需要业务明确决定。三、为什么请求模型不能只剩一个 URL源码中的RpcRequest不只保存 URL而是显式描述provider 服务提供方 endpoint 接口路径 param 请求参数 headers 请求头 timeoutMillis 超时预算 rpcMode 协议、方法和内容类型组合 fallback 降级函数RpcModeEnum再把常见场景限定为 GET、POST JSON、POST FORM、POST XML 和 PUT JSON。这样做有两个好处。第一业务代码表达的是“调用哪个服务的哪个端点”而不是先拼接注册中心返回的 IP。第二不同内容类型仍走统一入口日志、超时、上下文和 fallback 不必重复实现。这也是为什么“封装 RPC”不等于重新发明网络协议。MetaLite 仍然使用 HTTP只是把散落的工程约束集中起来。四、调用上下文必须在离开当前线程前显式复制InternalServiceClient.checkAndFillRpcRequest会把当前线程中的信息写入请求头headers.put(TRACE_ID,ThreadContext.getTraceId());headers.put(LOGIN_USER_ID,ThreadContext.getLoginUserId());headers.put(APP_ID,ThreadContext.getAppId());headers.put(SEATA_XID,ThreadContext.getSeataXid());同时它还填充消费者名称和服务提供者名称。这一步很容易被低估。ThreadLocal 只在当前进程、当前线程有效HTTP 请求一旦离开 JVM另一端不可能自动得到这些上下文。因此传播链必须是显式的ThreadContext → HTTP Header → 服务端入口处理器 → 新的 ThreadContext如果缺少中间任何一步日志链路、登录身份或分布式事务上下文都会在跨服务时断开。五、超时不是每一层都使用同一个数字源码在调用前会对超时时间做递减timeoutMillistimeoutMillis0?API_REQUEST_TIMEOUT_MILLIS:timeoutMillis-API_REQUEST_TIMEOUT_MILLIS_MINUS;它表达的是一个重要原则下游不应该耗尽上游的全部等待时间。假设入口最多等待 3 秒下游也配置 3 秒那么下游刚返回超时上游可能已经先结束后续 fallback、日志和响应转换都失去执行窗口。更合理的模型是入口总预算 当前层处理时间 下游预算 收尾时间MetaLite 的递减是轻量实现不等于完整的 deadline 传播。链路更复杂时还需要传递绝对截止时间并在每一跳重新计算剩余预算。六、HTTP 成功不等于业务成功底层 Apache HttpClient 拿到 2xx只说明 HTTP 请求成功。内部接口返回的仍然是统一RespJSON因此客户端还要完成第二层解析HTTP RespString → 解析内部 Resp → 检查业务 code → 恢复 data 类型MetaLite 分别提供单对象结果ListT结果PageResultDtoT分页结果。它还会检查“调用方要求集合但服务端实际返回对象”等结构不一致问题避免把类型错误拖到更远的业务代码中。七、这套设计没有假装解决所有问题源码当前边界也很清晰内部代理目前只支持 HTTP实例选择依赖 Nacos 的健康实例能力全实例广播是串行调用实例很多时延迟会线性增加返回类型通过 JSON 二次转换复杂泛型需要额外设计服务端实例在查询后、调用前仍可能下线没有自动获得熔断、舱壁和全链路 deadline。这些能力可以继续演进但不应该通过一个巨大客户端类堆在一起。InternalServiceProxy的价值就在于为其他注册中心、协议或治理实现保留替换边界。八、真正值得复用的是边界而不是客户端名称Nacos、Feign、RestClient、WebClient 或 Apache HttpClient 都只是工具。企业项目长期维护时更关键的是四个边界服务发现与传输协议分离业务调用与连接池细节分离HTTP 状态与业务状态分离单实例调用与全实例广播分离。把这些边界定义清楚即使以后替换注册中心或 HTTP 客户端业务层也不需要跟着重写。框架简介MetaLite 是面向企业生产环境的新一代 Java 微服务技术底座。系列文章重点分享代码背后的设计思路、技术取舍与工程实践。源码基线JDK 21、Spring Boot 3.2.9、Spring Cloud 2023.0.1、Spring Cloud Alibaba 2023.0.1.3具体组件版本以项目backend-bom为准。作者简介15 年 Spring 体系企业级开发经验专注于 Java 微服务架构、工程治理与生产实践。持续更新MetaLite 系列内容将持续更新围绕核心设计、源码链路、技术取舍与生产实践展开。欢迎关注作者及时获取后续内容。在线演示演示地址: https://admin.metalite.top/演示账号: guess演示密码: admin2026
