2. RPC框架基础：原理、对比与调用模型

在深入Context Propagation之前，必须牢固掌握RPC框架的核心原理与主流实现。本章从远程过程调用的本质出发，对比gRPC、Dubbo、Thrift三大框架的架构差异，并剖析同步、异步、流式等调用模型对上下文传播路径的影响。

2.1 RPC核心原理

RPC（Remote Procedure Call）的目标是让开发者像调用本地函数一样调用远程服务。其核心流程包含五个阶段：

1. 客户端存根（Stub）：封装调用参数，执行序列化与协议编码。
2. 传输层：通过网络将请求数据包发送到服务端。
3. 服务端存根（Skeleton）：反序列化请求，还原参数并调用本地目标方法。
4. 执行与返回：服务端执行业务逻辑，将结果序列化后回传。
5. 客户端解包：反序列化响应，将结果返回给调用方。

2.2 常见RPC框架对比

当前生产环境最主流的RPC框架包括gRPC、Apache Dubbo和Apache Thrift。三者在协议、序列化、生态和上下文传播支持上存在显著差异。

2.3 RPC调用模型

RPC框架支持多种调用模型，不同模型对上下文传播的时机、线程模型和生命周期管理有直接影响。

2.3.1 同步调用（Sync）

客户端发起调用后阻塞等待响应。上下文传播路径最清晰：请求线程与响应线程相同，Context可通过ThreadLocal直接传递。

2.3.2 异步调用（Async / Future）

客户端发起调用后立即返回Future，通过回调或轮询获取结果。上下文传播面临线程切换问题：请求线程与回调线程可能不同，必须显式传递Context。

2.3.3 双向流调用（Bidirectional Streaming）

以gRPC为代表，客户端和服务端可同时发送多条消息。上下文传播需要处理流生命周期：每条消息可能携带独立的Context，框架需支持Context的增量更新与合并。

2.4 框架上下文传播机制详解

2.4.1 gRPC Metadata 与 Context

gRPC原生支持上下文传播：

• Metadata：键值对结构，随每个RPC请求传输，适合传递Trace ID、Auth 等。
• io.grpc.Context：与请求绑定的作用域上下文，支持子Context继承与取消传播。
• 拦截器（Interceptor）：通过ClientInterceptor/ServerInterceptor统一注入和提取Context。

// gRPC 客户端拦截器注入Context
public class ContextClientInterceptor implements ClientInterceptor {
  @Override
  public <ReqT, RespT> ClientCall<ReqT, RespT> interceptCall(
      MethodDescriptor<ReqT, RespT> method, CallOptions callOptions, Channel next) {
    return new ForwardingClientCall.SimpleForwardingClientCall<>(next.newCall(method, callOptions)) {
      @Override
      public void start(Listener<RespT> responseListener, Metadata headers) {
        // 将当前Context中的traceId注入Metadata
        headers.put(HeaderKey.TRACE_ID, ContextStorage.getTraceId());
        super.start(responseListener, headers);
      }
    };
  }
}

2.4.2 Dubbo RpcContext 与 Attachment

Dubbo通过RpcContext提供隐式参数传递：

• RpcContext.getContext()：获取当前线程绑定的上下文对象。
• setAttachment / getAttachment：在调用端设置隐式参数，服务端自动接收。
• 异步兼容：Dubbo 2.7+ 支持AsyncContext，解决异步线程的Context传递问题。

// Dubbo 客户端设置隐式参数
RpcContext.getContext().setAttachment("traceId", "abc-123");
// 服务端获取隐式参数
String traceId = RpcContext.getContext().getAttachment("traceId");

2.4.3 Thrift 自定义上下文

Thrift未内置上下文传播机制，需通过以下方式扩展：

• 协议层扩展：在TProtocol中嵌入自定义字段。
• 传输层包装：使用TTransportWrapper在消息头前后附加元数据。
• 处理器拦截：实现TProcessor接口，在方法调用前后注入Context。

2.5 调用模型对Context传播的约束总结