hystrix

Springcloud核心知识点（必备）： 1.1 什么是微服务? 微服务是一种架构风格,是以开发一组小型服务的方式来作为一个独立的应用系统,每个服务都运行在自已的进程中,服务之间采用轻量级的HTTP通信机制 1.2 微服务之间是如何独立通讯的？ RestFul Http协议是微服务架构中最常用的通讯机制。 通讯方式： 同步：RPC ,REST等。 异步：消息队列，要考虑消息的可靠传输、高性能，以及编程模型的变化等。 1.3 SpringCloud和Dubbo有哪些区别？ springcloud和dubbo的最大区别：springcloud抛弃了dubbo的rpc通信，采用的是基于http的rest方式。 1.4 SpringBoot和SpringCloud，请谈谈对他们的理解？ SpringCloud是Spring为微服务架构思想做的一个一站式实现。从某种程度是可以简单的理解为，微服务是一个概念、一个项目开发的架构思想。SpringCloud是微服务架构的一种java实现。 SpringCloud是基于SpringBoot的一套实现微服务的框架。它提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。最重要的是，跟SpringBoot框架一起使用的话，会让你开发微服务架构的云服务非常方便。

3 月，跳不动了？>>> Actuator 　　 　　Hystrix 除了可以实现服务容错之外，还提供了近乎实时的监控功能，将服务执行结果和运行指标，请求数量成功数量等等这些状态通过 Actuator 进行收集，然后访问 /actuator/hystrix.stream 即可看到实时的监控数据。 　　 添加依赖 　　 　　在需要开启数据监控的项目中添加 actuator 依赖。 <!-- spring boot actuator 依赖 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> 　　 配置文件 　　 　　在配置文件中开启 hystrix.stream 端点。如果希望所有端点暴露，配置为 '*' 。 # 度量指标监控与健康检查 management: endpoints: web: exposure: include: hystrix.stream 　　 启动类 　　 package com.example; import org.springframework.boot.SpringApplication; import org.springframework.boot

EnableEurekaClient与EnableDiscoveryClient的区别 选用的注册中心是eureka，那么就推荐@EnableEurekaClient，如果是其他的注册中心，那么推荐使用@EnableDiscoveryClient。这个和“Slf4j与Log4j”的道理一样，Log4j可以直接用，也可以通过Slf4j调用Log4j。@EnableDiscoveryClient是通用注解，适用范围更广。 异常：com.netflix.client.ClientException: Load balancer does not have available server for client 如果出现异常：com.netflix.client.ClientException: Load balancer does not have available server for client。 可以关闭wifi后重试，也可以尝试重启Client，或者是适当增加Feign的超时时间。 （一般是因为Maven依赖不够，导致的注册失败问题，如果和我的配置相同，那么，很可能是因为默认的超时时间过短） 最直接的办法就是写url ，这种做法不符合系统架构的设计，但是或许能成为以后解决问题的一种办法，这里也做个笔记。 @FeignClient(name = "client-a", url

3 月，跳不动了？>>> 　　 什么是 Hystrix 　　 　　Hystrix 源自 Netflix 团队于 2011 年开始研发。2012年 Hystrix 不断发展和成熟，Netflix 内部的许多团队都采用了它。如今，每天在 Netflix 上通过 Hystrix 执行数百亿个线程隔离和数千亿个信号量隔离的调用。极大地提高了系统的稳定性。 　　在分布式环境中，不可避免地会有许多服务依赖项中的某些服务失败而导致 雪崩效应 。Hystrix 是一个库，可通过添加等待时间容限和容错逻辑来帮助您控制这些分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体稳定性。 　　 雪崩效应 　　 　　在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问 A 服务，而 A 服务需要调用 B 服务，B 服务需要调用 C 服务，由于网络原因或者自身的原因，如果 B 服务或者 C 服务不能及时响应，A 服务将处于阻塞状态，直到 B 服务 C 服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。以下图示完美解释了什么是雪崩效应。 　　 　　当一切服务正常时

3 月，跳不动了？>>> 由于 hystrix 对流量的监控状态的监控是单应用的。有的时候我们需要全面查看整个系统的监控状态，那么我们可能需要引入turbine 的监控检查。在spring boot admin 已经有spring-boot-admin-server-ui-turbine 这个插件 turbine 是一个hystrix 的集合。里面展示所有的hystrix的效果。我们这里用的spring cloud的版本是 <spring-boot.version>1.5.3.RELEASE</spring-boot.version> <spring-cloud.version>Dalston.SR1</spring-cloud.version> <spring-boot-admin.version>1.5.0</spring-boot-admin.version> 1、配置turbine 的包依赖 <dependencies> <dependency> <groupId>de.codecentric</groupId> <artifactId>spring-boot-admin-server</artifactId> <version>${spring-boot-admin.version}</version> </dependency> <dependency>

我们从整体上来看一下Spring Cloud各个组件如何来配套使用： 从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。 其中Eureka负责服务的注册与发现，很好将各服务连接起来 Hystrix 负责监控服务之间的调用情况，连续多次失败进行熔断保护。 Hystrix dashboard,Turbine 负责监控 Hystrix的熔断情况，并给予图形化的展示 Spring Cloud Config 提供了统一的配置中心服务 当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息 所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用 最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们进行后续分析 Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。 微服务架构是一种趋势，Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。 从现在开始

一、为什么需要服务发现 简单来说，服务化的核心就是将传统的一站式应用根据业务拆分成一个一个的服务，而微服务在这个基础上要更彻底地去耦合（不再共享DB、KV，去掉重量级ESB），并且强调DevOps和快速演化。这就要求我们必须采用与一站式时代、泛SOA时代不同的技术栈，而Spring Cloud就是其中的佼佼者。 DevOps是英文Development和Operations的合体，他要求开发、测试、运维进行一体化的合作，进行更小、更频繁、更自动化的应用发布，以及围绕应用架构来构建基础设施的架构。这就要求应用充分的内聚，也方便运维和管理。这个理念与微服务理念不谋而合。 接下来我们从服务化架构演进的角度来看看为什么Spring Cloud更适应微服务架构。 1.1 从使用nginx说起 最初的服务化解决方案是给提供相同服务提供一个统一的域名，然后服务调用者向这个域名发送HTTP请求，由Nginx负责请求的分发和跳转。 这种架构存在很多问题: Nginx作为中间层，在配置文件中耦合了服务调用的逻辑，这削弱了微服务的完整性，也使得Nginx在一定程度上变成了一个重量级的ESB。 服务的信息分散在各个系统，无法统一管理和维护。每一次的服务调用都是一次尝试，服务消费者并不知道有哪些实例在给他们提供服务。这不符合DevOps的理念。 无法直观的看到服务提供者和服务消费者当前的运行状况和通信频率

一、Spring Boot 简介 Spring Boot是由Pivotal团队提供的全新框架，其设计目的是简化新的Spring应用的初始搭建以及开发过程。该框架使用了特定的方式进行配置，从而使开发人员不再需要定义样板化的配置。Spring Boot致力于在蓬勃发展的快速应用开发领域（rapid application development）成为领导者。 在使用Spring Boot之前，我们需要搭建一个项目架构并配置各种第三方库的依赖，还需要在XML中配置很多内容，繁杂且容易出错。Spring Boot 完全打破了我们之前的使用习惯，一分钟就可以创建一个Web开发的项目了通过Starter的方式轻松集成第三方的框架；去掉了XML的配置，全部用注解代替。 Spring Boot Starter 是用来简化jar包依赖的，集成一个框架只需要引入一个Starter，然后在属性文件中配置一些值，整个集成的过程就结束了。不得不说，Spring Boot 在内部做了很多的处理，让开发人员使用起来更加简单了。 下面总价性列几个使用Spring Boot 开发的优点： 基于 Spring 开发 Web 应用更加容易； 采用基于注解方式的配置，避免了编写大量重复的 XML 配置； 可以轻松集成 Spring 家族的其他框架，比如：Spring JDBC、Spring Data等等；

我们讨论了hystrix+feign+ribbon，但是可能很多人都知道hystrix还有线程隔离，信号量隔离，等等各种参数配置，在这几就记录下hystrix的参数， 一、hystrix参数使用方法 通过注解@HystrixCommand的commandProperties去配置， 如下就是hystrix命令超时时间命令执行超时时间，为1000ms和执行是不启用超时 了解springcloud架构可以加求求：三五三六二四七二五九 @RestController public class MovieController { @Autowired private RestTemplate restTemplate; @GetMapping("/movie/{id}") @HystrixCommand(commandProperties = { @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000"), @HystrixProperty(name = "execution.timeout.enabled", value = "false")},fallbackMethod = "findByIdFallback") public User findById(

docker-hystrix-dashboard-turbine： Hystrix的主要优点之一是它收集关于每个HystrixCommand的一套指标。 了解springcloud架构可以加求求：三五三六二四七二五九 Hystrix仪表板以有效的方式显示每个断路器的运行状况，通过Hystrix Dashboard我们可以在直观地看到各Hystrix Command的断路器是否打开，请求响应时间, 请求失败率，请求超时个数等等数据。 但是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 我们需要一个工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine， ，这节我们讨论一下，怎么用turbine+hystrix-dashboard监听两个消费者服务 一、监听模块microservice-consumer-movie-feign-with-hystrix断路器的运行状况 二、监听模块microservice-consumer-movie-ribbon-with-hystrix1断路器的运行状况 2.1、创建模块microservice-consumer-movie-ribbon-with-hystrix1 项目结构如下： 2.2、pom.xml文件 <?xml version="1.0