多拷贝一个provider 检查是否,2个provider是否都有执行
order-provider:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
>
>org.springframework.retry >
>spring-retry >
>
order-provider:
ribbon:
ConnectTimeout: 250 #连接超时时间
ReadTimeout: 1000 #数据读取超时时间
OkToRetryOnAllOperations: true #是否对所有操作进行重试
MaxAutoRetries: 1 #对当前实例的重试次数
MaxAutoRetriesNextServer: 1 #切换实例的重试次数
前面我们使用的RestTemplate实现REST API调用,代码大致如下:
@GetMapping("/buy/{id}")
public Product order() {
Product product = restTemplate.getForObject(“http://shop-service
product/product/1”, Product.class);
return product;
}
由代码可知,我们是使用拼接字符串的方式构造URL的,该URL只有一个参数。但是,在现实中,URL 中往往含有多个参数。这时候我们如果还用这种方式构造URL,那么就会非常痛苦。那应该如何解决?
我们带着这样的问题进入到本章的学习。
Feign是Netflflix开发的声明式,模板化的HTTP客户端,其灵感来自Retrofifit,JAXRS-2.0以及WebSocket. Feign可帮助我们更加便捷,优雅的调用HTTP API。
在SpringCloud中,使用Feign非常简单——创建一个接口,并在接口上添加一些注解,代码就完
成了。 Feign支持多种注解,例如Feign自带的注解或者JAX-RS注解等。
SpringCloud对Feign进行了增强,使Feign支持了SpringMVC注解,并整合了Ribbon和Eureka, 从而让Feign的使用更加方便。
<!--springcloud整合的openFeign-->
org.springframework.cloud
spring-cloud-starter-openfeign
启动类添加Feign的支持
通过@EnableFeignClients注解开启Spring Cloud Feign的支持功能
启动类激活FeignClient
创建一个Feign接口,此接口是在Feign中调用微服务的核心接口
在服务消费者 shop_service_order 添加一个 ProductFeginClient 接口
//指定需要调用的微服务名称
@FeignClient(name="shop-service-product")
public interface ProductFeginClient {
//调用的请求路径
@RequestMapping(value = "/product/{id}",method = RequestMethod.GET)
public Product findById(@PathVariable("id") Long id);
}
Ribbon是一个基于 HTTP 和 TCP 客户端 的负载均衡的工具。它可以 在客户端 配置
RibbonServerList(服务端列表),使用 HttpClient 或 RestTemplate 模拟http请求,步骤相当繁琐。Feign 是在 Ribbon的基础上进行了一次改进,是一个使用起来更加方便的 HTTP 客户端。采用接口的方式, 只需要创建一个接口,然后在上面添加注解即可 ,将需要调用的其他服务的方法定义成抽象方法即可, 不需要自己构建http请求。然后就像是调用自身工程的方法调用,而感觉不到是调用远程方法,使得编写客户端变得非常容易
Feign中本身已经集成了Ribbon依赖和自动配置,因此我们不需要额外引入依赖,也不需要再注册 RestTemplate 对象。另外,我们可以像上节课中讲的那样去配置Ribbon,可以通过 ribbon.xx 来进 行全局配置。也可以通过 服务名.ribbon.xx 来对指定服务配置:
启动两个 shop_service_product ,重新测试可以发现使用Ribbon的轮询策略进行负载均衡
雪崩效应
在微服务架构中,一个请求需要调用多个服务是非常常见的。如客户端访问A服务,而A服务需要调用B 服务,B服务需要调用C服务,由于网络原因或者自身的原因,如果B服务或者C服务不能及时响应,A服 务将处于阻塞状态,直到B服务C服务响应。此时若有大量的请求涌入,容器的线程资源会被消耗完毕,导致服务瘫痪。服务与服务之间的依赖性,故障会传播,造成连锁反应,会对整个微服务系统造成灾难 性的严重后果,这就是服务故障的“雪崩”效应。
雪崩是系统中的蝴蝶效应导致其发生的原因多种多样,有不合理的容量设计,或者是高并发下某一个方法响应变慢,亦或是某台机器的资源耗尽。从源头上我们无法完全杜绝雪崩源头的发生,但是雪崩的根本原因来源于服务之间的强依赖,所以我们可以提前评估,做好熔断,隔离,限流。
服务隔离
顾名思义,它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相对独立,无强依赖。 当有故障发生时,能将问题和影响隔离在某个模块内部,而不扩散风险,不波及其它模块,不影响整体的系统服务。
熔断降级
熔断这一概念来源于电子工程中的断路器(Circuit Breaker)。在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整体的可用性,可以暂时切断对下游服务的调用。这种牺牲局部,保全整体的措施就叫做熔断。
所谓降级,就是当某个服务熔断之后,服务器将不再被调用,此时客户端可以自己准备一个本地的fallback回调,返回一个缺省值。 也可以理解为兜底
服务限流
限流可以认为服务降级的一种,限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的,为了保证系统的稳固运行,一旦达到的需要限制的阈值,就需要限制流量并采取少量措施以完成限制流量的目的。比方:推迟解决,拒绝解决,或者者部分拒绝解决等等。
Hystrix是由Netflflix开源的一个延迟和容错库,用于隔离访问远程系统、服务或者第三方库,防止级联失败,从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。
包裹请求:使用HystrixCommand包裹对依赖的调用逻辑,每个命令在独立线程中执行。这使用了设计模式中的“命令模式”。
跳闸机制:当某服务的错误率超过一定的阈值时,Hystrix可以自动或手动跳闸,停止请求该服务一段时间。
资源隔离:Hystrix为每个依赖都维护了一个小型的线程池(或者信号量)。如果该线程池已满,发往该依赖的请求就被立即拒绝,而不是排队等待,从而加速失败判定。
监控:Hystrix可以近乎实时地监控运行指标和配置的变化,例如成功、失败、超时、以及被拒绝的请求等。
回退机制:当请求失败、超时、被拒绝,或当断路器打开时,执行回退逻辑。回退逻辑由开发人员自行提供,例如返回一个缺省值。
自我修复:断路器打开一段时间后,会自动进入“半开”状态。
>
>org.springframework.boot >
>spring-boot-starter-actuator >
>
>
>org.springframework.cloud >
>spring-cloud-starter-netflix-hystrix >
>
>
>org.springframework.cloud >
>spring-cloud-starter-netflix-hystrix-dashboard >
>
默认一个服务降级
SpringCloud Fegin默认已为Feign整合了hystrix,所以添加Feign依赖后就不用在添加hystrix,那么怎么才能让Feign的熔断机制生效呢,只要按以下步骤开发:
management:
endpoints:
web:
exposure:
include: hystrix.stream
我们知道,当请求失败,被拒绝,超时的时候,都会进入到降级方法中。但进入降级方法并不意味着断路器已经被打开。那么如何才能了解断路器中的状态呢?
Hystrix的监控平台
除了实现容错功能,Hystrix还提供了近乎实时的监控,HystrixCommand和
HystrixObservableCommand在执行时,会生成执行结果和运行指标。比如每秒的请求数量,成功数量等。这些状态会暴露在Actuator提供的/health端点中。只需为项目添加 spring-boot-actuator 依赖,重启项目,访问http://localhost:9004/actuator/hystrix.stream ,即可看到实时的监控数据。
>
>
>org.springframework.boot >
>spring-boot-starter-actuator >
>
>
>org.springframework.cloud >
>spring-cloud-starter-netflix-hystrix >
>
>
>org.springframework.cloud >
>spring-cloud-starter-netflix-hystrix-dashboard >
>
>
在微服务架构体系中,每个服务都需要配置Hystrix DashBoard监控。如果每次只能查看单个实例的监控数据,就需要不断切换监控地址,这显然很不方便。要想看这个系统的Hystrix Dashboard数据就需要用到Hystrix Turbine。Turbine是一个聚合Hystrix 监控数据的工具,他可以将所有相关微服务的Hystrix 监控数据聚合到一起,方便使用。引入Turbine后,整个监控系统架构如下:
>
>org.springframework.cloud >
>spring-cloud-starter-netflix-turbine >
>
server:
port: 7002
spring:
application:
name: my-cloud-hystrix-dashboard
eureka:
client:
service-url:
defaultZone: http://root:ok@localhost:7001/eureka/
instance:
prefer-ip-address: true
turbine:
# 要监控的微服务列表,多个用,分隔
app-config: user-consumer
cluster-name-expression: "'default'"
@SpringBootApplication
@EnableHystrixDashboard
@EnableTurbine
public class MyHystrixDashboardApp {
public static void main(String[] args) {
SpringApplication.run(MyHystrixDashboardApp.class,args);
}
}
作为一个独立的监控项目,需要配置启动类,开启HystrixDashboard监控平台,并激活Turbine
浏览器访问 http://localhost:7002/hystrix 展示HystrixDashboard。并在url位置输入 http://localhost:7002/turbine.stream,动态根据turbine.stream数据展示多个微服务的监控数据
熔断器有三个状态 CLOSED 、 OPEN 、 HALF_OPEN 熔断器默认关闭状态,当触发熔断后状态变更为OPEN ,在等待到指定的时间,Hystrix会放请求检测服务是否开启,这期间熔断器会变为 HALF_OPEN 半启状态,熔断探测服务可用则继续变更为 CLOSED 关闭熔断器。
Closed:关闭状态(断路器关闭),所有请求都正常访问。代理类维护了最近调用失败的次数,如果某次调用失败,则使失败次数加1。如果最近失败次数超过了在给定时间内允许失败的阈值,则代理类切换到断开(Open)状态。此时代理开启了一个超时时钟,当该时钟超过了该时间,则切换到半断开(Half-Open)状态。该超时时间的设定是给了系统一次机会来修正导致调用失败的错误。
Open:打开状态(断路器打开),所有请求都会被降级。Hystix会对请求情况计数,当一定时间 内失败请求百分比达到阈值,则触发熔断,断路器会完全关闭。默认失败比例的阈值是50%,请求 次数最少不低于20次。
Half Open:半开状态,open状态不是永久的,打开后会进入休眠时间(默认是5S)。随后断路 器会自动进入半开状态。此时会释放1次请求通过,若这个请求是健康的,则会关闭断路器,否则 继续保持打开,再次进行5秒休眠计时。
为了能够精确控制请求的成功或失败,我们在 my-cloud-user-consumer的调用业务中加入一段逻辑:
这样如果参数是id为1,一定失败,其它情况都成功。
我们准备两个请求窗口:
一个请求:http://localhost:8080/consumer/1,注定失败
一个请求:http://localhost:8080/consumer/2,肯定成功