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

#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 大部分代码

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

新功能：PB 支持

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

新功能： 支持 context

其他优化和修复

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

新功能：支持 context