您好,登錄后才能下訂單哦!
本文小編為大家詳細(xì)介紹“go micro怎么集成鏈路跟蹤”,內(nèi)容詳細(xì),步驟清晰,細(xì)節(jié)處理妥當(dāng),希望這篇“go micro怎么集成鏈路跟蹤”文章能幫助大家解決疑惑,下面跟著小編的思路慢慢深入,一起來(lái)學(xué)習(xí)新知識(shí)吧。
opentracing是個(gè)規(guī)范,還需要搭配一個(gè)具體的實(shí)現(xiàn),比如zipkin、jeager等,這里選擇zipkin。
通過docker快速啟動(dòng)一個(gè)zipkin服務(wù)端:
docker run -d -p 9411:9411 openzipkin/zipkin
為了方便演示,這里把客戶端和服務(wù)端放到了一個(gè)項(xiàng)目中,程序的目錄結(jié)構(gòu)是這樣的:
main.go 服務(wù)端程序。client/main.go 客戶端程序。
config/config.go 程序用到的一些配置,比如服務(wù)的名稱和監(jiān)聽端口、zipkin的訪問地址等。
zipkin/ot-zipkin.go opentracing和zipkin相關(guān)的函數(shù)。
需要安裝go-micro、opentracing、zipkin相關(guān)的包:
go get go-micro.dev/v4@latest go get github.com/go-micro/plugins/v4/wrapper/trace/opentracing go get -u github.com/openzipkin-contrib/zipkin-go-opentracing
首先定義一個(gè)服務(wù)端業(yè)務(wù)處理程序:
type Hello struct { } func (h *Hello) Say(ctx context.Context, name *string, resp *string) error { *resp = "Hello " + *name return nil }
這個(gè)程序只有一個(gè)方法Say,輸入name,返回 "Hello " + name。
然后使用go-micro編寫服務(wù)端框架程序:
func main() { tracer := zipkin.GetTracer(config.SERVICE_NAME, config.SERVICE_HOST) defer zipkin.Close() tracerHandler := opentracing.NewHandlerWrapper(tracer) service := micro.NewService( micro.Name(config.SERVICE_NAME), micro.Address(config.SERVICE_HOST), micro.WrapHandler(tracerHandler), ) service.Init() micro.RegisterHandler(service.Server(), &Hello{}) if err := service.Run(); err != nil { log.Println(err) } }
這里NewService的時(shí)候除了指定服務(wù)的名稱和訪問地址,還通過micro.WrapHandler設(shè)置了一個(gè)用于鏈路跟蹤的HandlerWrapper。
這個(gè)HandlerWrapper是通過go-micro的opentracing插件提供的,這個(gè)插件需要傳入一個(gè)tracer。這個(gè)tracer可以通過前邊安裝的 zipkin-go-opentracing 包來(lái)創(chuàng)建,我們把創(chuàng)建邏輯封裝在了config.go中:
func GetTracer(serviceName string, host string) opentracing.Tracer { // set up a span reporter zipkinReporter = zipkinhttp.NewReporter(config.ZIPKIN_SERVER_URL) // create our local service endpoint endpoint, err := zipkin.NewEndpoint(serviceName, host) if err != nil { log.Fatalf("unable to create local endpoint: %+v\n", err) } // initialize our tracer nativeTracer, err := zipkin.NewTracer(zipkinReporter, zipkin.WithLocalEndpoint(endpoint)) if err != nil { log.Fatalf("unable to create tracer: %+v\n", err) } // use zipkin-go-opentracing to wrap our tracer tracer := zipkinot.Wrap(nativeTracer) opentracing.InitGlobalTracer(tracer) return tracer }
service創(chuàng)建完畢之后,還要通過 micro.RegisterHandler 來(lái)注冊(cè)前邊編寫的業(yè)務(wù)處理程序。
最后通過 service.Run 讓服務(wù)運(yùn)行起來(lái)。
再來(lái)看一下客戶端的處理邏輯:
func main() { tracer := zipkin.GetTracer(config.CLIENT_NAME, config.CLIENT_HOST) defer zipkin.Close() tracerClient := opentracing.NewClientWrapper(tracer) service := micro.NewService( micro.Name(config.CLIENT_NAME), micro.Address(config.CLIENT_HOST), micro.WrapClient(tracerClient), ) client := service.Client() go func() { for { <-time.After(time.Second) result := new(string) request := client.NewRequest(config.SERVICE_NAME, "Hello.Say", "FireflySoft") err := client.Call(context.TODO(), request, result) if err != nil { log.Println(err) continue } log.Println(*result) } }() service.Run() }
這段代碼開始也是先NewService,設(shè)置客戶端程序的名稱和監(jiān)聽地址,然后通過micro.WrapClient注入鏈路跟蹤,這里注入的是一個(gè)ClientWrapper,也是由opentracing插件提供的。這里用的tracer和服務(wù)端tracer是一樣的,都是通過config.go中GetTracer函數(shù)獲取的。
然后為了方便演示,啟動(dòng)一個(gè)go routine,客戶端每隔一秒發(fā)起一次RPC請(qǐng)求,并將返回結(jié)果打印出來(lái)。運(yùn)行效果如圖所示:
zipkin中跟蹤到的訪問日志:
Wrap從字面意思上理解就是封裝、嵌套,在很多的框架中也稱為中間件,比如gin中,再比如ASP.NET Core中。這個(gè)部分就來(lái)分析下go-micro中Wrap的原理。
在go-micro中服務(wù)端處理請(qǐng)求的邏輯封裝稱為Handler,它的具體形式是一個(gè)func,定義為:
func(ctx context.Context, req Request, rsp interface{}) error
這個(gè)部分就來(lái)看一下服務(wù)端Handler是怎么被Wrap的。
要想Wrap一個(gè)Handler,必須創(chuàng)建一個(gè)HandlerWrapper類型,這其實(shí)是一個(gè)func,其定義如下:
type HandlerWrapper func(HandlerFunc) HandlerFunc
它的參數(shù)和返回值都是HandlerFunc類型,其實(shí)就是上面提到的Handler的func定義。
以本文鏈路跟蹤中使用的 tracerHandler 為例,看一下HandlerWrapper是如何實(shí)現(xiàn)的:
func(h server.HandlerFunc) server.HandlerFunc { return func(ctx context.Context, req server.Request, rsp interface{}) error { ... if err = h(ctx, req, rsp); err != nil { ... } }
從中可以看出,Wrap一個(gè)Hander就是定義一個(gè)新Handler,在它的的內(nèi)部調(diào)用傳入的原Handler。
創(chuàng)建了一個(gè)HandlerWrapper之后,還需要把它加入到服務(wù)端的處理過程中。
go-micro在NewService的時(shí)候通過調(diào)用 micro.WrapHandler 設(shè)置這些 HandlerWrapper:
service := micro.NewService( ... micro.WrapHandler(tracerHandler), )
WrapHandler的實(shí)現(xiàn)是這樣的:
func WrapHandler(w ...server.HandlerWrapper) Option { return func(o *Options) { var wrappers []server.Option for _, wrap := range w { wrappers = append(wrappers, server.WrapHandler(wrap)) } o.Server.Init(wrappers...) } }
它返回的是一個(gè)函數(shù),這個(gè)函數(shù)會(huì)將我們傳入的HandlerWrapper通過server.WrapHandler轉(zhuǎn)化為一個(gè)server.Option,然后交給Server.Init進(jìn)行初始化處理。
這里的server.Option其實(shí)還是一個(gè)func,看一下WrapHandler的源碼:
func WrapHandler(w HandlerWrapper) Option { return func(o *Options) { o.HdlrWrappers = append(o.HdlrWrappers, w) } }
這個(gè)func將我們傳入的HandlerWrapper添加到了一個(gè)切片中。
那么這個(gè)函數(shù)什么時(shí)候執(zhí)行呢?就在Server.Init中。看一下Server.Init中的源碼:
func (s *rpcServer) Init(opts ...Option) error { ... for _, opt := range opts { opt(&s.opts) } if s.opts.Router == nil { r := newRpcRouter() r.hdlrWrappers = s.opts.HdlrWrappers ... s.router = r } ... }
它會(huì)遍歷傳入的所有server.Option,也就是執(zhí)行每一個(gè)func(o *Options)。這樣Options的切片HdlrWrappers中就添加了我們?cè)O(shè)置的HandlerWrapper,同時(shí)還把這個(gè)切片傳遞到了rpcServer的router中。
可以看到這里的Options就是rpcServer.opts,HandlerWrapper切片同時(shí)設(shè)置到了rpcServer.router和rpcServer.opts中。
還有一個(gè)問題:WrapHandler返回的func什么時(shí)候執(zhí)行呢?
這個(gè)在micro.NewService -> newService -> newOptions中:
func newOptions(opts ...Option) Options { opt := Options{ ... Server: server.DefaultServer, ... } for _, o := range opts { o(&opt) } ... }
遍歷opts就是執(zhí)行每一個(gè)設(shè)置func,最終執(zhí)行到rpcServer.Init。
到NewService執(zhí)行完畢為止,我們?cè)O(shè)置的WrapHandler全部添加到了一個(gè)名為HdlrWrappers的切片中。
再來(lái)看一下服務(wù)端Wrapper的執(zhí)行過程是什么樣的?
執(zhí)行Handler的這段代碼在rpc_router.go中:
func (s *service) call(ctx context.Context, router *router, sending *sync.Mutex, mtype *methodType, req *request, argv, replyv reflect.Value, cc codec.Writer) error { defer router.freeRequest(req) ... for i := len(router.hdlrWrappers); i > 0; i-- { fn = router.hdlrWrappers[i-1](fn) } ... // execute handler return fn(ctx, r, rawStream) }
根據(jù)前面的分析,可以知道router.hdlrWrappers中記錄的就是所有的HandlerWrapper,這里通過遍歷router.hdlrWrappers實(shí)現(xiàn)了HandlerWrapper的嵌套,注意這里遍歷時(shí)索引采用了從大到小的順序,后添加的先被Wrap,先添加在外層。
實(shí)際執(zhí)行時(shí)就是先調(diào)用到最先添加的HandlerWrapper,然后一層層向里調(diào)用,最終調(diào)用到我們注冊(cè)的業(yè)務(wù)Handler,然后再一層層的返回,每個(gè)HandlerWrapper都可以在調(diào)用下一層前后做些自己的工作,比如鏈路跟蹤這里的檢測(cè)執(zhí)行時(shí)間。
在客戶端中遠(yuǎn)程調(diào)用的定義在Client中,它是一個(gè)接口,定義了若干方法:
type Client interface { ... Call(ctx context.Context, req Request, rsp interface{}, opts ...CallOption) error ... }
我們這里為了講解方便,只關(guān)注Call方法,其它的先省略。
下面來(lái)看一下Client是怎么被Wrap的。
要想Wrap一個(gè)Client,需要通過struct嵌套這個(gè)Client,并實(shí)現(xiàn)Client接口的方法。至于這個(gè)struct的名字無(wú)法強(qiáng)制要求,一般以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實(shí)現(xiàn)的接口方法中都去調(diào)用了被嵌套Client的對(duì)應(yīng)接口方法,這是能夠嵌套執(zhí)行的關(guān)鍵。
有了上面的 XXXWrapper,還需要把它注入到程序的執(zhí)行流程中。
go-micro在NewService的時(shí)候通過調(diào)用 micro.WrapClient 設(shè)置這些 XXXWrapper:
service := micro.NewService( ... micro.WrapClient(tracerClient), )
和WrapHandler差不多,WrapClient的參數(shù)不是直接傳入XXXWrapper的實(shí)例,而是一個(gè)func,定義如下:
type Wrapper func(Client) Client
這個(gè)func需要將傳入的的Client包裝到 XXXWrapper 中,并返回 XXXWrapper 的實(shí)例。這里傳入的 tracerClient 就是這樣一個(gè)func:
return func(c client.Client) client.Client { if ot == nil { ot = opentracing.GlobalTracer() } return &otWrapper{ot, c} }
要實(shí)現(xiàn)Client的嵌套,可以給定一個(gè)初始的Client實(shí)例作為第一個(gè)此類func的輸入,然后前一個(gè)func的輸出作為后一個(gè)func的輸入,依次執(zhí)行,最終形成業(yè)務(wù)代碼中要使用的Client實(shí)例,這很像俄羅斯套娃,它有很多層Client。
那么這個(gè)俄羅斯套娃是什么時(shí)候創(chuàng)建的呢?
在 micro.NewService -> newService -> newOptions中:
func newOptions(opts ...Option) Options { opt := Options{ ... Client: client.DefaultClient, ... } for _, o := range opts { o(&opt) } return opt }
可以看到這里給Client設(shè)置了一個(gè)初始值,然后遍歷這些NewService時(shí)傳入的Option(WrapClient返回的也是Option),這些Option其實(shí)都是func,所以就是遍歷執(zhí)行這些func,執(zhí)行這些func的時(shí)候會(huì)傳入一些初始默認(rèn)值,包括Client的初始值。
那么前一個(gè)func的輸出怎么作為后一個(gè)func的輸入的呢?再來(lái)看下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中獲取到當(dāng)前的Client實(shí)例,把它傳給Wrap func,然后新生成的實(shí)例又被設(shè)置到Options的Client字段中。
正是這樣形成了前文所說(shuō)的俄羅斯套娃。
再來(lái)看一下客戶端調(diào)用的執(zhí)行流程是什么樣的?
通過service的Client()方法獲取到Client實(shí)例,然后通過這個(gè)實(shí)例的Call()方法執(zhí)行RPC調(diào)用。
client:=service.Client() client.Call()
這個(gè)Client實(shí)例就是前文描述的套娃實(shí)例:
func (s *service) Client() client.Client { return s.opts.Client }
前文提到過:XXXWrapper實(shí)現(xiàn)的接口方法中調(diào)用了被嵌套Client的對(duì)應(yīng)接口方法。這就是能夠嵌套執(zhí)行的關(guān)鍵。
這里給一張圖,讓大家方便理解Wrap Client進(jìn)行RPC調(diào)用的執(zhí)行流程:
一個(gè)重要的區(qū)別是:對(duì)于多次WrapClient,后添加的先被調(diào)用;對(duì)于多次WrapHandler,先添加的先被調(diào)用。
有一個(gè)比較怪異的地方是,WrapClient時(shí)如果傳遞了多個(gè)Wrapper實(shí)例,WrapClient會(huì)把順序調(diào)整過來(lái),這多個(gè)實(shí)例中前邊的先被調(diào)用,這個(gè)處理和多次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還提供了更低層級(jí)的CallWrapper,它的執(zhí)行順序和服務(wù)端HandlerWrapper的執(zhí)行順序一致,都是先添加的先被調(diào)用。
// wrap the call in reverse for i := len(callOpts.CallWrappers); i > 0; i-- { rcall = callOpts.CallWrappers[i-1](rcall) }
還有一個(gè)比較大的區(qū)別是,服務(wù)端的Wrap是調(diào)用某個(gè)業(yè)務(wù)Handler之前臨時(shí)加上的,客戶端的Wrap則是在調(diào)用Client.Call時(shí)就已經(jīng)創(chuàng)建好。這樣做的原因是什么呢?這個(gè)可能是因?yàn)樵诜?wù)端,業(yè)務(wù)Handler和HandlerWrapper是分別注冊(cè)的,注冊(cè)業(yè)務(wù)Handler時(shí)HandlerWrapper可能還不存在,只好采用動(dòng)態(tài)Wrap的方式。而在客戶端,通過Client.Call發(fā)起調(diào)用時(shí),Client是發(fā)起調(diào)用的主體,用戶有很多獲取Client的方式,無(wú)法要求用戶在每次調(diào)用前都臨時(shí)Wrap。
關(guān)于Http或者說(shuō)是Restful服務(wù)的鏈路跟蹤,go-micro的httpClient支持CallWrapper,可以用WrapCall來(lái)添加鏈路跟蹤的CallWrapper;但是其httpServer實(shí)現(xiàn)的比較簡(jiǎn)單,把http內(nèi)部的Handler處理完全交出去了,不能用WrapHandler,只能自己在http的框架中來(lái)做這件事,比如go-micro+gin開發(fā)的Restful服務(wù)可以使用gin的中間件機(jī)制來(lái)做鏈路追蹤。
讀到這里,這篇“go micro怎么集成鏈路跟蹤”文章已經(jīng)介紹完畢,想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過才能領(lǐng)會(huì),如果想了解更多相關(guān)內(nèi)容的文章,歡迎關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。