SpringCloud学习8（Spring Cloud Alibaba）链路追踪、配置中心NacosConfig

链路追踪（Sleuth & Zipkin）

微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。
分布式链路追踪(Distributed Tracing) ，就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将-次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

常见的链路追踪技术

• skywalking: SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器
• zipkin : 由Twiter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括: 数据的收集、存储、查找和展现。该产品结合spring-cloud-sleuth使用较为简单，集成很方便，但是功能较简单。
• sleuth ：Springcloud 提供的分布式系统中链路追踪解决方案
• cat : 由大众点评开源，基于Java开发的实时应用监控平台，包括实时应用监控，业务监控。 集成方案是通过代码埋点的方式来实现监控，比如: 拦截器，过滤器等。 对代码的侵入性很大，集成成本较高。风险较大.
• pinpoint : 韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。

Sleuth

引入依赖

<dependency>
    <groupId>org.springframework.cloudgroupId>
    <artifactId>spring-cloud-starter-sleuthartifactId>
dependency>

配置日志级别

logging:
  level:
    com.hx: debug

打印日志

// 在需要打印日志的类上加上注解
@Slf4j
// 在需要打印日志的地方，编写输出
log.debug("进入 ProductController 调用 getById " + "参数：" + pid);

Zipkin

安装Zipkin

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

访问：http://localhost:9411/zipkin/

添加依赖

<dependency>
    <groupId>org.springframework.cloudgroupId>
    <artifactId>spring-cloud-starter-zipkinartifactId>
dependency>

添加配置

spring: 
  zipkin:
    base-url: http://localhost:9411/    # zipkin server请求地址
    discovery-client-enabled: false     # 让nacos把他当成一个url，而不是服务名
  sleuth:
    sampler:
      probability: 1.0    # 采样百分比

测试

访问：http://localhost:8871/od/od/save?token=1&pid=123&num=2

更常用的是ELK

配置中心Nacos Config

配置中心介绍

首先我们来看一下,微服务架构下关于配置文件的一些问题:

1. 配置文件相对分散。在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。
2. 配置文件无法区分环境。微服务项目可能会有多个环境，例如: 测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。
3. 配置文件无法实时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说是非常不友好的。基于上面这些问题，我们就需要配置中心的加入来解决这些问题。

配置中心思路

首先把项目中的各种配置全部放到一个集中的地方进行统一管理，并提供一套标准的接口。
当各个服务需要获取配置的时候，就来配置中心的接口拉去自己的配置。
当配置中心的各种参数有更新的时候，也可以通知到各个服务实时的过来同步最新的消息，使它动态更新。
当加入了服务配置中心之后，我们的系统架构图如下：

常见的服务配置中心：

• Apollo：分布式配置中心。特点有配置更新可以实时生效，支持灰度发布，可以对所有配置进行版本控制，操作审计，提供开放平台API。
• Disconf：基于zookeeper来实现配置变更后实时通知和生效的开源分布式配置中心。
• SpringCloud Config：springcloud自带的配置中心组件，于Spring无缝集成，支持git存储。但是不是实时生效的，需要重启应用。
• Nacos Config：Nacos集成了服务配置的功能。可以直接使用作为配置中心。

Nacos Config入门

使用Nacos作为配置中心，其实就是将nacos当作一个服务端，将各微服务看成客户端，我们将各个微服务的配置文件统一存放到nacos上，然后各个微服务从nacos上拉取配置即可。

搭建nacos环境

省略，可以参考前面的步骤。

引入依赖

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-configartifactId>
dependency>

在微服务中添加nacos config配置

注意：这里不可以使用application.yml作为配置文件，而是新建一个bootstrap.yml作为配置文件。

配置文件优先级
bootstrap.properties  >  bootstrap.yml  >  application.properties  >  application.yml

spring:
  application:
    name: prod-service
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848   #nacos中心地址
        file-extension: yaml    # 配置文件格式
  profiles:
    active: dev

新建配置

注意：这里的文件名称不能随意配置，要和上面配置文件中的配置信息统一。对应关系见下图：

操作原理

观察启动后打印的日志，大体可以看出操作原理是：

1. 项目启动，先加载bootstrap.yml解析配置，得到3个核心信息
   • 服务名：
   • nacos配置中心地址
   • 激活环境
2. 访问nacos配置中心招项目的配置文件
   没有指定具体分组默认：DEFAULT_GROUP

组 + 服务名 + 激活环境 ==> DEFAULT_GROUP–prod-service-dev.yaml

Nacos Config配置动态刷新 @RefreshScope

需要在要求动态刷新配置的类上加上注解@RefreshScope
@RefreshScope操作原理：当配置发生更新时，贴有@RefreshScope注解的类，会在IOC容器中重新创建，该类中加载的数据重新更新。

@RefreshScope
public class Cloud2ProdApp {
	@Value("${app.name}")
	private String name;
	@RequestMapping("/name")
	public String name() {
	    return "
Cloud2ProdApp " + name + "
";
	}
}

配置共享

配置环境

• 开发dev：
• 测试test：
• 生产prod：

配置克隆

同一个微服务配置文件共享

只需要写一个以spring.application.name命名的配置文件即可：
application-dev.yml、application-test.yml、application-prd.yml
提取公共文件名：application.yml

不同的微服务配置文件共享

不同微服务之间也可以进行配置共享。原理类似于文件引入，就是定义一个公共配置文件，然后在当前配置文件中引入。
操作步骤：

1. 在nacos中定义一个DataID为 global-config.yaml 的配置，用于所有微服务共享。

globalConfig: global

2. 在bootstrap.yml文件中新增配置

spring: 
  cloud:
    nacos:
      config:
        shared-configs:
          - data-id: global-config.yaml
            refresh: true