微服务实现-sleuth+zipkin分布式链路追踪和nacos配置中心

1. sleuth+zipkin分布式链路追踪

在大型系统的微服务化构建中,一个系统被拆分成了许多微服务。这些模块负责不同的功能,组合成系统,最终可以提供丰富的功能。
这种架构中,一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上,这些软件模块,又可能是由不同的团队开发,可能使用不同的编程语言来实现,有可能布在了几千台服务器,横跨多个不同的数据中心【区域】,也就意味着这种架构形式会存在一些问题

  1. 如何快速发现问题
  2. 如何判断故障影响范围
  3. 如何梳理服务依赖


分布式链路追踪(Di是tributed Tracing) ,就是将一次分布式请求还原成调用链路,进行日志记录、性能监控,并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时、请求具体到达哪台机器IP上、每个服务节点的请求状态200、500等
常见的链路追踪技术有:

  • cat 由大众点评开源,基于Java开发的实时应用监控平台,包括实时应用监控,业务监控 。 集成方案是通过代码埋点【代码】的方式来实现监控,比如: 拦截器,过滤器等。 对代码的侵入性很大,集成成本较高。风险较大。

  • zipkin 由Twitter公司开源,开放源代码分布式的跟踪系统。收集链路日志,并以图形化展示。

  • pinpointPinpoint是韩国人开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能强大,接入端无代码侵入。 没开源

  • skywalking 【未来企业会使用的多】

SkyWalking是本土开源的基于字节码注入的调用链分析,以及应用监控分析工具。特点是支持多种插件,UI功能较强,接入端无代码侵入。目前已加入Apache孵化器。 ---火。

  • Sleuth (日志记录每一条链路上的所有节点,以及这些节点所在的机器,和耗时。)log4j

在微服务端生成链路日志的。[只生成日志]

实现分布式链路追踪:sleuth【生成链路日志】+zipkin【收集链路日志,以图像化显示】

1.1 Sleuth介绍

SpringCloud Sleuth主要功能就是在分布式系统中提供追踪解决方案。它大量借用了Google Dapper的设计, 先来了解一下Sleuth中的术语和相关概念。

  • Trace[一条完整链路-包含很多span(微服务接口)]

由一组Trace Id(贯穿整个链路)相同的Span串联形成一个树状结构。为了实现请求跟踪,当请求到达分布式系统的入口端点时,只需要服务跟踪框架为该请求创建一个唯一的标识(即TraceId),同时在分布式系统内部流转的时候,框架始终保持传递该唯一值,直到整个请求的返回。那么我们就可以使用该唯一标识将所有的请求串联起来,形成一条完整的请求链路。

  • Span

代表了一组基本的工作单元。为了统计各处理单元的延迟,当请求到达各个服务组件的时候,也通过一个唯一标识(SpanId)来标记它的开始、具体过程和结束。通过SpanId的开始和结束时间戳,就能统计该span的调用时间,除此之外,我们还可以获取如事件的名称、请求信息等元数据。

  • Annotation

用它记录一段时间内的事件,内部使用的重要注释:

  • ==cs(Client Send)==客户端发出请求,开始一个请求的命令

  • ==sr(Server Received)==服务端接受到请求开始进行处理, sr-cs = 网络延迟(服务调用的时间)

  • ==ss(Server Send)==服务端处理完毕准备发送到客户端,ss - sr = 服务器上的请求处理时间

  • cr(Client Reveived)客户端接受到服务端的响应,请求结束。 cr - cs = 请求的总时间

1.2 使用sleuth

  • 引入依赖-避免代码重复,该依赖可以添加到父工程下

    xml 复制代码
     <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-starter-sleuth</artifactId>
            </dependency>
        </dependencies>

访问资源后,会在控制台打印生成的日志相关信息

1.3 使用zipkin

观察上面的sleuth日志非常不方便,使用zipkin来收集上面的日志并形成ui图形化界面

1.4 使用zipkin软件

  • 在官网下载zipkin软件

https://repo1.maven.org/maven2/io/zipkin/zipkin-server/

  • 启动zipkin软件服务------在命令行窗口启动

    java -jar zipkin.jar

  • 微服务连接到zipkin服务器端

    1. 在父工程下添加依赖

      xml 复制代码
       <!--zipkin-->
              <dependency>
                  <groupId>org.springframework.cloud</groupId>
                  <artifactId>spring-cloud-starter-zipkin</artifactId>
              </dependency>
    2. 在配置文件中添加zipkin的配置-加在所有微服务上

      properties 复制代码
      #zipkin的配置
      spring.zipkin.base-url=http://localhost:9411
  • 展示

http://127.0.0.1:9411/zipkin

2. 配置中心

对微服务中配置文件的统一管理

2.1 为什么使用配置中心

复制代码
思考: (1)每个微服务可能要搭建n台集群。这个集群中的微服务配置都是一样。如果需要修改服务的配置,就需要每个都要修改。              (2)各个微服务他们可能拥有相同的配置。

思路: 交给一个组件来统一管理。----配置中心。

2.2 常用的配置中心组件

  • Apollo

Apollo是由携程开源的分布式配置中心。特点有很多,比如:配置更新之后可以实时生效,支持灰度发布功能,并且能对所有的配置进行版本管理、操作审计等功能,提供开放平台API。并且资料 也写的很详细。----很好用--开源

  • Disconf

Disconf是由百度开源的分布式配置中心。它是基于Zookeeper来实现配置变更后实时通知和生效的。

  • SpringCloud Config

这是Spring Cloud中带的配置中心组件。它和Spring是无缝集成,使用起来非常方便,并且它的配置存储支持Git<git没学>。不过它没有可视化的操作界面,配置的生效也不是实时的,需要重启或去刷新。

  • Nacos

这是SpingCloud alibaba技术栈中的一个组件,前面我们已经使用它做过服务注册中心。其实它也集成了服务配置的功能,我们可以直接使用它作为服务配置中心。

2.3 如何使用nacos配置中心

1. 在配置中心中创建一个配置文件

2. 在微服务中使用

在微服务中添加nacos配置中心的依赖

xml 复制代码
 <!--nacos配置中心的依赖-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        </dependency>

3. 创建一个配置文件bookstrap.properties

properties 复制代码
#微服务的名称
spring.application.name=qy174-product
#配置中心的地址
spring.cloud.nacos.config.server-addr=127.0.0.1:8848

配置文件中需要包含:

  1. 微服务的名称
  2. 配置中心的地址

2.4 application和bootstrap的区别

bootstrap(.yml或者.properties):bootstrap由父ApplicationContext加载的,比application优先加载,且boostrap里面的属性不能被覆盖。一般用于加载外边配置内容
application(.yml或者.properties):用于spring boot项目的自动化配置

2.5 实时刷新

在读取配置中心内容的位置类上添加注解@RefreshScope

2.6 集群项目共享一个配置文件

将微服务中application.properties配置文件中的内容复制粘贴到nacos对应微服务配置中心的文件中即可,并将原来配置文件中的内容注释

此时,端口号就固定了,8002端口号不会被使用了

2.7 不同微服务共享相同的配置

1. 创建一个公共配置

2. 在微服务中的bootstrap.properties配置文件中使用公共配置

properties 复制代码
#扩展配置的名称
spring.cloud.nacos.config.extension-configs[0].data-id=datasource.properties
#扩展配置文件的组名
spring.cloud.nacos.config.extension-configs[0].group=DEFAULT_GROUP
#扩展配置文件是否实时刷新
spring.cloud.nacos.config.extension-configs[0].refresh=true
#扩展配置文件的后缀
spring.cloud.nacos.config.extension-configs[0].file-extension=properties

3. 在公共配置中添加公共的配置

相关推荐
mghio9 小时前
Dubbo 中的集群容错
java·微服务·dubbo
数据智能老司机16 小时前
CockroachDB权威指南——CockroachDB SQL
数据库·分布式·架构
数据智能老司机16 小时前
CockroachDB权威指南——开始使用
数据库·分布式·架构
数据智能老司机17 小时前
CockroachDB权威指南——CockroachDB 架构
数据库·分布式·架构
IT成长日记17 小时前
【Kafka基础】Kafka工作原理解析
分布式·kafka
州周19 小时前
kafka副本同步时HW和LEO
分布式·kafka
爱的叹息21 小时前
主流数据库的存储引擎/存储机制的详细对比分析,涵盖关系型数据库、NoSQL数据库和分布式数据库
数据库·分布式·nosql
千层冷面21 小时前
RabbitMQ 发送者确认机制详解
分布式·rabbitmq·ruby
ChinaRainbowSea21 小时前
3. RabbitMQ 的(Hello World) 和 RabbitMQ 的(Work Queues)工作队列
java·分布式·后端·rabbitmq·ruby·java-rabbitmq
敖正炀1 天前
基于RocketMQ的可靠消息最终一致性分布式事务解决方案
分布式