构建了ELK的日志系统和监控系统这两个能够快速的发现系统中的问题,但是由于微服务架构中系统众多,系统之间的交互还比较复杂,在产生了大量的日志之后,可以帮助我们定位问题,但是在紧急情况下难以帮助我们快速,是快速的定位和解决问题,这个就调用链的设计初衷,在微服务中,调用链比较长的时候,如果出现问题,很容易出现踢皮球的情况,这种情况下,打开调用链,一看,谁的就是谁的不说不闹,多好。
市面上比较常见的APM有:pinpoint,Twitter的zipkin,美团的Cat,Google的Dapper,这里值得表扬美团,继续和金服的pk吧,最牛的还是Google,他发表了一篇Dapper就有好多公司去研究,最终形成自己的产品,不由的让我想起他的GFS,bigTable在大数据前期google为大数据所做的贡献,向慷慨的人致敬,懂得分享的人最可爱,嗯,对···进入正题
简单说一下调用链的东西TraceID 链路ID 在整个调用链中这个东西是不变的
SpanId 步骤ID 经过一个node就会变
ParentSpanID 很同意理解,这个spanId是从哪个span来的,这个设计很重要的
复杂的东西spring boot已经给我们封装好了
#######sleuth客户端
在需要跟踪的微服务中pom.xml加上
在application.yml中添加
pom.xml添加
并且在启动类上添加
客户端和服务端都启动,进入到zipkin服务端
可以根据时间,服务名称去查询,点击可查看调用链详情
因为现在zipkin的调用数据都是存在内存中的,一旦zipkin server重启,则意味着之前的都没有了,在这并发高的,一会就把内存挤爆了,所以最终zipkin的数据是要持久化的,要么mysql,这里采用ES,毕竟在大数据检索面前ES比mysql好很多很多
还有在页面请求量大的时候zipkin和ES直接联通存数据,肯定会阻塞,这里就用kafka来解决这个问题
pom.xml需要引入
application.yml添加
再次启动,加入数据,观察ES-head
已经将调用链存进去了,这里要感谢spring 将调用链集成,方便我们应用
望指正,不吝赐教
随着现在系统的逐步分布式化、规模化、微服务的流行,系统之间的调用越来越复杂,那么有一个自上而下的追踪系统就尤为重要了,我们可以快速定位到系统的瓶颈并作出相应的调整。
zipkin 是一款开源的分布式实时数据追踪系统(Distributed Tracking System),基于 Google Dapper 的论文设计而来,由 Twitter 公司开发贡献。其主要功能是聚集来自各个异构系统的实时监控数据,用来追踪微服务架构下的系统延时问题。(国内开源的还有美团点评的cat、京东的hydra)
github: https://github.com/openzipkin/zipkin
Quick Start
如果按照上文的获取官网jar包方式启动了zipkin-server,那么client启动之后,服务调用的请求就会以http请求的方式打到zipkin-server端,数据存在内存中,server重启之后丢失。上面的配置都增加了rabbitmq,作为中间件,zipkin-server也按照相应的配置来通过rabbitmq接收消息。
如果想定制zipkin-server的服务,比如作为服务发现节点、动态配置参数,那么可以自定义一个zipkin-server
加入eureka(服务发现)、sleuth、rabbit(消息中间件)、mysql(驱动包)、zipkin包(或者使用zipkin-autoconfigure-ui+spring-cloud-sleuth-zipkin-stream,不过我当时使用这两包有报错,所以替换掉了)
按照上面的配置搞定之后,分别启动rabbitmq、server、client,先调用几次服务,然后查看zipkin的web站 http://localhost:9411/
http://blog.spring-cloud.io/blog/sc-sleuth.html
http://spring-cloud.io/reference/sleuth/#_3
http://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/1.0.9.RELEASE/
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)