Spring Cloud 入门培训课程之运维

SpringCloud入门-运维技术能力中心尹毅03-284.服务链路追踪和分析（Sleuth和zipkin）5.SpringBootAdmin的使用2.Hystrix监控的搭建和使用3.分布式配置中心ConfigServer的搭建和使用1.微服务开发中的运维

3微服务开发中的运维/4微服务开发中的运维微服务的分布式部署给运维带来很大的难度和挑战，一般有如下问题：问题查找难（服务之间调用的问题）分散的数据管理难（日志数据、配置文件等）......应对上述问题的对策：跟踪与监控聚合数据、统一管理......

5Hystrix监控的搭建和使用/6

创建Hystrix监控创建一个SpringBoot工程（项目名demo.service.monitor），选择模块Hystrix、HystrixDashboard、Turbine用@EnableDiscoveryClient、@EnableHystrixDashboard、@EnableTurbine注解应用主类在perties配置文件中增加如下信息：

=service-monitor

server.port=5001eureka.client.serviceUrl.defaultZone=http://peer1:1001/eureka/turbine.app-config=service-consumerturbine.cluster-name-expression="default"bine-host-port=true启动工程后，访问http://localhost:5001/hystrix/7Hystrix监控架构和配置参数说明部分配置参数说明：

turbine.app-config参数指定了需要收集监控信息的服务名；turbine.cluster-name-expression参数指定了集群名称为default，当我们服务数量非常多的时候，可以启动多个Turbine服务来构建不同的聚合集群，而该参数可以用来区分这些不同的聚合集群，同时该参数值可以在Hystrix仪表盘中用来定位不同的聚合集群，只需要在HystrixStream的URL中通过cluster参数来指定；bine-host-port参数设置为true，可以让同一主机上的服务通过主机名与端口号的组合来进行区分，默认情况下会以host来区分不同的服务，这会使得在本地调试的时候，本机上的不同服务聚合成一个服务来统计。/8Hystrix监控的使用Hystrix共支持三种不同的监控方式：默认的集群监控：通过http://turbine-hostname:port/turbine.stream开启指定的集群监控：通过http://turbine-hostname:port/turbine.stream?cluster=[clusterName]开启单体应用的监控：通过http://hystrix-app:port/hystrix.stream开启/9Hystrix监控的使用监控页面上主要元素的具体含义：实心圆：它通过颜色的变化代表了实例的健康程度，它的健康度从绿色、黄色、橙色、红色递减。该实心圆的大小也会根据实例的请求流量发生变化，流量越大该实心圆就越大曲线：用来记录2分钟内流量的相对变化，我们可以通过它来观察到流量的上升和下降趋势其他一些数量指标如图所示

10分布式配置中心ConfigServer的搭建和使用/11

SpringCloudConfig简介SpringCloudConfig是SpringCloud团队创建的一个全新项目，用来为分布式系统中的微服务应用提供集中化的外部配置支持，它分为服务端与客户端两个部分：服务端称为分布式配置中心，它是一个独立的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密/解密信息等访问接口客户端则是微服务架构中的各个微服务应用，它们通过指定的配置中心来管理应用的配置信息，并在启动的时候从配置中心获取和加载配置信息配置中心默认采用Git来存储配置信息，所以使用SpringCloudConfig构建的配置服务器，天然就支持对微服务应用配置信息的版本管理可以通过Git客户端工具来方便的管理和访问配置内容。它也提供了对其他存储方式的支持，比如：SVN仓库、本地化文件系统/12

SpringCloudConfig架构和高可用配置客户端不是采用SpringCloud技术的，需要为ConfigServer集群搭建服务端负载均衡器（比如：Nginx）配置客户端是采用SpringCloud技术的，可以利用Ribbon提供的客户端负载均衡对ConfigServer进行访问，不需要另外搭建服务端负载均衡器/13

高可用服务配置中心ConfigServer的搭建创建一个SpringBoot工程（项目名demo.config.server），选择模块Config

Server、EurekaDiscovery用@EnableConfigServer和@EnableEurekaClient注解应用主类在perties配置文件中增加如下信息，配置文件存储在本地文件：

=config-serverserver.port=6001eureka.client.serviceUrl.defaultZone=http://peer1:1001/eureka/files.active=native

#spring.cloud.config.server.native.search-locations=D:/LocalConfigProperties

在\src\main\resources目录，增加service-consumer.properties文件：

config.demo=helloworld!/14

配置信息的加密提供了对属性进行加密解密的功能，以保护配置文件中的信息安全：在属性值前使用{cipher}前缀来标注该内容是一个加密值，当微服务客户端来加载配置时，配置中心会自动的为带有{cipher}前缀的值进行解密配置中心的JRE环境需要安装不限长度的JCE版本（UnlimitedStrengthJavaCryptographyExtension）。虽然，JCE功能在JRE中自带，但是默认使用的是有长度限制的版本。可以从Oracle的官方网站中下载（搜索：JCEJDK版本号），将local_policy.jar和US_export_policy.jar两个文件复制到$JAVA_HOME/jre/lib/security目录下，覆盖原来的默认内容。/encrypt/status：查看加密功能状态的端点/encrypt：对POST请求的body内容进行加密的端点/decrypt：对POST请求的body内容进行解密的端点通过encrypt.key属性在配置文件perties中直接指定密钥信息（对称性密钥）配置中心不仅可以使用对称性加密，也可以使用非对称性加密（比如：RSA密钥对），用%JAVA_HOME%\bin\keytool.exe生成秘钥，配置文件中用encrypt.key-store开头的属性进行配置。/15

配置信息的热刷新增加一些内容和操作以实现配置的热刷新：demo.service.consumer项目的pom.xml中新增spring-cloud-starter-config和spring-boot-starter-actuator依赖，其中actuator包含了/refresh刷新API <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-actuator</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency>重新启动demo.service.consumer修改configserver的配置文件，检查http://localhost:3001/testconfig，并没有更新通过POST请求发送到http://localhost:3001/refresh，再检查http://localhost:3001/testconfig，可以发现已经刷新上述方法只能刷新指定服务实例的配置，无法同步刷新多个实例/16

配置信息的同时刷新机制消息总线123333刷新三阶段：给ConfigServer发刷新POST/bus/refreshConfigServer给消息总线发配置变更消息各配置客户端接收消息总线的配置刷新消息123/17

配置信息的同时热刷新环境准备：安装kafka，/downloads下载，解压缩，cd到bin\windows目录，运行zookeeper-server-start../../config/perties启动Zookeeper服务，运行kafka-server-start../../config/perties启动kafka服务在demo.config.centre的pom.xml中新增spring-boot-starter-actuator依赖： <dependency> <groupId>org.springframework.boot</groupId><artifactId>spring-boot-actuator</artifactId> </dependency>在demo.config.centre和demo.service.consumer项目的pom.xml中新增如下依赖： <dependency> <groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-bus-kafka</artifactId> </dependency>启动各服务，修改configserver的配置文件，检查http://localhost:3001/testconfig，并没有更新通过POST请求发送到http://localhost:6001/bus/refresh，再检查http://localhost:3001/testconfig和http://localhost:3002/testconfig，可以发现都已经刷新

18服务链路追踪和分析（Sleuth和zipkin）/19

分布式服务跟踪原理主要包括下面两个关键点：为了实现请求跟踪，当请求发送到分布式系统的入口端点时，只需要服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在分布式系统内部流转的时候，框架始终保持传递该唯一标识，直到返回给请求方为止，这个唯一标识就是前文中提到的TraceID。通过TraceID的记录，我们就能将所有请求过程日志关联起来。为了统计各处理单元的时间延迟，当请求达到各个服务组件时，或是处理逻辑到达某个状态时，也通过一个唯一标识来标记它的开始、具体过程以及结束，该标识就是我们前文中提到的SpanID，对于每个Span来说，它必须有开始和结束两个节点，通过记录开始Span和结束Span的时间戳，就能统计出该Span的时间延迟，除了时间戳记录之外，它还可以包含一些其他元数据，比如：事件名称、请求信息等。Sleuth会在该请求的Header中增加实现跟踪需要的重要信息，主要有：X-B3-TraceId：一条请求链路（Trace）的唯一标识，必须值X-B3-SpanId：一个工作单元（Span）的唯一标识，必须值X-B3-ParentSpanId:：标识当前工作单元所属的上一个工作单元，RootSpan（请求链路的第一个工作单元）的该值为空X-B3-Sampled：是否被抽样输出的标志，1表示需要被输出，0表示不需要被输出X-Span-Name：工作单元的名称/20

被跟踪端代码修改和演示在vider和demo.service.consumer项目的pom.xml中新增依赖： <dependency> <groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-sleuth</artifactId> </dependency>demo.service.consumer项目的控制台打印信息：

INFO[service-consumer,38300205dbc9eb9c,38300205dbc9eb9c,false]demo.service.provider项目的控制台打印信息：

INFO[service-provider,38300205dbc9eb9c,571497adfcc07831,false]上述日志信息中的这些元素正是实现分布式服务跟踪的重要组成部分，每个值的含义如下（以demo.service.provider的为例）：第一个值：service-provider，它记录了应用的名称，也就是perties中参数配置的属性。第二个值：38300205dbc9eb9c，Sleuth生成的一个ID，称为TraceID，它用来标识一条请求链路。一条请求链路中包含一个TraceID，多个SpanID。第三个值：571497adfcc07831，Sleuth生成的另外一个ID，称为SpanID，它表示一个基本的工作单元，比如：发送一个HTTP请求。第四个值：false，表示是否要将该信息输出到Zipkin等服务中来收集和展示。/21

收集请求链路的跟踪数据并分析：ZipkinZipkin是Twitter的一个开源项目，它参考GoogleDapper项目实现。可以使用它来收集各个服务器上请求链路的跟踪数据，它也提供了方便的UI组件来帮助我们直观的搜索跟踪信息和分析请求链路明细。Zipkin支持按HTTP和消息中间件来收集数据，但因为前面为了实现配置同步刷新已经引入了消息中间件，所以只能选消息中间件来收集。在demo.service.consumer和demo.service.provider的pom.xml中引入spring-cloud-sleuth-zipkin依赖。创建一个SpringBoot工程（项目名demo.zipkin.server），在POM文件中增加如下依赖：<dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin-autoconfigure-ui</artifactId></dependency><dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin-server</artifactId></dependency><dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin-autoconfigure-collector-kafka10</artifactId> <version>2.8.4</version></dependency>用@EnableZipkinServer注解应用主类，在demo.zipkin.server的配置文件中增加如下信息：

server.port=7001zipkin.collector.kafka.bootstrap-servers=:9092

将相关服务都启动起来，并访问http://localhost:7001/22服务跟踪的抽样收集分析系统在收集跟踪信息的时候，需要收集多少量的跟踪信息才合适呢？理论上来说，我们收集的跟踪信息越多就可以更好的反映出系统的实际运行情况，并给出更精准的预警和分析但是在高并发的分布式系统运行时，大量的请求调用会产生海量的跟踪日志信息，如果收集过多的跟踪信息将会对我们整个分布式系统的性能造成一定的影响Sleuth中采用了抽样收集的方式来为跟踪信息打上收集标记，也就是之前在日志信息中看到的第四个boolean类型的值，它代表了该信息是否要被后续的跟踪信息收集器获取和存储在Sleuth中的抽样收集策略是通过Sampler接口实现的，它的定义如下（要定制自己的抽样收集策略，需要实现该接口）：publicinterfaceSampler{booleanisSampled(Spanspan);}默认情况下，Sleuth会使用PercentageBasedSampler实现的抽样策略，以请求百分比的方式配置和收集跟踪信息，可在perties中配置下面的参数对其百分比值进行设置，它的默认值为0.1，代表收集10%的请求跟踪信息：

spring.sleuth.sampler.percentage=1

23SpringBootAdmin的使用/24

SpringBootAdmin简介SpringBootAdmin是一个用来管理和监控SpringBoot应用的项目，这些应用可以是通过管理客户端（SpringBootAdminClient）用HTTP进行注册的应用，或者是通过SpringCloud的服务注册机制注册的应用。/25SpringBootAdmin的使用创建一个SpringBoot工程（项目名demo.