SpringCloud入门(七)

亦凉 2021-12-19 02:23 287阅读 0赞

代码地址  [https://github.com/springcloud-demo][https_github.com_springcloud-demo]

**目录**

第一章 服务容错和Hystrix

第二章 触发降级

第三章 超时设置

第四章 探讨断路器模式

4.1 使用配置项

4.2 feign-hystrix的使用

4.3 hystrix -dashboard

4.4 Zuul超时配置

第五章 服务追踪

5.1 Sleuth

5.2 Zipkin

5.3 分布式追踪系统

--------------------

# 第一章 服务容错和Hystrix #

在微服务架构层中,通常会有多个服务相互调用,如果有某个服务不可用,导致近邻故障,造成整个系统不可用的情况称为雪崩效应.

比如A会调用B服务,B会调用C服务,假如B调用C服务的时候因为某种原因调用不成功,B就会一直重试同步等待造成资源耗尽,结果B服务也不可用,紧接着因为A调用B,A也不可用了,A,B,C都不可用,这样最终会导致A,B,C都不可用.

SpringCloud中防止雪崩的利器就是Hystric,基于netflix对应的Hystrix,Hystrix的中文意思是豪猪,

SpringCloud具备服务降级,服务熔断,依赖隔离,监控等强大的功能.

服务降级:双十一来的时候某宝会显示哎呦欸,挤爆了,或者是某些APP会提示网络开小差了,请稍后再试,服务降级的指导思想是要区分业务,具体就是要优先核心服务,非核心服务不可用或弱可用,站在整个系统来看,比如我们的点餐业务突然涌入大量流量,服务器资源就这么多,那我们应优先选择商品,订单,支付服务,另外比如广告积分属于非核心服务,这种业务暂时不提供服务或者提供部分服务.

在某个具体服务中,比如商品服务,可能买家查询服务优先保护它的可用,卖家查询可能就是非核心服务,可以区别对待.

在用的层面上来说,Hystric的服务降级是非常简单,概括来讲,通过HystricCommand注解指定,在fallbackMethod(回退函数)中具体实现降级逻辑即可.

# 第二章 触发降级 #

订单去调用商品服务,当你想调用的目标服务,即server端不能正常提供服务的时候,会发生降级.

打开order项目,实现订单服务调用商品服务.

@RestController
    public class HystrixController {
    
        @HystrixCommand(fallbackMethod = "fallback")
        @GetMapping("/getProductInfoList")
        public String getProductInfoList(){
            RestTemplate restTemplate = new RestTemplate();
            return  restTemplate.postForObject("http://127.0.0.1:8082/product/listForOrder",
                    Arrays.asList("157875196366160022"),
                    String.class);
        }
    
        private String fallback(){
            return "太拥挤了,请稍后再试~~";
        }
    }

在application中加上注解@EnableCircuitBreaker

我这里加的SpringCloudApplication等于注释中的三个注解.

/*@SpringBootApplication
    @EnableDiscoveryClient
    @EnableCircuitBreaker*/
    @EnableFeignClients(basePackages = "com.imooc.product.client")
    @SpringCloudApplication
    public class OrderApplication {
    	public static void main(String[] args) {
    		SpringApplication.run(OrderApplication.class, args);
    	}
    }

当然降级也不一定是用在这种场景,我们也可以用到自己的服务降级,当并发太高,或者服务连接数太多了,主动抛出异常,即可实现服务降级.

这里检测到异常,直接会运行对应的fallback函数.

@RestController
    public class HystrixController {
    
        @HystrixCommand(fallbackMethod = "fallback")
        @GetMapping("/getProductInfoList")
        public String getProductInfoList(){
    //        RestTemplate restTemplate = new RestTemplate();
    //        return  restTemplate.postForObject("http://127.0.0.1:8082/product/listForOrder",
    //                Arrays.asList("157875196366160022"),
    //                String.class);
    //        if(服务太多,并发太高)
            throw new RuntimeException("发生异常了");
        }
    
        private String fallback(){
            return "太拥挤了,请稍后再试~~";
        }
    }

# 第三章 超时设置 #

我刚才写了一个注解@HystrixCommand(fallbackMethod = "fallback")就调了一个fallback方法,如果有很多个要写很多,这里提供了一个@DefaultProperties(defaultFallback = "defaultFallback").

@RestController
    @DefaultProperties(defaultFallback = "defaultFallback")
    public class HystrixController {
    
        @HystrixCommand
        @GetMapping("/getProductInfoList")
        public String getProductInfoList(){
            throw new RuntimeException("发生异常了");
        }
    
    
        private String defaultFallback(){
            return "默认提示:太拥挤了,请稍后再试~~";
        }
    
    }

更多的场景要注意服务的访问时间,也就是超时的问题.

我们在product服务中设置睡眠2s.这样虽然order服务能访问到product服务,但因为等待时间过长,所以还是触发了服务降级.

public List<ProductInfoOutput> listForOrder(@RequestBody List<String> productList){
            log.info("商品查询服务开始");
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e){
                e.printStackTrace();
            }
            return productService.findList(productList);
        }

我们可以配置超时时间,来避免这种情况.这样即使是2s也可以访问.

@RestController
    @DefaultProperties(defaultFallback = "defaultFallback")
    public class HystrixController {
    
        @HystrixCommand(commandProperties = {
                @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value="3000")
        })
        @GetMapping("/getProductInfoList")
        public String getProductInfoList(){
            RestTemplate restTemplate = new RestTemplate();
            return  restTemplate.postForObject("http://127.0.0.1:8082/product/listForOrder",
                    Arrays.asList("157875196366160022"),
                    String.class);
        }
        private String defaultFallback(){
            return "默认提示:太拥挤了,请稍后再试~~";
        }
    }

看一下时间,2.6s成功.

![20190702111410456.png][]

# 第四章 探讨断路器模式 #

Hystrix的依赖隔离类似于docker仓闭模式,docker通过仓闭模式实现进程隔离,使得容器之间互不影响,而Hystrix使用仓闭模式实现的是线程池隔离,会为每个HystrixCommand创建一个独立的线程池,这样就算再某个HystrixCommand包装下的服务出现依赖过高的情况,也只是对该依赖的服务产生影响,并不会拖慢其它服务,使用了HystrixCommand来讲某个函数包装成Hystrix命令时,Hystrix就会自动为某个函数实现依赖隔离,所以依赖隔离,服务降级,在实现的时候都是一体化实现的,这样利用Hystrix来实现服务容错保护在编程模型上就很容易实现了.

除了依赖隔离,服务降级之外,Hystrix还有一个重要元素,服务熔断,

@RestController
    @DefaultProperties(defaultFallback = "defaultFallback")
    public class HystrixController {
    
        @HystrixCommand(commandProperties = {
                @HystrixProperty(name = "circuitBreaker.enabled",value = "true"),//开启熔断
                @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "true"),
                @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "true"),
                @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "true"),
        })
        @GetMapping("/getProductInfoList")
        public String getProductInfoList(@RequestParam("number")Integer number){
            RestTemplate restTemplate = new RestTemplate();
            if(number%2==0) return "success";
            return  restTemplate.postForObject("http://127.0.0.1:8082/product/listForOrder",
                    Arrays.asList("157875196366160022"),
                    String.class);
        }
        private String defaultFallback(){
            return "默认提示:太拥挤了,请稍后再试~~";
        }
    }

分别请求如下两个地址:

[http://localhost:8081/getProductInfoList?number=1][http_localhost_8081_getProductInfoList_number_1]

[http://localhost:8081/getProductInfoList?number=2][http_localhost_8081_getProductInfoList_number_2]

我们访问1,会显示稍后再试,访问2会显示success,但是如果访问1访问多了,访问2也会显示稍后再试,而不是显示success.然后隔一会儿再访问2就好了.

![20190702121211988.png][]

Circuit Breaker:断路器,断路器的作用是及时切断故障电路.

放到Hystrix中也是类似的,当某个服务单元发生故障,类似服务单元发生短路后,通过断路器的故障监控,直接切断原来的主逻辑调用,

微服务和分布式中,容错是必须要考虑的,通常的做法有两种,一种是重试机制,对于预期的短暂的故障问题,使用重试是可以解决的.

对于更长时间解决的故障问题,这时候可以使用断路器模式,断路器模式是将受保护的服务封装到一个可以监控故障的断路器对象中,当故障达到一定的值,断路器将会跳闸.断路器对象返回错误.

断路器的状态机有撒种状态,Closed是熔断器的关闭状态,调用失败次数累计到了一定的阈值,或者到了一定的比例,就会启用熔断机制,此时熔断器处于打开状态,对服务都返回错误,但涉及到一个时钟选项,默认的时钟到了这个时间后就会进入半熔断状态,也就是halfOpen,允许定量的服务请求,如果调用都成功,或者一定的比例成功,则认为恢复了.就会关闭熔断器.否则会认为还没好,又回到熔断器打开状态.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70][]

下面三个就是控制熔断器的关键参数,刚才说涉及到一个时钟选项,默认时钟到了一定时间,进入半熔断状态.

![20190702123615585.png][]

sleepWindowInMilliseconds:

很多地方翻译成时间窗口,断路器确定是否需要打开统计一些请求和时间窗口和错误数据的时候呢,是有一个时间范围的,这个时间范围就被称之为时间窗口,当断路器打开对主逻辑进行熔断之后,Hystrix会启动一个休眠时间窗,在这个时间窗内,降级逻辑是临时的成为主逻辑,当休眠时间窗到期,断路器将进入半开状态,释放一次请求到原来的主逻辑上,如果此次请求正常返回,那么断路器会继续闭合,主逻辑恢复.如果这次请求依然有问题,断路器将继续进入打开状态.休眠时间窗重新计时.

我们在这里设置的是10000毫秒,也就是10s,这个时间窗结束后会将断路器设置为halfopen,尝试熔断请求命令.如果依然失败,就将断路器设置为打开状态,如果成功就设置为关闭状态.

requestVolumeThreshold:

设置在滚动时间窗口中,断路器的最小请求数.我们这里设置的是10

errorThresholdPercentage:

设置断路器打开地错误百分比条件,这里设置的是60,表示在滚动时间窗口中,发生了10次调用,如果7次发生异常,70%超过60%,这是断路器将会被设置为打开状态.

## 4.1 使用配置项 ##

上面配置的内容可以将其写在配置文件中.

@HystrixCommand
        @GetMapping("/getProductInfoList")
        public String getProductInfoList(@RequestParam("number")Integer number){
            RestTemplate restTemplate = new RestTemplate();
            if(number%2==0) return "success";
            return  restTemplate.postForObject("http://127.0.0.1:8082/product/listForOrder",
                    Arrays.asList("157875196366160022"),
                    String.class);
        }
        private String defaultFallback(){
            return "默认提示:太拥挤了,请稍后再试~~";
        }

application.properties

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=1000

上面配置的是所有的,如果为一个方法配置默认时间呢?假如是getProductInfoList方法,如下配置即可.

hystrix.command.getProductInfoList.execution.isolation.thread.timeoutInMilliseconds=3000

## 4.2 feign-hystrix的使用 ##

之前用的是restTemplate,现在改用feign.

**因为feign已经集成好了hystrix,所以我们这里不用引入hystrix包.**

在application.properties中开启对feign对hystrix的使用.

feign.hystrix.enabled=true

修改product服务中的Feign如下,表示如果请求istForOrder失败便会调用ProductClientFallback 中的listForOrder方法.然后重新mvn install来让order服务引用.

@FeignClient(name = "product",fallback = ProductClient.ProductClientFallback.class)
    public interface ProductClient {
        /*获取商品列表(给订单服务用的)*/
        @PostMapping("/product/listForOrder")
        public List<ProductInfoOutput> listForOrder(@RequestBody List<String> productList);
    
        @PostMapping("/product/decreaseStock")
        public void decreaseStock(@RequestBody List<DecreaseStockInput> decreaseStockInputList);
    
        @Component
        static class ProductClientFallback implements  ProductClient{
    
            @Override
            public List<ProductInfoOutput> listForOrder(List<String> productList) {
                return null;
            }
    
            @Override
            public void decreaseStock(List<DecreaseStockInput> decreaseStockInputList) {
    
            }
        }
    }

## 4.3 hystrix -dashboard ##

SpringCloud还提供了对熔断进行可视化的组件.

引入依赖:

<dependency>
         <groupId>org.springframework.cloud</groupId>
         <artifactId>spring-cloud-netflix-hystrix-dashboard</artifactId>
    </dependency>

添加@EnableHystrixDashboard与映射代码

@EnableFeignClients(basePackages = "com.imooc.product.client")
    @SpringCloudApplication
    @ComponentScan(basePackages = "com.imooc")
    @EnableHystrixDashboard
    public class OrderApplication {
    	public static void main(String[] args) {
    		SpringApplication.run(OrderApplication.class, args);
    	}
    
    	@Bean
    	public ServletRegistrationBean hystrixMetricsStreamServlet() {
    		ServletRegistrationBean registration = new ServletRegistrationBean(new HystrixMetricsStreamServlet());
    		registration.addUrlMappings("/actuator/hystrix.stream");
    		return registration;
    	}
    }

访问以下网址

[http://localhost:8081/hystrix][http_localhost_8081_hystrix]

在输入框中输入我们order服务的地址

[http://localhost:8081/actuator/hystrix.stream][http_localhost_8081_actuator_hystrix.stream]

去访问下面的两个地址,就会出现下面的结果(一开始是loading,访问之后会有图)

[http://localhost:8081/getProductInfoList?number=1][http_localhost_8081_getProductInfoList_number_1]

[http://localhost:8081/getProductInfoList?number=][http_localhost_8081_getProductInfoList_number_1]2

当错误率较高时绿色的Closed会变成open.

不同颜色的数字代表的意义在界面右上方有对应的字母.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 1][]

## 4.4 Zuul超时配置 ##

当我们通过Zuul访问页面时,第一次访问往往会超时,因为第一次访问有一个懒加载的过程.即有一些类是用到的时候再加载而不是启动的时候就加载,而默认的时间又比较短就容易超时.

查看依赖关系,可以看到Zuul完全依赖了hystrix.所以我们可以将hystrix的配置应用到Zuul中.(现版本已更改,不用看)

![20190702192332146.png][]

设置Zuul中的服务的访问接口为5S.

ribbon.ReadTimeout=5000

# 第五章 服务追踪 #

当我们使用某个服务A时,发现A耗时很严重,于是我们查看代码,发现A调用了B服务,B耗时很严重,于是去看B服务,B服务又调用C,C又耗时很严重,我们....

![20190705171406948.png][]

当服务的调用越来越多,链路越来越长的时候,我们再通过打点计时的方式去排查问题,效率就比较低.那我们该如何去做呢?

我们要做的事情其实有一个专有名词,叫做链路监控.SpringCloud提供了Spring Cloud Sleuth来做这件事情.

## 5.1 Sleuth ##

引入依赖

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

运行创建订单请求:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 2][]

打印出来的语句如下,可以看到多了一些字符串.分析以下这些字符串.

第一个值是服务的名字,第二个值叫做traceId.一条链路中最多包含一个traceId.也就是说transId就是一条链路的随机标识.第三个值叫做spanId,是一个基本单元,一条链路请求中可以包含多个spanId,spanId可以理解成一个基本的工作单元.比如发送一个http请求,最后一个值可以看到是false,true表示的是要把这个信息输出到其它服务来收集和展示,false就是不收集.

![20190705173854246.png][]

再次访问,发现没有了上面的多出来的字符串.调整日志的级别,可以让它每次都打印出日志且看到更过内容.

因为我们这里这里使用了feign,所以我们调整feign的日志级别.

List<ProductInfoOutput> productInfoList = productClient.listForOrder(productIdList);

logging.level.org.springframework.cloud.netflix.feign=debug

重新下单,发现又重新打印出了上面的内容.

我们刚才是在order服务中提升了日志级别,我们这个请求时调用商品服务的,商品内容中也应该有对应的traceId,我们给商品服务页加上Sleuth组件,且调整日志级别.

再次下单,发现order与product中的traceid是一样的,表明它们是同一个链路,spanId是不一样的.

order:

![2019070518253659.png][]

product:

![20190705182611237.png][]

现在监控的指标已经产生,接下去我们要去看.

## 5.2 Zipkin ##

我们用到的是Zipkin框架.输入如下安装并运行Zipkin框架.

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

访问 [http://192.168.99.100:9411/zipkin/][http_192.168.99.100_9411_zipkin]即可到对应管理界面.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 3][]

这只是一个展示界面,如何将其与数据连接呢?

在order服务中引入依赖

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

在application.properties中进行配置.

第一个配置了zipikin地址.

第二个将上面提到的false改为true,并且标识将记录每一个请求(默认是0.1即只记录十分之一个请求)

如果项目里引用了RabbitMQ依赖，会把数据发送到mq， 不会通过http方式发到zipkin服务端了,配置第三个让项目把数据发送到zipkin.

spring.zipkin.base-url=http://192.168.99.100:9411/
    
    spring.sleuth.sampler.probability=1
    
    spring.zipkin.sender.type=web

进行下单,可以看到有了对应的请求时间.

一共花费了2.045s.

创建订单用了706ms,查看商品用了16.6ms,扣库存用了22.5ms,product向order发送消息用了1us,order接收rabbitMQ消息并写入redis用了1.4s.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 4][]

点进去可以看到更详细的信息.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 5][]

## 5.3 分布式追踪系统 ##

核心步骤:数据采集,数据存储,查询展示

在数据采集过程中由于不同系统的api并不兼容,这就导致如果希望切换追踪系统,会带来较大改动,因此诞生了opentracing 规范,以解决不同分布式追踪系统api不兼容的问题.

OpenTracing的优势:提供平台无关,厂商无关的api,使得开发人员能够方便添加或者更换追踪系统的实现,OpenTracing正在为全球的分布式追踪提供统一的概念和数据标准.

OpenTracing来自CNCF,即云原生容器基金会,kubernetes就是其的一个产品,随着OpenTracing进入CNCF,这个标准越来越受到开源和商业团队的追捧,比如ZIPKIN,TRACER,JAEGER,GRPC等等都跟进OpenTracing,OpenTracing的数据模型中重要的概念trace也就是调用链是通过归属此调用链的span来定义,span和trace其实都来自于谷歌的一个开源项目叫做dapper的专业术语,还有一个经常涉及的专业术语叫做annotation.

annotation是用来即时记录一个事件的,一些核心注解用来定义一个请求的开始和结束,可以理解成span生命周期中重要时刻的数据快照,比如一般包括发生时刻,事件类型等信息.

事件类型有四种:

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 6][]

客户端调用时间=cr-cs

服务端处理时间 =ss-sr

ZipKin是跟进opentracing规范的,它的起源来自于谷歌2010年谷歌发表的一篇关于其内部使用分布式追踪系统叫做dapper,该论文讲述了dapper在谷歌内部演变,设计,和运维经验,Twitter根据该论文开发出了自己的分布式跟踪系统ZipKin并且将其开源.

下图是从官网搞过来的,体现了ZipKin的架构.

右边绿色的是ZipKin的四大核心组件.

Collector是收集组件,用于处理从外部系统发过来的跟踪信息,将这些信息转化为ZipKin内部处理的Span格式,以支持后续的储存,分析,展示等功能.

Storage是储存,默认是储存在内存中,放在内存中会随着服务端的启动会清空历史数据,如果想持久化保存这些数据,可以修改保存策略,可以存在Mysql中等.

API组件是用来提供给外部访问的restful接口,比如给客户端展示跟踪信息,或者外界系统访问以实现监控.

UI组件是基于API组件实现的上层应用,通过UI组件能方便和直观的查询分析跟踪信息.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 7][]

通过ZipKin可以查看某个请求的详细调用链,也可以查看服务之间的依赖关系.

微服务之间可能存在循环引用形成一个网状关系,当项目规模越来越大之后,微服务之间的依赖关系估计谁也理不清,这样从请求链中就能比较直观的查到请求关系.

ZipKin几个关键概念:

traceId:就是一个全局的跟踪Id,是跟踪的入口点,根据需求来决定在哪生成traceId,比如一个常见的Http请求,入口是web应用,一般看完整的调用链,这里是自然是traceId生成的起点,结束点在web请求返回点.

spanId这是下一层的请求跟踪Id,这个根据自己的需求了,一个traceId包含一个以上的spanId.

parentId是上一次请求跟踪Id,用来将前后请求串联起来.

[https_github.com_springcloud-demo]: https://github.com/springcloud-demo
[20190702111410456.png]: /images/20211219/2cf8b6cb4ebc438ab8c52851d14540c0.png
[http_localhost_8081_getProductInfoList_number_1]: http://localhost:8081/getProductInfoList?number=1
[http_localhost_8081_getProductInfoList_number_2]: http://localhost:8081/getProductInfoList?number=2
[20190702121211988.png]: /images/20211219/aab137b3128d4e61bfc1bb2235e36723.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70]: /images/20211219/d3063354e9ed4ccc8e1b8d065af7b239.png
[20190702123615585.png]: /images/20211219/0cd35764d2a64489bde6a461dd15723b.png
[http_localhost_8081_hystrix]: http://localhost:8081/hystrix
[http_localhost_8081_actuator_hystrix.stream]: http://localhost:8081/actuator/hystrix.stream
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 1]: /images/20211219/c81506cec654496481a5aebeacd34bda.png
[20190702192332146.png]: /images/20211219/f3ec7bc01a9643e6ad22c74c989342c4.png
[20190705171406948.png]: /images/20211219/65ce706c1a3c459f8ee26a5e0d2bebdc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 2]: /images/20211219/7bea06651c304ad5ae233c5b9bd7eac5.png
[20190705173854246.png]: /images/20211219/20d1f33106ac4ab8959b123f216d0743.png
[2019070518253659.png]: /images/20211219/8cfa0f78b823429f8ec47e92b28a1560.png
[20190705182611237.png]: /images/20211219/aabeb4d3504146919f2899fa87b9492d.png
[http_192.168.99.100_9411_zipkin]: http://192.168.99.100:9411/zipkin/
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 3]: /images/20211219/ae2d46c701b44070b301e924a6c56d8b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 4]: /images/20211219/0a1b06f0bca64a6b8f0675044b2f8e30.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 5]: /images/20211219/b34d61e0ca544272b3948f9bda98a3a2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 6]: /images/20211219/2e20c64f2c69497186c1065de9133bcd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3E2MTAzNzY2ODE_size_16_color_FFFFFF_t_70 7]: /images/20211219/80297d2f8f144034aec40a8974d98d9c.png