ServiceComb+Zipkin：使用篇

分布式调用链追踪能有效地监控服务间的网络延时并可视化微服务中的数据流转。ServiceComb扩展了zipkin的接口提供了服务内部的链路调用信息，能提供更完整的调用链路信息，更容易定位问题和潜在性能问题。本文将介绍ServiceComb 提供的分布式调用链追踪能力及使用指导。

一. 异常场景示例

我们将使用ServiceComb的入门案例BMI（体质指数应用），展示ServiceComb的调用链追踪和自定义调用链追踪能力。BMI应用程序包含体质指数计算calculator和服务网关webapp两个服务，参见ServiceComb的入门案例BMI指导¹。
我们给BMI的calculator微服务增加了异常代码，如下。

public double calculate(double height, double weight) {

	// 异常代码：增加一块进程休眠代码（模拟实际工作中调用当前线程处理其他业务的情景）
    try{
    Thread.currentThread().sleep(5000);
    } catch (Exception e){	
    }
	// 正常代码：计算身高体重的bmi值
    if (height <= 0 || weight <= 0) {
      throw new IllegalArgumentException("Arguments must be above 0");
    }
    double heightInMeter = height / 100;
    double bmi = weight / (heightInMeter * heightInMeter);
    return roundToOnePrecision(bmi);
  }	

参见BMI程序使用指导¹，运行bmi程序，出现如下异常结果。

二. 使用Zipkin定位服务级别异常

以上的BMI示例还未开启调用链追踪，下面我们将使用ServiceComb提供的分布式调用链追踪能力定位分析BMI应用的哪个服务发生了异常。

首先需要给BMI程序配置zipkin调用链追踪能力，只需添加两个配置即可。可参考分布式追踪²和Distributed Tracing with ServiceComb and Zipkin³。

1. 添加依赖
   在 calculator微服务 的 pom.xml 文件中添加依赖项：

   <dependency>
     <groupId>org.apache.servicecomb</groupId>
     <artifactId>handler-tracing-zipkin</artifactId>
   </dependency>
   

   在 webapp微服务 的 pom.xml 文件中添加依赖项：

   <dependency>
     <groupId>org.apache.servicecomb</groupId>
     <artifactId>spring-cloud-zuul-zipkin</artifactId>
   </dependency>
   

2. 配置跟踪处理程序
   在 calculator微服务 的 microservice.yaml 文件中添加分布式追踪的处理链：

   servicecomb:
     handler:
       chain:
         Provider:
           default: tracing-provider
   

到此已配置完毕，您只需执行以下几步即可运行：

使用 Docker 运行 Zipkin 分布式追踪服务：

docker run -d -p 9411:9411 openzipkin/zipkin

重启 calculator 微服务：

mvn spring-boot:run -Drun.jvmArguments="-Dcse.handler.chain.Provider.default=tracing-provider"

重启 webapp 微服务：

mvn spring-boot:run -Drun.jvmArguments="-Dservicecomb.tracing.enabled=true"

打开浏览器访问 http://localhost:9411 ，查看调用链追踪情况和程序报错信息，结果如下。可以看到gateway服务在1.7S时就返回给了用户失败结果，而calculator服务却运行了5S的时间，但calculator为蓝色（并非内部错误），可以确定calculator 服务超时导致gateway超时异常。
我们通过在后台服务打印程序调用栈日志可以看到，异常是由于socket读取超时，可以印证我们在Zipkin中看到的结果。

三、使用自定义追踪功能定位到函数级别

以上已确定导致超时返回的是calculator服务，在服务应用代码较大时，会较难找到具体出现异常的地点，ServiceComb支持可以在服务内部进行函数级别的调用链打点追踪，这将可以帮助我们解决这个问题。

首先，配置BMI程序的自定义追踪功能，只需三步即可。

参考java-chassis使用手册——自定义调用链打点⁴。
在 体质指数计算器 的 pom.xml 文件中添加依赖项：

<dependency>
  <groupId>org.apache.servicecomb</groupId>
  <artifactId>tracing-zipkin</artifactId>
</dependency>

在程序入口或者配置处添加 @EnableZipkinTracing 注解

import org.apache.servicecomb.tracing.zipkin.EnableZipkinTracing;

@SpringBootApplication
@EnableServiceComb
@EnableZipkinTracing
public class CalculatorApplication {

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

在 服务程序中的调用方法处添加 @Span 注解

import org.apache.servicecomb.tracing.Span;

@Service
public class CalculatorServiceImpl implements CalculatorService {

  /**
   * {@inheritDoc}
   */
  @Span
  @Override
  public double calculate(double height, double weight) {
    if (height <= 0 || weight <= 0) {
      throw new IllegalArgumentException("Arguments must be above 0");
    }
    double heightInMeter = height / 100;
    double bmi = weight / (heightInMeter * heightInMeter);
    return roundToOnePrecision(bmi);
  }

  private double roundToOnePrecision(double value) {
    return new BigDecimal(value).setScale(1, RoundingMode.HALF_UP).doubleValue();
  }
}

import org.apache.servicecomb.tracing.Span;

@Service
public class InstanceInfoServiceImpl implements InstanceInfoService {

  /**
   * {@inheritDoc}
   */
  @Span
  @Override
  public String getInstanceId() {

    MicroserviceInstance instance = RegistryUtils.getMicroserviceInstance();
    if (instance == null) {
      throw new IllegalStateException(
          "unable to find any service instances, maybe there is problem registering in service center?");
    }
    return instance.getInstanceId();
  }
}

至此，自定义函数级别打点配置完成。
运行程序，从Zipkin界面如下：

可以看到，调用链中新增加了calculate函数这个Span（上图红圈处），耗时5S。
点开该Span，可以查看该函数的详细信息，我们可以根据该信息准确查找到对应的源码进行修正。

四、总结

本例子为了最简化读者理解，使用了仅有两个微服务的BMI用例，在实际的生产环境中，微服务数量繁多将导致问题的定位变得复杂，调用链追踪和自定义追踪能力，可以帮助我们高效地解决这个问题。

五、参考

---

1. ServiceComb的入门案例BMI指导 ↩︎ ↩︎

2. 分布式追踪 ↩︎

3. Distributed Tracing with ServiceComb and Zipkin ↩︎

4. java-chassis使用手册——自定义调用链打点 ↩︎