一、分布式链路追踪

1、为什么需要Spring Cloud Sleuth

微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。
举个例子，在微服务系统中，一个来自用户的请求，请求先达到前端A（如前端界面），然后通过远程调用，达到系统的中间件B、C（如负载均衡、网关等），最后达到后端服务D、E，后端经过一系列的业务逻辑计算最后将数据返回给用户。对于这样一个请求，经历了这么多个服务，怎么样将它的请求过程的数据记录下来呢？这就需要用到服务链路追踪。

2、Spring Cloud Sleuth基本术语

Spring Cloud Sleuth采用的是Google的开源项目Dapper的专业术语。

• Span：基本工作单元，发送一个远程调度任务 就会产生一个Span，Span是一个64位ID唯一标识的，Trace是用另一个64位ID唯一标识的，Span还有其他数据信息，比如摘要、时间戳事件、Span的ID、以及进度ID。
• Trace：一系列Span组成的一个树状结构。请求一个微服务系统的API接口，这个API接口，需要调用多个微服务，调用每个微服务都会产生一个新的Span，所有由这个请求产生的Span组成了这个Trace。
• Annotation：用来及时记录一个事件的，一些核心注解用来定义一个请求的开始和结束 。这些注解包括以下：
  (1)cs - Client Sent -客户端发送一个请求，这个注解描述了这个Span的开始
  (2) sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络传输的时间。
  (3)ss - Server Sent （服务端发送响应）–该注解表明请求处理的完成(当请求返回客户端)，如果ss的时间戳减去sr时间戳，就可以得到服务器请求的时间。
  (4)cr - Client Received （客户端接收响应）-此时Span的结束，如果cr的时间戳减去cs时间戳便可以得到整个请求所消耗的时间。

3、实战Spring Cloud Sleuth

基于之前使用到的组件包括：Eureka、Feign、Zuul，包括以下四个项目：
（1）Eureka-server： 8761 注册中心
（2）product-server ：8771 商品微服务
（3）order-server ： 8781 订单微服务
（4）zuul-gateway ： 9000 Zuul网关
我们分别在product-server和order-server上加上Sleuth依赖

    <dependency>
             <groupId>org.springframework.cloud</groupId>
             <artifactId>spring-cloud-starter-sleuth</artifactId>
     </dependency>

由于默认是日志级别是INFO，所以访问url看不到日志，就看不到效果
所以我们手动在两个微服务中都加入代码打印日志信息 如下

@Service
public class ProductServiceImpl implements ProductService {
    private final Logger logger=LoggerFactory.getLogger(getClass());
    @Override
    public Product findById(int id) {
        logger.info("service product find");
        return dtoMap.get(id);
    }
}

访问URL可以分别看到如下

eg：[order-service,dc1da5e886b48dcf,acea4312e3a6fca4,false]
1、第一个值，spring.application.name的值
2、第二个值，dc1da5e886b48dcf ，sleuth生成的一个ID，叫Trace ID，用来标识一条请求链路，一条请求链路中包含一个Trace ID，多个Span ID
3、第三个值，acea4312e3a6fca4、Span ID 基本的工作单元，获取元数据，如发送一个http
4、第四个值：false，是否要将该信息输出到zipkin服务中来收集和展示。

由此我们可以看到第二个值是相同的，链路追踪的也是通过同一个Trace ID串联起来进行追踪的

4、链路追踪组件Zipkin+Spring Cloud Sleuth

zipkin：大规模分布式系统的APM工具（Application Performance Management）,基于Google Dapper的基础实现，和sleuth结合可以提供可视化web界面分析调用链路耗时情况。
官网资料：
https://github.com/openzipkin/zipkin
https://zipkin.io/pages/quickstart.html
http://cloud.spring.io/spring-cloud-static/Finchley.SR1/single/spring-cloud.html#_sleuth_with_zipkin_via_http
原理：sleuth收集跟踪信息通过http请求发送给zipkin server，zipkinserver进行跟踪信息的存储以及提供Rest API即可，Zipkin UI调用其API接口进行数据展示。

• 安装Zipkin
  我是在用docker安装的步骤如下

//安装docker
$ sudo yum update
$ curl -fsSL https://get.docker.com -o get-docker.sh
$ sudo sh get-docker.sh
$ sudo systemctl start docker
//通过docker安装Zipkin
$ docker run -d -p 9411:9411 openzipkin/zipkin

• 安装完成后可访问Zipkin地址：ip+端口

  
  zipkin界面

• 加入依赖（此依赖中已经包含了sleuth）

    <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
    </dependency>

• 配置zipkin.base-url 、配置采样百分闭spring.sleuth.sampler

spring:
  application:
    name: product-service
  zipkin:
    base-url: http://192.168.216.128:9411/
#配置采样百分比 测试环境配置成1方便测试 生产环境最好还是按默认值0.1来
  sleuth:
    sampler:
      probability: 1

• 测试 访问几次接口后 刷新zipkin界面 可看到调用记录 点进去可以看到详细的信息

  
  
  

二、配置中心

1、微服务配置中心是什么

集中式配置是将应用系统中对配置信息的管理作为一个新的应用功能模块，区别与传统的配置信息分散到系统各个角落方式，进行集中统一管理，并且提供额外功能。尤其是在微服务架构中，是不可或缺组件之一。

2、为什么需要微服务配置中心

在微服务体系中，服务的数量以及配置信息的日益增多，比如各种服务器参数配置、各种数据库访问参数配置、各种环境下配置信息的不同、配置信息修改之后实时生效等等，传统的配置文件方式或者将配置信息存放于数据库中的方式已无法满足开发人员对配置管理的要求，如：

• 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏
• 时效性：修改配置，需要重启服务才能生效
• 局限性：无法支持动态调整：例如日志开关、功能开关

3、spring cloud config基础流程

spring cloud config基础流程

4、搭建配置中心

• 新建项目config-server 加入依赖

           <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-config-server</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
        </dependency>

• 启动类加入注解@EnableConfigServer

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {

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

}

• 默认使用git存储配置中心
  本次使用github(git/gitlab服务器,开源中国git、阿里云git等都可以)
  在github上添加项目,并创建文件如下：（文件内容写入服务对应配置）

  
  
• config-server配置文件添加配置(注意url要去掉.git)

server:
  port: 9100

#服务的名称
spring:
  application:
    name: config-server
  cloud:
    config:
      server:
        git:
          uri: https://github.com/yuanyuanqq/springcloud-config
          username: yuanyuanqq
          password: xxxxx
          timeout: 5
          default-label: master

#指定注册中心地址
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

• 启动项目 访问方式
  例子 http://localhost:9100/product-service-dev.yml
  • /{name}-{profiles}.properties
  • /{name}-{profiles}.yml
  • /{name}-{profiles}.json
  • /{label}/{name}-{profiles}.yml

name 服务器名称
profile 环境名称，开发、测试、生产
lable 仓库分支、默认master分支

5、配置中心客户端使用

官方文档：http://cloud.spring.io/spring-cloud-config/single/spring-cloud-config.html#_spring_cloud_config_client

• 加入依赖

<dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-config-client</artifactId>
</dependency>

• 修改对应服务的配置文件,把application.yml 改为 bootstrap.yml
  (因为bootstrap.yml 先于 application.yml 加载)
• 配置bootstrap.yml

#服务的名称
spring:
  application:
    name: product-service
#指定从哪个配置中心读取
  cloud:
    config:
      discovery:
        service-id: config-server
        enabled: true
      profile: dev
      label: master

#指定注册中心地址
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

注意点：
1.配置文件要用bootstrap.yml
2.默认读取文件名是 服务名称

• 启动项目进行测试
  github中文件product-service-dev.yml配置了端口号9200

  
  
  

  如上 可以发现product-service服务启动端口为9200 是用了配置中心的文件