go-micro集成链路跟踪的方法和中间件原理2

客户端Wrap

在客户端中远程调用的定义在Client中，它是一个接口，定义了若干方法：

type Client interface {
  ...
  Call(ctx context.Context, req Request, rsp interface{}, opts ...CallOption) error
  ...
}

我们这里为了讲解方便，只关注Call方法，其它的先省略。

下面来看一下Client是怎么被Wrap的。

XXXWrapper

要想Wrap一个Client，需要通过struct嵌套这个Client，并实现Client接口的方法。至于这个struct的名字无法强制要求，一般以XXXWrapper命名。

这里以链路跟踪使用的 otWrapper 为例，它的定义如下：

type otWrapper struct {
  ot opentracing.Tracer
  client.Client
}
func (o *otWrapper) Call(ctx context.Context, req client.Request, rsp interface{}, opts ...client.CallOption) error {
  ...
  if err = o.Client.Call(ctx, req, rsp, opts...); err != nil {
  ...
}
...

注意XXXWrapper实现的接口方法中都去调用了被嵌套Client的对应接口方法，这是能够嵌套执行的关键。

Wrap Client

有了上面的 XXXWrapper，还需要把它注入到程序的执行流程中。

go-micro在NewService的时候通过调用 micro.WrapClient 设置这些 XXXWrapper：

service := micro.NewService(
    ...
    micro.WrapClient(tracerClient),
  )

和WrapHandler差不多，WrapClient的参数不是直接传入XXXWrapper的实例，而是一个func，定义如下：

type Wrapper func(Client) Client

这个func需要将传入的的Client包装到 XXXWrapper 中，并返回 XXXWrapper 的实例。这里传入的 tracerClient 就是这样一个func：

return func(c client.Client) client.Client {
  if ot == nil {
    ot = opentracing.GlobalTracer()
  }
  return &otWrapper{ot, c}
}

要实现Client的嵌套，可以给定一个初始的Client实例作为第一个此类func的输入，然后前一个func的输出作为后一个func的输入，依次执行，最终形成业务代码中要使用的Client实例，这很像俄罗斯套娃，它有很多层Client。

那么这个俄罗斯套娃是什么时候创建的呢？

在 micro.NewService -> newService -> newOptions中：

func newOptions(opts ...Option) Options {
  opt := Options{
    ...
    Client:    client.DefaultClient,
    ...
  }
  for _, o := range opts {
    o(&opt)
  }
  return opt
}

可以看到这里给Client设置了一个初始值，然后遍历这些NewService时传入的Option（WrapClient返回的也是Option），这些Option其实都是func，所以就是遍历执行这些func，执行这些func的时候会传入一些初始默认值，包括Client的初始值。

那么前一个func的输出怎么作为后一个func的输入的呢？再来看下WrapClient的源码：

func WrapClient(w ...client.Wrapper) Option {
  return func(o *Options) {
    for i := len(w); i > 0; i-- {
      o.Client = w[i-1](o.Client)
    }
  }
}

可以看到Wrap方法从Options中获取到当前的Client实例，把它传给Wrap func，然后新生成的实例又被设置到Options的Client字段中。

正是这样形成了前文所说的俄罗斯套娃。

再来看一下客户端调用的执行流程是什么样的？

通过service的Client()方法获取到Client实例，然后通过这个实例的Call()方法执行RPC调用。

client:=service.Client()
client.Call()

这个Client实例就是前文描述的套娃实例：

func (s *service) Client() client.Client {
  return s.opts.Client
}

前文提到过：XXXWrapper实现的接口方法中调用了被嵌套Client的对应接口方法。这就是能够嵌套执行的关键。

这里给一张图，让大家方便理解Wrap Client进行RPC调用的执行流程：

客户端Wrap和服务端Wrap的区别

一个重要的区别是：对于多次WrapClient，后添加的先被调用；对于多次WrapHandler，先添加的先被调用。

有一个比较怪异的地方是，WrapClient时如果传递了多个Wrapper实例，WrapClient会把顺序调整过来，这多个实例中前边的先被调用，这个处理和多次WrapClient处理的顺序相反，不是很理解。

func WrapClient(w ...client.Wrapper) Option {
  return func(o *Options) {
    // apply in reverse
    for i := len(w); i > 0; i-- {
      o.Client = w[i-1](o.Client)
    }
  }
}

客户端Wrap还提供了更低层级的CallWrapper，它的执行顺序和服务端HandlerWrapper的执行顺序一致，都是先添加的先被调用。

  // wrap the call in reverse
  for i := len(callOpts.CallWrappers); i > 0; i-- {
    rcall = callOpts.CallWrappers[i-1](rcall)
  }

还有一个比较大的区别是，服务端的Wrap是调用某个业务Handler之前临时加上的，客户端的Wrap则是在调用Client.Call时就已经创建好。这样做的原因是什么呢？这个可能是因为在服务端，业务Handler和HandlerWrapper是分别注册的，注册业务Handler时HandlerWrapper可能还不存在，只好采用动态Wrap的方式。而在客户端，通过Client.Call发起调用时，Client是发起调用的主体，用户有很多获取Client的方式，无法要求用户在每次调用前都临时Wrap。

Http服务的链路跟踪

关于Http或者说是Restful服务的链路跟踪，go-micro的httpClient支持CallWrapper，可以用WrapCall来添加链路跟踪的CallWrapper；但是其httpServer实现的比较简单，把http内部的Handler处理完全交出去了，不能用WrapHandler，只能自己在http的框架中来做这件事，比如go-micro+gin开发的Restful服务可以使用gin的中间件机制来做链路追踪。

以上就是本文的主要内容，如有错漏欢迎指正。

代码已经上传到Github，欢迎访问：github.com/bosima/go-d…