![640?wx_fmt=gif](https://i-blog.csdnimg.cn/blog_migrate/3674b3ea574284e113a3808d24ad55ab.gif)
今天是南方的小年
南方的小年时间为
2019年1月29日
农历腊月廿四,星期二
小蜜蜂在此恭祝大家小年夜快乐!
^(* ̄(oo) ̄)^
SeviceComb + Zipkin 简介
ServiceComb 是Apache的微服务顶级项目,在微服务框架中,微服务之间通过网络进行通信,我们必须处理所有与网络相关的问题,例如延迟,超时和分区。随着部署的微服务越来越多,我们需要系统监控微服务网络延迟和请求流。
上篇文章我们介绍了如何使用ServiceComb与Zipkin进行协同定位微服务应用的异常的微服务和具体异常函数。
本篇将介绍ServiceComb如何通过自身handler处理链机制支持Zipkin 微服务级别和函数级别的调用链追踪的。
▼▼▼
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/1e8e6f2b4c704b5767e51ece3096c7af.png)
ServiceComb 如何支持zipkin
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/4422406a8d3b14b2b3a4e90d7426b22f.png)
ServiceComb 提供了处理链机制,消费端和服务端的调用链请求都会经过该处理链,通过扩展handler处理链接口,可以实现负载均衡、熔断容错、流量控制等能力。同样,调用链追踪能力也是通过扩展该接口实现的。
关于ServiceComb处理链参考 ↓↓↓
https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/intruduction.html
ServiceComb 扩展handler处理链接口,编写了handler-tracing-zipkin 模块。Handler-tracing-zipkin 模块在java-chassis/handler处理链下,模块内容如下。
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/a3caa8e5a0a218de33b207c9d4eef189.png)
handler-tracing-zipkin模块实现追踪调用链记录数据和上传追踪数据到zipkin服务,即可支持Zipkin。
如果读者对于使用ServiceComb对于Zipkin支持的能力还不熟悉,可参考ServiceComb官网相关文档↓↓↓
1.http://servicecomb.apache.org/docs/tracing-with-servicecomb/
2.https://servicecomb.apache.org/cn/docs/customized-tracing-with-servicecomb/
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/4422406a8d3b14b2b3a4e90d7426b22f.png)
handler-tracing-zipkin模块源码解读
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/1e8e6f2b4c704b5767e51ece3096c7af.png)
每一次接口调用请求都会触发handler链的处理,而在这个handler链当中,ServiceComb专门为Zipkin编写了handler类ZipkinConsumerTracingHandler
和ZipkinProviderTracingHandle进行适配。下面我们来看下这两个类。
ZipkinConsumerTracingHandler 和ZipkinProviderTracingHandler
查看这两个类源码可知,都继承自ZipkinTracingHandler
,都只有两个构造器。
区别在于分别向父类构造器传递了不同的ZipkinTracingDelegate实现。
ZipkinTracingDelegate实现分别为ZipkinConsumerDelegate和ZipkinProviderDelegate。
这两个代理类分别封装了对应的Zipkin请求消费和请求生产操作。下面重点看下ZipkinTracingHandler的源码实现。
ZipkinTracingHandler
handler类最重要的方法是handler方法,该方法接收一个Invocation对象和AsyncResponse对象(全是ServiceComb内置对象)。Invocation对象包含当前调用相关信息(包括HttpServletRequest对象)。下面我们看下这个方法做了什么事情。
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/75c295fd198a60d0c0e5f5edb38b84a5.png)
handler方法执行步骤:
一
调用了tracingDelegate.createSpan(invocation)方法创建了一个span。tracingDelegate是一个ZipkinTracingDelegate对象。
二
调用当前对象的onResponse方法封装成一个AsyncResponse对象。该对象是是一个函数式对象,在如下图的函数体中可看到最终调用了tracingDelegate.onResponse(span, response, error)上传span到Zipkin服务器。
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/10117fbd8fa673e5e0700ff7d035845e.png)
三
调用invocation.next()方法将生成的AsyncResponse对象传递给下一个handler处理。
四
如果在以上操作中发生异常,将调用tracingDelegate.onResponse(span, null, e)方法发送带有异常信息的span到Zipkin服务器。
从以上分析我们可以看到tracingDelegate十分重要,下面我们接着看这个ZipkinTracingDelegate接口到底做了什么。
ZipkinTracingDelegate接口
如下图,该接口定义了4个方法。
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/602002e3c8e279f26fd764332d197412.png)
1.tracer() ,获取对应的追踪器
2.createSpan(), 根据Invocation对象携带的信息创建对应的span
3.onResponse(),将span对象和对应的响应信息和异常信息上传到Zipkin服务器
4.name() , 区分消费操作和生产操作
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/f60ced7bce4557e228c5266bb9bb2cac.png)
该接口有两个实现类ZipkinConsumerDelegate
和ZipkinProviderDelegate,分别对应请求消费操作和请求生产操作。
下面我们可以看到两个实现的区别。
ZipkinConsumerDelegate和ZipkinProviderDelegate
下面我们先上两张图片仔细对比一下,第一张是ZipkinConsumerDelegate类,第二张是ZipkinProviderDelegate类。
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/47b086d09e25a093065462f83e116b24.png)
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/d073d5212cb2328f1f1d9812bffc5b34.png)
我们会发现它们都是用handler变量来进行相应的操作,注意这里的handler变量在两个类分别是不一样的类型,ZipkinConsumerDelegate的handler变量是HttpClientHandler对象,而ZipkinProviderDelegate的hanler变量是HttpServerHandler对象。HttpClientHandler和HttpServerHandler类都是final修饰的类,不可继承。前面我们看到创建span和发送span都是由这两个类来负责,那么我们来看下这两个对象怎么生成的。
仔细观察可发现↓↓↓
ZipkinConsumerDelegate构造器部分代码:
this.handler = HttpClientHandler.create(httpTracing, new ConsumerInvocationAdapter());
ZipkinProviderDelegate构造器部分代码 :
this.handler = HttpServerHandler.create(httpTracing, new ProviderInvocationAdapter());
从上面两段构造器代码中可发现HttpClientHandler和HttpServerHandler在创建对象时都分别传入ConsumerInvocationAdapter对象和ProviderInvocationAdapter对象,这两个对象分别继承了Zipkin的HttpClientAdapter和HttpServerAdapter抽象类,提供了属于ServiceComb本身的客户端信息和服务端信息。而Zipkin可以在不改动代码的情况下获取到这些定制信息并用于调用链追踪。
至此,ServiceComb如何一步一步去实现zipkin分布式调用链追踪,已经解读完毕。
链接
参考
1.zipkin https://zipkin.io/
2.Distributed Tracing with ServiceComb and Zipkin
http://servicecomb.apache.org/docs/tracing-with-servicecomb/
3.处理链参考
https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/intruduction.html
4.java-chassiss使用手册——调用参考
https://docs.servicecomb.io/java-chassis/zh_CN/
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/73db1e3caa3f4e4589e34f337c2021cf.png)
文末小结
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/94eeb3b2f7351d241e177b4d3b2ca124.png)
本文向社区读者从源码角度阐述了ServiceComb是如何支持Zipkin的。
我们也非常欢迎爱好者们向社区提问和贡献代码。
下章我们将介绍ServiceComb+SpringCloud Ribbon使用篇。
如果在阅读代码时有任何疑问想交流,欢迎扫码加入进微信群。
![640?wx_fmt=jpeg](https://i-blog.csdnimg.cn/blog_migrate/8f564ebcbfa727103b657eb72f93d240.jpeg)
期待志同道合的朋友们加入
ServiceComb的大门为你们敞开~
用心做开源,不忘初衷
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/51ea8db35acd4fb5a17b6f92745c7bec.png)
Holiday is Coming
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/6c14103d72352ad403543bfd6eed617c.png)
再次祝大伙儿小年快乐~
![640?wx_fmt=gif](https://i-blog.csdnimg.cn/blog_migrate/fdb328e5b676b7b1c20f8fac31fe5df2.gif)
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/6d69594d50c6b5cd8154dde765ccfa8e.jpeg)
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/5775440ed466d3a253ad8fca6d16f748.png)
前期阅读:
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/504ec6f7ecc605dba4d81e9ff509e750.png)
[学习微服务-第3天]ServiceComb内置高性能网关服务
[每天学习微服务-源码解读]ServiceComb+SpringCloud Zuul
[每天学习微服务-网关]ServiceComb+SpringCloud Zuul
------------------------------------------
了解更多信息请访问:
官方网站 http://servicecomb.apache.org/
Github代码仓库https://github.com/apache?q=ServiceComb
赶紧点击阅读原文阅读相关源码
并给ServiceComb点个“Star”吧
↓↓↓
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/9f262ff218b6d4820acca2082d618d24.png)