服务治理：服务熔断与监控

微服务治理
1、微服务的依赖层级：依赖关系，解决单个微服务集群的性能瓶颈。
2、微服务的重要级别：进行熔断处理，防止整个服务雪崩。

项目中微服务如何修改？
针对每个微服务进行监控
1,添加依赖

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-hystrix</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

2,添加配置(Hystrix的配置)

feign.hystrix.enabled=true
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=300000
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds=300000

3,添加注解启用功能

@EnableFeignClients
@EnableHystrix

聚合监控微服务Turbine
如何对整个项目中的微服务进行监控？
Netflix提供了一个开源项目（Turbine）来提供把多个hystrix.stream的内容聚合为一个数据源供Dashboard展示。
把监控结果展示在一张页面上。
断路器聚合监控(Hystrix Turbine)：聚合所有服务的Hystrix Dashboard的数据。
监控分类：单点监控，集群监控，聚合监控。

创建hystrix turbine微服务(单独起一ge微服务做监控端)。
添加依赖：

    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-turbine</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-turbine</artifactId>
        </dependency>
    </dependencies>

常用配置
1)turbine.appConfig=ZIPKIN-USER-8000,ZIPKIN-USER-8001,ZIPKIN-USER-8002
监控的微服务名称，配置在Eureka中的serviceId列表，表明监控哪些微服务。
2)turbine.aggregator.clusterConfig=default
指定聚合哪些集群，多个使用”,”分割，默认为default。
3)可以针对某一个微服务集群，进行监控，需要使用eureka的配置项。

turbine.appConfig=ZIPKIN-USER-8000,ZIPKIN-USER-8001,ZIPKIN-USER-8002
turbine.aggregator.clusterConfig= default
turbine.clusterNameExpression= new String("default")

启动类添加@EnableTurbine，激活对Turbine的支持。
@EnableHystrixDashboard
@EnableTurbine

单点监控
针对微服务端口进行监控
监控某一个微服务结点对其他微服务的调用；只能监控当前微服务的端口。针对微服务所在的端口进行监控。
当前微服务没有通过feign对其他微服务进行调用，所以监控不到。
案例：实现8001调用8002，通过feign调用
http://localhost:9000/hystrix
http://localhost:8000/hystrix.stream
http://localhost:8001/hystrix.stream

开始监控目标服务
点击“Monitor Stream”按钮，在3个输入框输入无误后，开始“监控”目标服务。
点击“Monitor Stream”按钮后，会出现几种情况：
1、正常，但暂未执行过hystrix命令，会出现两个Loading…
2、正常，随便调用一个被hystrix管理的远程调用接口后，页面会刷新出类似如下的页面(理想状态，调用接口后出现)。
为什么8001监控不到？没有数据，只有先调用通，才会有数据。
3、异常，目标服务没有引入spring-boot-starter-actuator启动依赖。

如何查看hystrixdashboard？
1、实心圆共有两种含义：颜色(故障实例)，大小(高压实例)
1)它通过颜色的变化代表了实例的健康程度，它的健康度颜色从绿色<黄色<橙色<红色递减。
2)它的大小也会根据实例的请求流量发生变化，流量越大该实心圆就越大。所以通过该实心圆的展示可以在大量的实例中快速的发现故障实例和高压力实例。
2、曲线：用来记录2分钟内流量的相对变化，可以通过它来观察流量的上升和下降趋势。
3、7种颜色的数据
Success | Short-Circuited | Bad Request |Timeout | Rejected | Failure | Error
成功数，熔断数，错误请求数，连接超时数，连接池拒绝数，失败异常数，最近10s错误比例。
集群主机报告状态：服务请求频率，断路状态

服务熔断与服务降级的区别
1、触发原因不太一样：服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
2、管理目标的层次不太一样：熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）。
服务降级要考虑的问题：1.核心和非核心服务。2.是否支持降级，降级策略

1、服务降级：服务压力剧增的时候根据当前的业务情况及流量对一些服务和页面有策略的降级，以此环节服务器的压力，以保证核心任务的进行。同时保证部分甚至大部分任务客户能得到正确的相应。也就是当前的请求处理不了了或者出错了，给一个默认的返回(环节服务器压力)。
2、服务熔断：在股票市场，熔断这个词大家都不陌生，是指当股指波幅达到某个点后，交易所为控制风险采取的暂停交易措施。相应的，服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护(防止整个系统雪崩)。

针对Zuul的理解
Zuul本身就集成了Hystrix，实际上Zuul的路由转发也是用到了Ribbon+Hystrix，也就意味着我们可以通过Hystrix Dashboard监控Zuul的工作情况。

服务熔断的作用：防止服务雪崩和级联故障

当服务的某个API接口的失败次数在一定时间内小于设定的阀值时,熔断器处于关闭状态,该API接口正常提供服务.当API接口处理请求的失败次数大于设定的阀值时,Hystrix判定该API接口出现故障,打开熔断器,这时请求该API接口会执行快速失败逻辑(即fallback回退逻辑)。

circuitBreaker.sleepWindowInMilliseconds //过多长时间，熔断器再次检测是否开启，默认为5000，即5s钟
circuitBreaker.errorThresholdPercentage //错误率，默认50%。

Hystrix隔离机制：信号量隔离与线程池隔离
Hystrix对依赖服务实现线程池隔离，每个微服务的调用都会分配一个线程池，这样就算某个Hystrix命令包装下的依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的服务。

Hystrix限流机制：服务限流
在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹；而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），因此需有一种手段来限制这些场景的并发/请求量，即限流。
限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。
一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如nginx的limit_conn模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）；其他还有如限制远程接口调用速率、限制MQ的消费速率。另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。
线程池方式限流：通过线程池+队列的方式；通过信号量的方式（底层是并发包）。比如商品评论比较慢，最大能同时处理10个线程，队列待处理5个，那么如果同时20个线程到达的话，其中就有5个线程被限流了，其中10个先被执行，另外5个在队列中。从执行结果中，我们可以明显看出一共打印出了 7 个降级商品。这也就是请求数超过线程池+队列的数量而直接被 reject 的结果。

针对某个feign接口关闭熔断功能，是可以实现的，文档里面有。
是不是每个新建的微服务都要走网关路由和Nginx？按道理来说每个微服务的请求都要走nginx与zuul。
Dashboard上标题显示的是什么意思？具体哪个微服务的那个接口。
1、微服务在eureka上实例名称的显示规则：微服务名称，ip地址，端口号。一定要显示ip地址。
2、关于对集群的监控：不需要进行修改配置，默认就好。
3、feign.hystrix.enabled: true 在调用者这一端进行配置。
4、eureka：微服务的名称，微服务实例的别名。
5、微服务通过zuul访问，直接报错，没有进行熔断怎么处理？ 原来在zuul中还要配置一些连接超时时间。针对zuul的理解。
6、注册中心的地址：已经拿到，上面有所有的微服务的名称；监控其实是对微服务实例名称的监控。

Feign内集成了robbin依赖，如果存在多个微服务实例，就会通过轮询算法进行处理；所以当自己本地启的微服务注册到Eureka Server上；Eureka Server存在多个实例，就会进行请求转发到其中的实例。

微服务监控：
1）单个点监控，目标微服务的ip地址和端口号
2）整个项目监控，当前监控微服务的ip地址和端口号。

微服务监控原理：被监控的微服务和监控微服务必须注册到同一个Eureka Server上。
Spring Cloud Hystrix Dashboard只是spring cloud基于Hystrix Dashboard，将实时监控数据通过页面呈现出来。Spring Cloud Hystrix Dashboard的底层原理是间隔一定时间去“Ping”目标服务，返回的结果是最新的监控数据，最后将数据显示出来。

3个输入框。作用如下：目标服务暴露的hystrix.stream端口；“Ping”的间隔时间；目标服务的别名，可以随便取；开始监控目标微服务。

turbine如何聚合设置了context-path的hystrix数据
http://blog.didispace.com/spring-cloud-tips-4/

如何通过最大并发数去设置线程池大小？
什么是确定的？平均每秒响应时间，200ms，每秒请求数。哪些变量是可控的？

jekins 微服务启动日志，重新启动一下看看。
log中看不到微服务的启动日志，可能是没有记录，只记录了报错级别的日志。

同步和异步：
同步：按照顺序串行化执行，前一个任务没有执行完，下一个任务就不会开启。
同步操作：调用接口，需要拿到结果。
异步操作：调用接口，不需要拿到结果。 是否需要等待执行结果？
执行一个接口是使用同步调用还是异步调用，可以自己设置。

实施流程：
1，熔断器发生作用？
2，单点监控如何实现？
3，集群监控如何现？
4，技术上的整理，如何实现这个功能，技术文档？
5，DEV环境跑一个微服务，专门用来做监控的。
6，针对每个微服务如何做监控？ 如何进行改造？
7，在DEV环境，测试熔断功能的实现？
8、尽可能操作简化，否则别人不买单。
9、是不是只能监控，通过hystrix调用的微服务？ 为什么8001不能监控得到？
10、zuul 不能访问访问就报连接异常。

上线策略：
1）项目原型中，添加对Hystrix的支持,添加依赖，开启注解，服务熔断回调。
2）新上线的服务，要添加对Hystrix的支持；旧的微服务，最近一次发布时，要添加对Hystrix的支持。
Hystrix熔断的具体实施
不强制要求，可以按照文档来接入。
接入流程：新上线的微服务自动开启Hystrix功能。

---

feign.hystrix.enabled=true 配置
客户端熔断，和feign依赖没关系，使用FeignClient的时候，需要添加对Hystrix的支持，设置fallBack回调。
在客户端开启熔断功能

hystrix的常用配置，以及什么意思？ 如何结合Feign使用?
spring-cloud-starter-eureka-server 添加这个依赖。
feign的调用分两层，ribbon的调用和hystrix的调用。不能保证服务的100%可用，所以要进行熔断机制。
feign.hystrix.enabled: true

不使用Feign时如何使用Hystrix？
#请求处理的超时时间
ribbon.ReadTimeout: 120000
#请求连接的超时时间
ribbon.ConnectTimeout: 30000

---

微服务监控流程
1）单独建立Hystrix Dashboard或者Hystrix Turbine监控微服务， 所有的数据都发送到这个微服务。
2）监控管理界面和被监控的微服务的地址(这两个是不一样的)。目标微服务的ip地址和端口号，监控地址是哪个？目标服务暴露的hystrix.stream端口。
3）被监控微服务应该添加的依赖和注解。
4）监控微服务应该添加的依赖和注解。
无论怎么监控，都需要依赖监控微服务。
服务治理：服务熔断与服务监控是不一样的；服务熔断和服务降级也存在很大的差别。
服务监控分类：单点监控，集群监控，聚合监控。
单个微服务结点怎么监控？
多个微服务结点怎么监控？ 微服务熔断已经可以了。

---

服务追踪：
服务追踪组件zipkin，Spring Cloud Sleuth集成了zipkin组件。
Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，
1）引入spring-cloud-starter-zipkin依赖。你只需要在pom文件中引入相应的依赖即可。
2）设置spring.zipkin.base-url就可以了。配置文件中设置
spring.zipkin.base-url=http://localhost:9411
服务追踪分析
微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。
服务之间存在调用关系，才叫服务追踪。

服务追踪组件zipkin，Spring Cloud Sleuth集成了zipkin组件。
Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。

微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。
1、多个微服务协同才能完成这个接口功能；
2、如果调用链路上任何一个服务出现问题，导致接口调用失败；
3、服务之间的相互调用关系越来越复杂。

ZipkinServer：收集调用数据，并展示。只有微服务之间存在调用关系，server-zipkin才会收集数据的，这就是为什么叫服务追踪了。
Zipkin Server：
不需要自己构建Zipkin Server，只需要下载jar即可。下载完成jar 包之后，需要运行jar，访问浏览器localhost:9494，注意查看端口号，可能不是9494. 启动日志里面有的。（查看zipkin是否跑起来了）
如何看Zipkin Server上的数据？

Zipkin Server管理界面：
1、这个界面主要用来查找服务的调用情况，可以根据服务名、开始时间、结束时间、请求消耗的时间等条件来查找。点击“Find Trackes”按钮，界面如图所示。从图可知服务的调用情况，比如服务调用时间、服务的消耗时间，服务调用的链路情况。
2、点击Dependences按钮，可以查看服务的依赖关系，在本案例中，gateway-service将请求转发到了user-service，它们的依赖关系如图。

Span：基本工作单元，发送一个远程调度任务 就会产生一个Span。
Trace：一系列Span组成的一个树状结构。请求一个微服务系统的API接口，这个API接口，需要调用多个微服务，调用每个微服务都会产生一个新的Span，所有由这个请求产生的Span组成了这个Trace。

如何启动zipkin-server？
如何查看管理界面？
1）启动日志上的端口号。
2）只有存在微服务相互调用，才会产生数据。两个微服务之间相互调用即可产生数据。
如何在项目中集成zipkin？
1）引入spring-cloud-starter-zipkin依赖
2）设置spring.zipkin.base-url即可。
3）开启zipkin功能 @EnableZipkinServer
如何把数据存储到数据库？

---