当服务微服务进行管理后,服务模块之前的调用拓扑非常的复杂。并且当每一个模块又有多个分布式集群等复杂的情况时,一个请求可能会调用后端的N多台服务,那么在追查问题的时候是非常麻烦的。一般不同的小组会负责不同的服务模块,则跨团队的协作是非常麻烦的。比如电商平台中,当一个请求进入后,api网关会根据URI会分发到不同的服务模块,比如当前调用到了订单系统,订单系统可能会去查下商品系统。我们原来的商品系统会根据业务分为好几个子系统,有的子系统还有自己的服务模块,总共商品有上百台服务器。那么在问题追踪的时候可以想象。
那么实现链路追踪对于微服务治理来说至关重要。
Zipkin 是 Twitter 的一个开源项目,它基于 Google Dapper 实现,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。 我们可以使用它来收集各个服务器上请求链路的跟踪数据,并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序,从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的 API 接口之外,它也提供了方便的 UI 组件来帮助我们直观的搜索跟踪信息和分析请求链路明细,比如:可以查询某段时间内各用户请求的处理时间等。 Zipkin 提供了可插拔数据存储方式:In-Memory、MySql、Cassandra 以及 Elasticsearch。
Zipkin 的架构,主要由 4 个核心组件构成:
Zipkin分为两端,一个是 Zipkin 服务端,一个是 Zipkin 客户端,客户端也就是微服务的应用。客户端会配置服务端的 URL 地址,一旦发生服务间的调用的时候,会被配置在微服务里面的 Sleuth 的监听器监听,并生成相应的 Trace 和 Span 信息发送给服务端。发送的方式主要有两种,一种是 HTTP 报文的方式,还有一种是消息总线的方式如 RabbitMQ。
不论哪种方式,我们都需要:
在 Spring Boot 2.0 版本之后,官方已不推荐自己搭建定制了,而是直接提供了编译好的 jar 包。详情可以查看官网:https://zipkin.io/pages/quickstart.html
我下载的是zipkin-server-2.23.2-exec.jar版本,下载之后启动
启动命令:java -jar zipkin-server-2.23.2-exec.jar
启动成功后访问:http://127.0.0.1:9411/
如上图,我们搭建了三个微服务,x-demo-springcloud-pay-service,x-demo-springcloud-user-service,x-demo-springcloud-order-service。在x-demo-springcloud-pay-service中调用user和order服务。
1、引入依赖
dependencies { compile("org.springframework.cloud:spring-cloud-starter-netflix-eureka-client") compile("org.springframework.cloud:spring-cloud-starter-zipkin") compile("org.springframework.cloud:spring-cloud-starter-netflix-ribbon") }
Spring Cloud 之 链路追踪Sleuth和Zipkin整合(十六)
原文:https://www.cnblogs.com/shileibrave/p/14462663.html