链路追踪（Sleuth & Zipkin）
微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。
分布式链路追踪(Distributed Tracing) ，就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将-次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。
常见的链路追踪技术
- skywalking: SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器
- zipkin : 由Twiter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括: 数据的收集、存储、查找和展现。该产品结合spring-cloud-sleuth使用较为简单，集成很方便，但是功能较简单。
- sleuth ：Springcloud 提供的分布式系统中链路追踪解决方案
- cat : 由大众点评开源，基于Java开发的实时应用监控平台，包括实时应用监控，业务监控。 集成方案是通过代码埋点的方式来实现监控，比如: 拦截器，过滤器等。 对代码的侵入性很大，集成成本较高。风险较大.
- pinpoint : 韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。
Sleuth
引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</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.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</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
配置中心介绍
首先我们来看一下,微服务架构下关于配置文件的一些问题:
- 配置文件相对分散。在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。
- 配置文件无法区分环境。微服务项目可能会有多个环境，例如: 测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。
- 配置文件无法实时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说是非常不友好的。基于上面这些问题，我们就需要配置中心的加入来解决这些问题。
配置中心思路
首先把项目中的各种配置全部放到一个集中的地方进行统一管理，并提供一套标准的接口。
当各个服务需要获取配置的时候，就来配置中心的接口拉去自己的配置。
当配置中心的各种参数有更新的时候，也可以通知到各个服务实时的过来同步最新的消息，使它动态更新。
当加入了服务配置中心之后，我们的系统架构图如下：
常见的服务配置中心：
- Apollo：分布式配置中心。特点有配置更新可以实时生效，支持灰度发布，可以对所有配置进行版本控制，操作审计，提供开放平台API。
- Disconf：基于zookeeper来实现配置变更后实时通知和生效的开源分布式配置中心。
- SpringCloud Config：springcloud自带的配置中心组件，于Spring无缝集成，支持git存储。但是不是实时生效的，需要重启应用。
- Nacos Config：Nacos集成了服务配置的功能。可以直接使用作为配置中心。
Nacos Config入门
使用Nacos作为配置中心，其实就是将nacos当作一个服务端，将各微服务看成客户端，我们将各个微服务的配置文件统一存放到nacos上，然后各个微服务从nacos上拉取配置即可。
搭建nacos环境
省略，可以参考前面的步骤。
引入依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</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
新建配置
注意：这里的文件名称不能随意配置，要和上面配置文件中的配置信息统一。对应关系见下图：
操作原理
观察启动后打印的日志，大体可以看出操作原理是：
- 项目启动，先加载bootstrap.yml解析配置，得到3个核心信息
- 服务名：
- nacos配置中心地址
- 激活环境
- 访问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 "<h1>Cloud2ProdApp " + name + "</h1>";
}
}
配置共享
配置环境
- 开发dev：
- 测试test：
- 生产prod：
配置克隆
同一个微服务配置文件共享
只需要写一个以spring.application.name命名的配置文件即可：
application-dev.yml、application-test.yml、application-prd.yml
提取公共文件名：application.yml
不同的微服务配置文件共享
不同微服务之间也可以进行配置共享。原理类似于文件引入，就是定义一个公共配置文件，然后在当前配置文件中引入。
操作步骤：
- 在nacos中定义一个DataID为 global-config.yaml 的配置，用于所有微服务共享。
globalConfig: global
- 在bootstrap.yml文件中新增配置
spring:
cloud:
nacos:
config:
shared-configs:
- data-id: global-config.yaml
refresh: true