1.为什么需要调用链监控？

  随着系统规模越来越大，服务数目增加，各微服务间的调用关系也越来越错综复杂，通常一个客户端发起的请求在后端系统中会经过多个不同的微服务调用来协同产生结果并返回，在复杂的微服务架构系统中，几乎每一个前端请求都会形成一条复杂的分布式服务调用链路，在每条链路中任何一个依赖服务出现延迟过高或错误的时候都会引起请求最后的失败，这时候，对于每一个请求，调用链的跟踪就变得越来越重要，通过实现对请求调用的跟踪可以帮助我们快速发现错误以及监控分析每条链路上的性能瓶颈，现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》。

2.应用监控缺失会出现哪些问题

• 线上发布服务后，怎么知道这些服务是正常的
• 大量报错，根源在哪里
• 人工配置错误，查找起来要很久很久
• 会不会最后都把问题归根于“网络问题”
• 任何可能出错的地方都会出错，因此微服务需要监控

3.Spring Cloud Sleuth

Spring Cloud Sleuth也是依据Dapper论文而诞生的，它的核心概念是：

• Trace：一次分布式调用的链路踪迹
• Span：一个方法（局部或远程）调用踪迹
• Annotation：附着在Spane上的日志信息
• Sampling：采样率（0-1，1是全采样）
• 引用Sleuth官方提供的示意图（Sletuh官网地址），将Span和Trace在一个系统中使用Zipkin注解的过程图形化：
  
  

4.Zipkin

Zipkin 是一个开放源代码分布式的跟踪系统，由Twitter公司开源，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现，Zipkin的设计是基于谷歌的Google Dapper论文。
Zipkin的服务端已经打包成了一个 jar，使用 java -jar zipkin-server.jar 启动，访问 localhost:9411 查看zipkin主页

Zipkin官网地址：https://zipkin.io/

5.Spring Cloud Sleuth 与 Zipkin 的关系

Zipkin收集 Sleuth 产生的数据，并以界面的形式呈现出来

6.代码实践

请求流程：请求先到达service1，再到service2，由service2分别调用service3和service4，最后响应回去

所需环境：eureka，zipkin-server，4个服务

• 1.eureka使用之前博客中的，直接启动
• 2.启动zipkin-server，端口在9411
• 3.新建4个服务，引用都是一样的，下面以 service-a 服务为例（service-a 对应上面的 service1）：
  
• 4.项目依赖：

<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

• 5.配置文件：

server:
  port: 8071
spring:
  application:
    name: service-a
  sleuth:
    web:
      enabled: true
    sampler:
      probability: 1.0
  zipkin:
    base-url: http://localhost:9411

# 注册中心配置
eureka:
  instance:
    prefer-ip-address: true
    hostname: localhost
  client:
    service-url:
      defaultZone: http://zy:zy123@localhost:10025/eureka/

• 6.启动类：

@EnableDiscoveryClient
@SpringBootApplication
public class ServiceAApplication {

	public static void main(String[] args) {
		SpringApplication.run(ServiceAApplication.class, args);
	}

	@Bean
    @LoadBalanced
	public RestTemplate restTemplate(){
	    return new RestTemplate();
    }
}

• 7.添加控制器，开始远程调用

@RestController
public class IndexController {

    @Autowired private RestTemplate restTemplate;

    @RequestMapping("/index")
    public String index(){
        //远程调用service-b的方法，service-b分别调用service-c、service-b
        String result = remoteCallServiceB();
        return " service-a start ," + result;
    }

    //远程调用service-b
    private String remoteCallServiceB(){
        String url = "http://service-b/Second";
        String result = restTemplate.getForObject(url , String.class);
        return result;
    }
}

• 8.分别启动4个服务
  
• 9.访问 http://localhost:8071/index ，看到请求从 service-a 开始，service-d为止，最后正确返回
  
• 10.再访问 http://localhost:9411/ ，点击蓝色的 Find Traces 按钮 ，可以看到本次请求的详细信息与耗时：
  
  上面是本次请求经过了4个服务，每个服务的耗时，下面是每个服务的耗时，点击某个服务看详细
  
  点击service-b，查看详情
  
  以上是正常请求的展示过程，再模拟一个错误请求，看zipkin监控页面能否查看到

手动把 service-c 停掉，那么服务调用时，会出现错误，在zipkin监控页面能看到有一个请求是红色的错误提示

可以看到请求到 service-b 就停止了，没有到 service-c，点击最后那个service-b，可以看到详细错误信息

详细错误信息页面如下，service-b 调用 service-c 时，因停了 service-c ，所以没有发现可用实例

我们还可以在 zipkin 监控页面查看请求流程图，点击 Dependencies

好了，Spring Cloud Sleuth + Zipkin 调用链监控功能就完成了

代码已上传至码云：

• eureka-server
• sleuth

在团队小，业务量小时，为了快速开发，使用 Spring Cloud Sleuth + Zipkin可以快速进行微服务监控，但是 Zipkin 有些缺点

美团-大众点评在git上开源了 CAT 监控工具，有使用教程，超过8000课星，有业界一线的互联网公司接入（很成熟了，一些坑已经被踩了），在服务规模大时，接入 CAT 监控是个不错的选择
CAT 地址：https://github.com/dianping/cat

网友对 CAT 、Zipkin、Pinpoint等监控组件进行了对比