真实面经题目 · 原创解析
HTTP 转 Dubbo 的本质不是协议字节直接翻译，而是在网关或适配层把一个 HTTP 请求解析成一次 Dubbo RPC 调用。核心流程是：接收 HTTP 请求，按路由规则定位 Dubbo 接口、方法和版本，完成参数绑定和类型转换，通过注册中心或本地配置找到服务提供者，使用 Dubbo 客户端按 Dubbo 协议编码、序列化并发起调用，再把 Dubbo 响应、异常和超时结果转换成 HTTP 状态码与响应体。回答要围绕映射、发现、调用、治理和观测展开，而不是只说用网关转发。
可以从适配层角度回答：通常会在 API 网关、BFF 或独立协议转换服务里做 HTTP 到 Dubbo 的转换。HTTP 层负责接收 REST、表单或 JSON 请求，先根据路径、方法、域名、Header 等规则匹配到目标 Dubbo 服务，比如 interface、method、group、version。然后把路径参数、Query、Header、Body 里的数据绑定成 Dubbo 方法入参，并根据 Dubbo 接口签名做类型转换和校验。接下来通过注册中心获取 Dubbo provider 地址，或者从配置中心读取目标服务信息；调用时可以走强类型 Stub，也可以走 Dubbo 泛化调用，后者更适合网关动态转发。真正发起调用时，Dubbo 客户端会按 Dubbo 协议组织请求头、请求 ID、序列化类型、方法名、参数类型、参数值、附件等内容，通过 Netty 长连接发送给 provider。返回后，适配层再把正常结果、业务异常、超时、限流、无服务、反序列化失败等情况映射成统一的 HTTP 响应。生产环境还要补齐鉴权、限流、超时、重试、熔断、灰度、日志、链路追踪、指标监控和错误码治理，这些才是协议转换在工程上真正复杂的部分。
HTTP 和 Dubbo 不是同一层次的调用模型。HTTP 常见语义是资源、路径、方法、Header、Body 和状态码；Dubbo 的语义是接口、方法、参数类型、参数值、附件、服务分组、版本和调用配置。因此 HTTP 转 Dubbo 通常不是把 HTTP 报文头改成 Dubbo 报文头这么简单，而是由一个适配层完成请求语义到 RPC 语义的转换。这个适配层可以是 API 网关、业务 BFF、边缘服务，也可以是专门的协议转换网关。它对外暴露 HTTP 接口，对内作为 Dubbo consumer 调用后端服务。
第一步是根据 HTTP 请求确定要调用哪个 Dubbo 服务。常见映射维度包括域名、URI 路径、HTTP Method、Header、租户、AppId 或网关路由配置。例如 POST /orders/create 可以映射到 com.xxx.OrderService.createOrder，GET /users/{id} 可以映射到 UserService.getById。映射结果通常至少包含 interface、method、group、version，必要时还包含超时时间、重试次数、序列化方式、目标集群、灰度标识和鉴权策略。这里的难点是避免路径设计与 RPC 方法强耦合：对外 HTTP API 应该稳定，对内 Dubbo 接口可以演进，所以中间需要一层明确的路由和参数映射配置。
HTTP 请求里的数据可能分布在 Path Variable、Query String、Header、Cookie、表单和 JSON Body 中，而 Dubbo 方法需要的是有明确顺序和类型的参数列表。适配层要做参数提取、字段重命名、默认值填充、类型转换和参数校验。例如 HTTP 里 userId 是字符串，Dubbo 方法可能需要 Long；HTTP Body 是 JSON 对象，Dubbo 方法可能需要一个 Java DTO；Header 里的 traceId、tenantId、userId 可能不进入业务参数，而是放到 Dubbo attachment。这里还要处理泛型、枚举、日期、集合、嵌套对象、空值和参数顺序问题。Dubbo 调用不仅需要参数值，还需要参数类型签名，否则重载方法、泛化调用和反序列化都可能出问题。
适配层作为 Dubbo consumer，需要具备服务发现能力。通常它会连接注册中心，从注册中心订阅目标 interface、group、version 对应的 provider 列表，然后按照 Dubbo 的集群策略、负载均衡策略和路由规则选择一个可用节点。也可以在简单场景下通过直连地址或静态配置调用，但生产环境一般依赖注册中心和配置中心。服务发现还涉及 provider 上下线感知、权重、路由、同机房优先、灰度分组和健康状态。HTTP 网关如果没有正确接入 Dubbo 的注册和治理体系，就很容易出现 HTTP 路由命中了、但后端服务找不到，或者灰度流量打到错误版本的问题。
HTTP 转 Dubbo 有两种常见实现。第一种是强类型方式：网关或 BFF 引入 Dubbo 接口依赖，像普通 consumer 一样注入服务代理并调用方法。这种方式类型安全、开发简单、性能和可维护性较好，适合接口数量有限、业务边界清晰的场景。第二种是泛化调用：网关不依赖具体接口 jar，而是根据 interface、method、parameterTypes 和参数值动态发起 GenericService 调用。这种方式更适合通用 API 网关，因为它可以通过配置动态接入大量 Dubbo 接口，但复杂点在于参数类型描述、DTO 结构转换、版本兼容和错误诊断。
适配层完成路由和参数准备后，会由 Dubbo 客户端负责真正的 RPC 通信。Dubbo 协议通常基于长连接，底层常见是 Netty。请求会带上魔数、请求标志、序列化类型、请求 ID、数据长度等协议头信息，Body 里包含 Dubbo 版本、服务路径、服务版本、方法名、参数类型描述、参数值和附件。参数值会按照配置的序列化协议编码，例如 Hessian2、Fastjson2、Java 序列化或其他扩展序列化方式。HTTP 网关一般不应该自己手写 Dubbo 协议头，而应使用 Dubbo 官方客户端或成熟 SDK，否则很容易在心跳、长连接复用、响应关联、序列化兼容和服务治理上踩坑。
Dubbo 返回结果后，适配层要把 RPC 响应转换成 HTTP 语义。正常业务结果一般序列化成 JSON 返回，业务异常可以映射为约定的业务错误码，参数错误映射为 400 类错误，无权限映射为 401 或 403，服务不存在或路由失败可以映射为 404 或 503，Dubbo 超时、provider 不可用、限流、熔断可以映射为 502、503 或 504，具体取决于团队的错误码规范。关键是不能简单把所有异常都返回 500，否则调用方无法区分是参数问题、权限问题、业务拒绝、后端不可用还是网关自身故障。
协议转换上线后，真正影响稳定性的往往是治理策略。HTTP 客户端有自己的超时，网关有处理超时，Dubbo consumer 也有调用超时，三者需要统一设计，避免外部请求已经断开而内部 RPC 还在重试。重试要谨慎，读接口可以按条件重试，写接口如果没有幂等保障就不应该随意重试。限流可以在 HTTP 入口按 AppId、用户、IP、接口维度做，也可以在 Dubbo consumer 侧按服务和方法做。熔断和降级用于 provider 异常时保护系统。
HTTP 请求通常带有 Token、Cookie、签名、AppKey 或网关认证信息，而 Dubbo 后端服务可能依赖用户身份、租户、来源应用、灰度标、traceId 等上下文。适配层要先完成认证鉴权，再把可信的身份信息放入 Dubbo attachment 或统一上下文中传递给下游。这里要注意不能把客户端传来的 Header 原样透传为内部身份，否则容易形成伪造风险。正确做法是网关验证后生成内部可信上下文，并只透传白名单字段。对于多租户和开放接口，还要有接口级授权、参数级权限、签名防重放和敏感字段脱敏。
HTTP 转 Dubbo 横跨入口层和 RPC 层，如果没有观测，很难定位问题。适配层至少要记录请求路径、目标 Dubbo 服务、方法、版本、调用耗时、返回码、异常类型、provider 地址、traceId 和灰度命中情况。链路追踪要把 HTTP span 和 Dubbo span 串起来，指标要能按接口、方法、应用、错误类型和 P99 延迟聚合。灰度方面，可以根据 Header、用户 ID、AppId、地域、租户或流量比例选择不同 Dubbo group、version 或 provider 集合。这样才能在接口迁移、版本升级和小流量验证时控制风险。
不一定。可以用 API 网关、BFF、业务适配服务，也可以在某个应用里直接提供 HTTP Controller，再调用 Dubbo consumer。区别在于职责边界：通用网关适合统一接入、鉴权、限流和动态路由；BFF 适合面向具体端做业务编排；业务应用内转换适合简单场景，但复用性和治理集中度较弱。
普通调用需要引入接口 jar，通过强类型代理调用，编译期能发现类型问题。泛化调用不依赖接口类，运行时传入接口名、方法名、参数类型和参数值，适合网关动态调用。泛化调用的代价是参数构造更复杂，类型校验更依赖元数据，排查问题也更依赖日志和配置治理。
适配层需要根据目标 Dubbo 方法签名知道参数类型，然后把 JSON 字段绑定到对应 DTO、Map、List、基本类型或枚举。这个过程包括字段名映射、类型转换、默认值、必填校验和嵌套对象处理。如果是泛化调用，复杂对象通常会被构造成 Map 结构，并带上必要的类型信息或依赖 Dubbo 的泛化序列化规则。
要区分异常类型。参数不合法通常返回 400，未认证返回 401，无权限返回 403，路由不到服务可返回 404 或 503，后端服务不可用返回 503，调用超时返回 504，网关自身异常返回 500。业务异常通常用 200 加业务错误码或 4xx 状态码都可以，但必须在团队内统一规范。
可以根据用户 ID、租户、AppId、Header、Cookie、地域或比例规则给请求打灰度标，然后映射到 Dubbo 的 group、version 或 provider 子集。关键是灰度规则要可配置、可回滚，并且日志和指标能显示每个请求命中了哪个版本，否则灰度问题很难排查。
Dubbo 协议不仅是请求头和 Body 编码，还涉及长连接管理、心跳、请求 ID 关联、负载均衡、注册发现、序列化兼容、过滤器链、路由、超时、重试和异常处理。自己手写容易遗漏治理能力，维护成本高。更合理的做法是让适配层作为标准 Dubbo consumer，通过官方客户端或成熟框架发起调用。
