光效网站,为什么不用h5做网站,朋友圈转wordpress文章显示缩略图,县网站建设检查情况汇报1、基本概念和整合
1.1、为什么用 微服务架构是一个分布式架构#xff0c;它按业务划分服务单元#xff0c;一个分布式系统往往有很多个服务单元。由于服务单元数量众多#xff0c;业务的复杂性#xff0c;如果出现了错误和异常#xff0c;很难去定位 。主要体现在#…1、基本概念和整合
1.1、为什么用 微服务架构是一个分布式架构它按业务划分服务单元一个分布式系统往往有很多个服务单元。由于服务单元数量众多业务的复杂性如果出现了错误和异常很难去定位 。主要体现在一个请求可能需要调用很多个服务 而内部服务的调用复杂性决定了问题难以定位。所以微服务架构中必须实现分布式链路追踪去跟进一个请求到底有哪些服务参与参与的顺序又是怎样的从而达到每个请求的步骤清晰可见出了问题很快定位 。 链路追踪组件有 Google 的 Dapper Twitter 的 Zipkin 以及阿里的 Eagleeye 鹰眼等它们都是非常优秀的链路追踪开源组件。 1.2、基本术语
Span跨度基本工作单元发送一个远程调度任务 就会产生一个 SpanSpan 是一个 64 位 ID 唯一标识的Trace 是用另一个 64 位 ID 唯一标识的Span 还有其他数据信息比如摘要、时间戳事件、Span 的 ID、以及进度 ID。 Trace跟踪一系列 Span 组成的一个树状结构。请求一个微服务系统的 API 接口这个 API 接口需要调用多个微服务调用每个微服务都会产生一个新的 Span所有由这个请求产生的 Span 组成了这个 Trace。 Annotation标注用来及时记录一个事件的一些核心注解用来定义一个请求的开始和结束 。这些注解包括以下 cs - Client Sent -客户端发送一个请求这个注解描述了这个 Span 的开始 sr - Server Received -服务端获得请求并准备开始处理它如果将其 sr 减去 cs 时间戳便可得到网络传输的时间。 ss - Server Sent 服务端发送响应–该注解表明请求处理的完成(当请求返回客户端)如果 ss 的时间戳减去 sr 时间戳就可以得到服务器请求的时间。 cr - Client Received 客户端接收响应-此时 Span 的结束如果 cr 的时间戳减去cs 时间戳便可以得到整个请求所消耗的时间。 官方文档GitHub - spring-cloud/spring-cloud-sleuth at 2.2.x
如果服务调用顺序如下 那么用以上概念完整的表示出来如下 Span 之间的父子关系如下 2、整合 Sleuth 1、gulimall-common导入依赖 !--链路追踪 sleuth--dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-sleuth/artifactId/dependency
2 、每个微服务配置打开 debug 日志
logging:level:org.springframework.cloud.openfeign: debugorg.springframework.cloud.sleuth: debug 3、发起一次远程调用观察控制台
查看商品详情http://item.gulimall.com/10.html DEBUG [gulimall-product,541450f08573fff5,541450f08573fff5,false]
gulimall-product服务名
541450f08573fff5是 TranceId一条链路中只有一个 TranceId
541450f08573fff5是 spanId链路中的基本工作单元 id
false表示是否将数据输出到其他服务true 则会把信息输出到其他可视化的服务上观察
3、整合 zipkin 可视化观察 通过 Sleuth 产生的调用链监控信息可以得知微服务之间的调用链路但监控信息只输出到控制台不方便查看。我们需要一个图形化的工具-zipkin 。 Zipkin 是 Twitter 开源的分布式跟踪系统主要用来收集系统的时序数据从而追踪系统的调用问题。 zipkin 官网地址如下 OpenZipkin · A distributed tracing system 1、docker 安装 zipkin 服务器
docker run --name zipkin-server -d --restartalways -p 9411:9411 openzipkin/zipkin
2、导入 !--链路追踪 zipkin--dependencygroupIdorg.springframework.cloud/groupIdartifactIdspring-cloud-starter-zipkin/artifactId/dependency
zipkin 依赖也同时包含了 sleuth可以省略 sleuth 的引用
3、添加 zipkin 相关配置
spring:application:name: gulimall-product zipkin:base-url: http://192.168.56.10:9411/ # zipkin 服务器的地址# 关闭服务发现否则 Spring Cloud 会把 zipkin 的 url 当做服务名称discoveryClientEnabled: falsesender:type: web # 设置使用 http 的方式传输数据sleuth:sampler:probability: 1 # 设置抽样采集率为 100%默认为 0.1即 10%
发送远程请求测试 zipkin。
访问http://192.168.56.10:9411/ 服务调用链追踪信息统计 使用本地zipkin
Central Repository: io/zipkin/java/zipkin-server
java -jar zipkin-server-2.9.4-exec.jar
启动成功 访问http://127.0.0.1:9411/
spring:application:name: gulimall-product zipkin:base-url: http://127.0.0.1:9411/ # zipkin 服务器的地址# 关闭服务发现否则 Spring Cloud 会把 zipkin 的 url 当做服务名称discoveryClientEnabled: falsesender:type: web # 设置使用 http 的方式传输数据sleuth:sampler:probability: 1 # 设置抽样采集率为 100%默认为 0.1即 10% 4、Zipkin 数据持久化 Zipkin 默认是将监控数据存储在内存的如果 Zipkin 挂掉或重启的话那么监控数据就会丢失。所以如果想要搭建生产可用的 Zipkin就需要实现监控数据的持久化。而想要实现数据持久化自然就是得将数据存储至数据库。好在 Zipkin 支持将数据存储至 内存默认 MySQL Elasticsearch Cassandra Zipkin 数据持久化相关的官方文档地址如下GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system Zipkin 支持的这几种存储方式中内存显然是不适用于生产的这一点开始也说了。
而使用MySQL 的话当数据量大时查询较为缓慢也不建议使用。
Twitter 官方使用的是 Cassandra作为 Zipkin 的存储数据库但国内大规模用 Cassandra 的公司较少而且 Cassandra 相关文档也不多。 综上故采用 Elasticsearch 是个比较好的选择关于使用 Elasticsearch 作为 Zipkin 的存储数据库的官方文档如下 elasticsearch-storage zipkin/zipkin-server at master · openzipkin/zipkin · GitHub zipkin-storage/elasticsearchzipkin/zipkin-storage/elasticsearch at master · openzipkin/zipkin · GitHub 通过 docker 的方式
docker run --env STORAGE_TYPEelasticsearch --env ES_HOSTS192.168.56.10:9200
openzipkin/zipkin-dependencies 使用 es 时 Zipkin Dependencies 支持的环境变量
