grpc-java是否有免实现thisUsesUnstableApi的CallCredentials稳定方案

我有一个充当代理角色的gRPC服务端，通过成对的 ServerInterceptor/ClientInterceptor 转发若干鉴权相关请求头，核心实现逻辑如下。
目前已知的为出站gRPC调用设置 Metadata 请求头的方式只有继承 CallCredentials 创建子类，但采用该方式必须实现 thisUsesUnstableApi 方法，显式声明使用不稳定API。

是否存在无需继承CallCredentials子类的稳定API替代方案？ #

ServerInterceptor 负责从 Metadata 中提取相关请求头并存入 Context，实现代码如下：

@Override
  public <ReqT, RespT> ServerCall.Listener<ReqT> interceptCall(
      ServerCall<ReqT, RespT> call,
      final Metadata requestHeaders,
      ServerCallHandler<ReqT, RespT> next) {
    Context contextWithAuth = Context.current();
    // 此处省略对示例无参考价值的工具类逻辑
    for (...) {
      contextWithAuth = contextWithAuth.withValue(Context.key(foo), requestHeaders.get(Metadata.Key.of(...)));
    }
    return Contexts.interceptCall(contextWithAuth, call, requestHeaders, next);
  }

ClientInterceptor 负责从 Context 中读取请求头，添加到出站请求的 Metadata 中，原有基于CallCredentials的实现代码如下：

@Override
  public <ReqT, RespT> ClientCall<ReqT, RespT> interceptCall(
      MethodDescriptor<ReqT, RespT> method, CallOptions callOptions, Channel next) {
    return next.newCall(
        method,
        callOptions.withCallCredentials(
            new CallCredentials() {
              @Override
              public void applyRequestMetadata(
                  RequestInfo requestInfo, Executor appExecutor, MetadataApplier applier) {
                try {
                  Metadata headers = new Metadata();
                  for (...) {
                    headers.put(Metadata.Key.of(...), Context.key(...).get());
                  }
                  applier.apply(headers);
                } catch (RuntimeException e) {
                  applier.fail(Status.UNAUTHENTICATED.withCause(e));
                }
              }

              @Override
              public void thisUsesUnstableApi() {
              }
            }));
    }

存在完全基于稳定API的实现方式，不需要继承 CallCredentials，直接在 ClientInterceptor 中包装返回的 ClientCall，重写 start 方法注入请求头即可，这也是官方拦截器示例推荐的标准写法。
具体实现逻辑：

• 拦截器拿到next通道创建的 ClientCall 实例后，包装一层gRPC核心包自带的 ForwardingClientCall.SimpleForwardingClientCall 做代理，不需要手动实现完整的ClientCall接口，大幅减少样板代码
• 重写包装类的 start(Listener responseListener, Metadata headers) 方法，在方法内部先把从Context中读取到的鉴权头写入传入的headers对象，再把headers传给原始ClientCall的start方法完成调用
• 注意：读取Context的逻辑必须放在start方法内执行，不要在interceptCall阶段直接读取。因为拦截器执行线程和实际请求发起线程可能不一致，Context是线程绑定的，在start方法内读取才能拿到正确的上下文值
  对应改造后的ClientInterceptor代码如下：

@Override
public <ReqT, RespT> ClientCall<ReqT, RespT> interceptCall(
    MethodDescriptor<ReqT, RespT> method, CallOptions callOptions, Channel next) {
  return new ForwardingClientCall.SimpleForwardingClientCall<ReqT, RespT>(next.newCall(method, callOptions)) {
    @Override
    public void start(Listener<RespT> responseListener, Metadata headers) {
      try {
        // 从当前Context读取鉴权头，写入出站Metadata
        for (...) {
          headers.put(Metadata.Key.of(...), Context.key(...).get());
        }
        super.start(responseListener, headers);
      } catch (RuntimeException e) {
        // 头注入失败直接返回未认证错误
        Metadata emptyHeaders = new Metadata();
        super.start(new ClientCall.Listener<RespT>() {}, emptyHeaders);
        cancel("Auth header injection failed", Status.UNAUTHENTICATED.withCause(e).asException());
      }
    }
  };
}

方案优势 #

• 完全使用gRPC稳定版公开API，没有任何不稳定注解标记，不需要覆写任何声明API不稳定的空方法
• 相比CallCredentials的实现方式，拦截器直接注入头的执行时机更早，不会和其他CallCredentials逻辑产生执行顺序冲突
• 扩展性更强，如果后续需要做异步的头获取逻辑（比如临时刷新过期token），只需要在拿到有效头之后再调用super.start即可，不需要依赖CallCredentials的异步回调机制

内容的提问来源于stack exchange，提问作者pgoldste