经过前文讲述,我们的微服务架构日趋完善,已可使用Spring Cloud构建一个非常健壮的系统!
但假设,你的项目一旦出现问题,如何才能快速定位出来呢?一般项目上要求我们快速定位两种问题:
- 调用发生失败,快速定位出是哪个环节出了问题。是微服务问题,还是网络?
- 调用慢,如何快速找到性能瓶颈?
这正是调用链监控要做的事情。Spring Cloud提供Sleuth来实现调用链监控。
简介
Spring Cloud Sleuth为Spring Cloud提供了分布式跟踪的解决方案,它大量借用了Google Dapper、Twitter Zipkin和Apache HTrace的设计。
TIPS
- Spring Cloud Sleuth的GitHub:https://github.com/spring-cloud/spring-cloud-sleuth
- Dapper论文:https://research.google.com/pubs/pub36356.html
基本概念
(1) Span(跨度):
基本工作单元。span用一个64位的id唯一标识。除ID外,span还包含其他数据,例如描述、时间戳事件、键值对的注解(标签),span ID、span父ID等。
span被启动和停止时,记录了时间信息。初始化span被称为“root span”,该span的id和trace的id相等。
(2) Trace(跟踪):
一组共享“root span”的span组成的树状结构称为trace。trace也用一个64位的ID唯一标识,trace中的所有span都共享该trace的ID。
(3) Annotation(标注):
annotation用来记录事件的存在,其中,核心annotation用来定义请求的开始和结束。
1 2 3 4 5 6 7 | (1) cs(Client Sent 客户端发送):客户端发起一个请求,该annotation描述了span的开始。 (2) sr(Server Received 服务器端接收):服务器端获得请求并准备处理它。如果用sr减去cs时间戳,就能得到网络延迟。 (3) ss(Server Sent 服务器端发送):该annotation表明完成请求处理(当响应发回客户端时)。如果用ss减去sr时间戳,就能得到服务器端处理请求所需的时间。 (4) cr(Client Received 客户端接收):span结束的标识。客户端成功接收到服务器端的响应。如果cr减去cs时间戳,就能得到从客户端发送请求到服务器响应的所需的时间。 |
快速入门
-
加依赖:
1 2 3 4
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency>
-
加配置:
1 2 3 4
logging: level: root: INFO org.springframework.cloud.sleuth: DEBUG
其中,配置不是必选的,这里加上日志,只是为了看到更多Sleuth相关的日志。
是不是非常简单!
测试
-
启动
microservice-provider-user-sleuth
-
访问
http://localhost:8000/users/1
,可看到类似如下的日志:1 2 3 4 5 6 7
2019-03-13 23:32:46.913 INFO [microservice-provider-user,,,] 14759 --- [nio-8000-exec-1] o.apache.tomcat.util.http.parser.Cookie : A cookie header was received [1551574921,1551708812,1552142696] that contained an invalid cookie. That cookie will be ignored.Note: further occurrences of this error will be logged at DEBUG level. Hibernate: select user0_.id as id1_0_0_, user0_.age as age2_0_0_, user0_.balance as balance3_0_0_, user0_.name as name4_0_0_, user0_.username as username5_0_0_ from user user0_ where user0_.id=? 2019-03-13 23:32:46.975 TRACE [microservice-provider-user,e22f74e62c06104b,e22f74e62c06104b,false] 14759 --- [nio-8000-exec-1] o.h.type.descriptor.sql.BasicBinder : binding parameter [1] as [BIGINT] - [1] 2019-03-13 23:32:46.981 TRACE [microservice-provider-user,e22f74e62c06104b,e22f74e62c06104b,false] 14759 --- [nio-8000-exec-1] o.h.type.descriptor.sql.BasicExtractor : extracted value ([age2_0_0_] : [INTEGER]) - [20] 2019-03-13 23:32:46.982 TRACE [microservice-provider-user,e22f74e62c06104b,e22f74e62c06104b,false] 14759 --- [nio-8000-exec-1] o.h.type.descriptor.sql.BasicExtractor : extracted value ([balance3_0_0_] : [NUMERIC]) - [100.00] 2019-03-13 23:32:46.982 TRACE [microservice-provider-user,e22f74e62c06104b,e22f74e62c06104b,false] 14759 --- [nio-8000-exec-1] o.h.type.descriptor.sql.BasicExtractor : extracted value ([name4_0_0_] : [VARCHAR]) - [张三] 2019-03-13 23:32:46.982 TRACE [microservice-provider-user,e22f74e62c06104b,e22f74e62c06104b,false] 14759 --- [nio-8000-exec-1] o.h.type.descriptor.sql.BasicExtractor : extracted value ([username5_0_0_] : [VARCHAR]) - [account1]
从日志可以发现,此时日志多出来类似
[microservice-provider-user,e22f74e62c06104b,e22f74e62c06104b,false]
的内容。经过数据分析,就能实现本文开始提出的两个诉求啦!如何分析呢?且听下回分解。
TIPS
本文的例子本身意义不大,主要是让大家了解下Sleuth的基本概念以及如何整合。实现分布式应用的监控才有意义;另外完善的监控工具一般都会配备一个良好的界面,便于大家才能迅速了解系统的运行情况。这些都是下一节要探索的问题。