TarsGo 新版本发布，支持 protobuf， zipkin 和自定义插件

[sandyskies]

#TarsGo 新版本发布，支持 protobuf，zipkin 和自定义插件

Tars 是腾讯从 2008 年到今天一直在使用的后台逻辑层的统一应用框架，目前支持 C++,Java,PHP,Nodejs，Golang 语言。该框架为用户提供了涉及到开发、运维、以及测试的一整套解决方案，帮助一个产品或者服务快速开发、部署、测试、上线。 它集可扩展协议编解码、高性能 RPC 通信框架、名字路由与发现、发布监控、日志统计、配置管理等于一体，通过它可以快速用微服务的方式构建自己的稳定可靠的分布式应用，并实现完整有效的服务治理。目前该框架在腾讯内部，各大核心业务都在使用，颇受欢迎，基于该框架部署运行的服务节点规模达到上万个。 Tars 于 2017 年 4 月开源，并于 2018 年 6 月加入 Linux 基金会。 TarsGo 是 Tars 的 Go 语言实现版本， 于 2018 年 9 月开源， 项目地址 https://github.com/TarsCloud/TarsGo，欢迎 star。

##TarsGo 新版本发布 在上次开源之后，有些用户反馈了一些需求，基于用户反馈的需求，我们进行了实现，并发布了 1.1.0 版本。 本次发布新增了：支持 pb、支持 zipkin 分布式追踪、支持 filter （自定义插件编写）、支持 context 等，除此之外还做了一系列优化和 bugfix。

新功能：PB 支持

Protocol Buffers (简称 PB )是 Google 的一种数据交换的格式，它独立于语言，独立于平台，最早公布于 2008 年 7 月。随着微服务架构的发展及自身的优异表现，ProtoBuf 可用于诸如网络传输、配置文件、数据存储等诸多领域，目前在互联网上有着大量应用。 如果对于现有已使用 grpc，使用 proto 文件，想转换成 tars 协议的用户而言，需要将上面的 proto 文件翻译成 Tars 文件。这种翻译会比较繁琐，而且容易出错。 为此我们决定编写插件支持 proto 文件直接生成 tars 的 rpc 逻辑。protoc-gen-go 的代码逻辑里面是预留了插件编写的规范的，参照 grpc，主要有 grpc/grpc.go 和一个导入插件的 link_grpc.go 。 这里我们编写 tarsrpc/tarsrpc.go 和 link_tarsrpc.go 使用方面：

• 将这两个文件放到 protoc-gen-go 下面，go install 重新生成 protoc-gen-go 二进制

• 定义 proto 文件

• 使用重新编译安装的 protoc-gen-go 生成序列化和 rpc 相关接口代码

protoc --go_out=plugins=tarsrpc:. helloworld.proto

• 编写 tars 客户端和服务端代码，参数使用 pb 生成的结构体，其余代码逻辑和正常的 tars 服务一致。

• 详细原理和使用文档，阅读 腾讯云社区文章

新功能：filter 机制， 支持 zipkin 分布式追踪

为了支持用户编写插件，我们支持了 filter 机制，分为服务端的过滤器和客户端过滤器，用户可以基于这个机制，实现自己的 TarsGo 插件。

//服务端过滤器， 传入 dispatch，和 f， 用于调用用户代码，req， 和 resp 为传入的用户请求和服务端相应包体
type ServerFilter func(ctx context.Context, d Dispatch, f interface{}, req *requestf.RequestPacket, resp *requestf.ResponsePacket, withContext bool) (err error)
//客户端过滤器， 传入 msg （包含 obj 信息，adapter 信息，req 和 resp 包体）， 还有用户设定的调用超时
type ClientFilter func(ctx context.Context, msg *Message, invoke Invoke, timeout time.Duration) (err error)
//注册服务端过滤器
//func RegisterServerFilter(f ServerFilter)
//注册客户端过滤器
//func RegisterClientFilter(f ClientFilter)

有了过滤器，我们就能对服务端和客户端的请求做一些过滤，比如使用 hook 用于分布式追踪的 opentracing 的 span。 我们来看下客户端 filter 的例子：

//生成客户端 tars filter，通过注册这个 filter 来实现 span 的注入
func ZipkinClientFilter() tars.ClientFilter {
	return func(ctx context.Context, msg *tars.Message, invoke tars.Invoke, timeout time.Duration) (err error) {
		var pCtx opentracing.SpanContext
		req := msg.Req
		//先从客户端调用的 context 里面看下有没有传递来调用链的信息，
		//如果有，则以这个做为父 span，如果没有，则起一个新的 span，span 名字是 RPC 请求的函数名
		if parent := opentracing.SpanFromContext(ctx); parent != nil {
			pCtx = parent.Context()
		}
		cSpan := opentracing.GlobalTracer().StartSpan(
			req.SFuncName,
			opentracing.ChildOf(pCtx),
			ext.SpanKindRPCClient,
		)
		defer cSpan.Finish()
		cfg := tars.GetServerConfig()

		//设置 span 的信息，比如我们调用的客户端的 ip 地址，请求的接口，方法，协议，客户端版本等信息
		cSpan.SetTag("client.ipv4", cfg.LocalIP)
		cSpan.SetTag("tars.interface", req.SServantName)
		cSpan.SetTag("tars.method", req.SFuncName)
		cSpan.SetTag("tars.protocol", "tars")
		cSpan.SetTag("tars.client.version", tars.TarsVersion)

		//将 span 注入到 请求包体的  Status 里面，status 是一个 map[strint]string 的结构体
		if req.Status != nil {
			err = opentracing.GlobalTracer().Inject(cSpan.Context(), opentracing.TextMap, opentracing.TextMapCarrier(req.Status))
			if err != nil {
				logger.Error("inject span to status error:", err)
			}
		} else {
			s := make(map[string]string)
			err = opentracing.GlobalTracer().Inject(cSpan.Context(), opentracing.TextMap, opentracing.TextMapCarrier(s))
			if err != nil {
				logger.Error("inject span to status error:", err)
			} else {
				req.Status = s
			}
		}
		//没什么其他需要修改的，就进行客户端调用
		err = invoke(ctx, msg, timeout)
		if err != nil {
			//调用错误，则记录 span 的错误信息
			ext.Error.Set(cSpan, true)
			cSpan.LogFields(oplog.String("event", "error"), oplog.String("message", err.Error()))
		}

		return err
	}

服务端也会注册一个 filter，主要功能就是从 request 包体的 status 提取调用链的上下文，以这个作为父 span，进行调用信息的记录。 整体的一个效果：

详细代码参见 TarsGo/tars/plugin/zipkintracing 完整的 zipkin tracing 的客户端和服务端例子，详见 TarsGo/examples 下面的 ZipkinTraceClient 和 ZipkinTraceServer

新功能： 支持 context

TarsGo 之前在生成的客户端代码，或者用户传入的实现代码里面，都没有使用 context。 这使得我们想传递一些框架的信息，比如客户端 ip，端口等，或者用户传递一些调用链的信息给框架，都很难于实现。 通过接口的一次重构，支持了 context，这些上下文的信息，将都通过 context 来实现。 这次重构为了兼容老的用户行为，采用了完全兼容的设计。

服务端使用 context

type ContextTestImp struct {
}
//只需在接口上添加 ctx context.Context 参数
func (imp *ContextTestImp) Add(ctx context.Context, a int32, b int32, c *int32) (int32, error) {
	//我们可以通过 context 获取框架传递的信息，比如下面的获取 ip， 甚至返回一些信息给框架，详见 tars/util/current 下面的接口
	ip, ok := current.GetClientIPFromContext(ctx)
    if !ok {
        logger.Error("Error getting ip from context")
    }  
	return 0, nil
}
//以前使用 AddServant，现在只需改成 AddServantWithContext
app.AddServantWithContext(imp, cfg.App+"."+cfg.Server+".ContextTestObj")

客户端使用 context

    ctx := context.Background()
    c := make(map[string]string)
    c["a"] = "b" 
//以前使用 app.Add 进行客户端调用，这里只要变成 app.AddWithContext，就可以传递 context 给框架，如果要设置给 tars 请求的 context
//可以多传入参数，比如 c，参数 c 是可选的，格式是 ...[string]string
    ret, err := app.AddWithContext(ctx, i, i*2, &out, c)

服务端和客户端的完整例子，详见 TarGo/examples

其他优化和修复

• 将 request package 的 Sbuffer 字段由 vector<unsigned byte=""> 改成 vector<byte>,解决和其他语言通信问题</byte></unsigned>
• 修复 stat 监控上报问题
• 日志级别从远端更新
• 修复路由刷新协程极端情况下死锁问题
• 优化协程池方案，并添加协程池方案
• 修复 go 协程启动顺序导致 panic 问题
• golint 大部分代码