分布式系统面临的问题java
复杂分布式体系结构中的应用程序有数十个依赖关系,每一个依赖关系在某些时候将不可避免地失败。 服务雪崩 多个微服务之间调用的时候,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”。若是扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用愈来愈多的系统资源,进而引发系统崩溃,所谓的“雪崩效应”. 对于高流量的应用来讲,单一的后端依赖可能会致使全部服务器上的全部资源都在几秒钟内饱和。比失败更糟糕的是,这些应用程序还可能致使服务之间的延迟增长,备份队列,线程和其余系统资源紧张,致使整个系统发生更多的级联故障。这些都表示须要对故障和延迟进行隔离和管理,以便单个依赖关系的失败,不能取消整个应用程序或系统。 备注:通常状况对于服务依赖的保护主要有3中解决方案: (1)熔断模式:这种模式主要是参考电路熔断,若是一条线路电压太高,保险丝会熔断,防止火灾。放到咱们的系统中,若是某个目标服务调用慢或者有大量超时,此时,熔断该服务的调用,对于后续调用请求,不在继续调用目标服务,直接返回,快速释放资源。若是目标服务状况好转则恢复调用。 (2)隔离模式:这种模式就像对系统请求按类型划分红一个个小岛的同样,当某个小岛被火少光了,不会影响到其余的小岛。例如能够对不一样类型的请求使用线程池来资源隔离,每种类型的请求互不影响,若是一种类型的请求线程资源耗尽,则对后续的该类型请求直接返回,再也不调用后续资源。这种模式使用场景很是多,例如将一个服务拆开,对于重要的服务使用单独服务器来部署,再或者公司最近推广的多中心。 (3)限流模式:上述的熔断模式和隔离模式都属于出错后的容错处理机制,而限流模式则能够称为预防模式。限流模式主要是提早对各个类型的请求设置最高的QPS阈值,若高于设置的阈值则对该请求直接返回,再也不调用后续资源。这种模式不能解决服务依赖的问题,只能解决系统总体资源分配问题,由于没有被限流的请求依然有可能形成雪崩效应。
Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,好比超时、异常等,Hystrix可以保证在一个依赖出问题的状况下,不会致使总体服务失败,避免级联故障,以提升分布式系统的弹性。 “断路器”自己是一种开关装置,当某个服务单元发生故障以后,经过断路器的故障监控(相似熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方没法处理的异常,这样就保证了服务调用方的线程不会被长时间、没必要要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。 服务降级、服务熔断、服务限流、接近实时的监控
服务熔断 熔断机制是应对雪崩效应的一种微服务链路保护机制。 当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回"错误"的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制经过Hystrix实现。Hystrix会监控微服务间调用的情况,当失败的调用到必定阈值,缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。 =====处理异常业务逻辑=====provider client处理====
2.1>、参考cloud-provider-dept-8001新建cloud-provider-dept-8001-hystrixweb
2.2>、POM新增spring
<!-- hystrix 客户端 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency>
2.3>、YML修改后端
eureka: instance: instance-id: cloud-dept8001-hystirx #eureka服务列表中显示的名称--hystix prefer-ip-address: true #访问路径能够显示IP地址
2.4>、修改DeptControllerapi
一旦调用服务方法失败并排除了错误信息后,会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法。 @HystrixCommand(fallbackMethod = "getHystrixCommand") @RequestMapping(value="/dept/get/{id}",method=RequestMethod.GET) public Dept get(@PathVariable("id") Long id) { if(id>200){ throw new RuntimeException(); } return service.get(id); } //参数必须同样 public Dept getHystrixCommand(@PathVariable("id") Long id){ return new Dept().setDname("这是一个null部门."); }
2.5>、修改主启动类APP服务器
package com.lee.cloud; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker; import org.springframework.cloud.netflix.eureka.EnableEurekaClient; @EnableCircuitBreaker//对hystrixR熔断机制的支持 @EnableEurekaClient //本服务启动后会自动注册进eureka服务中 @SpringBootApplication public class DeptProvider8001_APP_hystrix { public static void main(String[] args) { SpringApplication.run(DeptProvider8001_APP_hystrix.class,args); } }
测试:app
1>、启动3个Eureka服务 2>、启动cloud-provider-dept-8001-hystrix 3>、启动cloud-consumer-dept-80 4>、访问http://localhost:80/consumer/dept/get/9999 结果: {"deptno":null,"dname":"这是一个null部门.","db_source":null} 思考: 服务熔断,容易形成方法膨胀,如何解决呢?
服务降级处理是在客户端实现完成的,与服务端没有关系框架
总体资源快不够了,忍痛将某些服务先关掉,待渡过难关,再开启回来。 ===关闭不重要的服务===consumer client处理=====
3.1>、修改cloud-consumer-dept-80项目中个的service接口分布式
根据已有的DeptFeignService接口,新建一个实现了FallbackFactory接口的类DeptFeignServiceFallbackFactory package com.lee.cloud.feign.service; import com.lee.cloud.entity.Dept; import feign.hystrix.FallbackFactory; import org.springframework.stereotype.Component; import java.util.List; @Component public class DeptFeignServiceFallbackFactory implements FallbackFactory<DeptFeignService> { @Override public DeptFeignService create(Throwable throwable) { return new DeptFeignService() { @Override public Dept get(long id) { return new Dept().setDname("服务已经降级。。").setDb_source("服务降级 没有找到 database."); } @Override public List<Dept> list() { return null; } @Override public boolean add(Dept dept) { return false; } }; } }
3.2>、DeptFeignService接口在注解@FeignClient中添加fallbackFactory属性值ide
@FeignClient(value = "CLOUD-DEPT",fallbackFactory = DeptFeignServiceFallbackFactory.class)
3.3>、cloud-consumer-dept-80-feign工程修改yml
添加 feign: hystrix: enabled: true
测试:
1》、启动3个eureka服务 2》、启动服务提供者cloud-provider-dept-8001服务,注意不是cloud-provider-dept-8001-hystrix 3》、启动cloud-consumer-dept-80-feign 4》、正常访问测试 http://localhost:80/consumer/dept/get/1 5》、故意关闭cloud-provider-dept-8001 6》、客户端本身调用提示 结果: {"deptno":null,"dname":"服务已经降级。。","db_source":"服务降级 没有找到 database."}
思考: 服务熔断 和 服务降级 有什么区别? 【服务熔断】 通常是某个服务故障或者异常引发,相似现实世界中的"保险丝",当某个异常条件被处罚,直接熔断整个服务,而不是一直等到此服务超时。 【服务降级】 所谓降级,通常是从总体负荷考虑,就是当某个服务熔断以后,服务器将再也不被调用。 此时客户端能够本身准备一个本地的fallback回调,返回一个缺省值。 这样作,虽然服务水平降低,但好歹可用,比直接挂掉要强。
除了隔离依赖服务的调用之外,Hystrix还提供了准实时的调用监控(Hystrix Dashboard),Hystrix会持续地记录全部经过Hystrix发起的请求的执行信息,并以统计报表和图形的形式展现给用户,包括每秒执行多少请求多少成功,多少失败等。Netflix经过hystrix-metrics-event-stream项目实现了对以上指标的监控。Spring Cloud也提供了Hystrix Dashboard的整合,对监控内容转化成可视化界面。
4.1>、新建module,cloud-consumer-dept-9001-hystirx-dashboard
4.2>、POM文件
<dependencies> <!-- 本身定义的api --> <dependency> <groupId>com.lee</groupId> <artifactId>cloud-api</artifactId> <version>${project.version}</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- 修改后当即生效,热部署 --> <dependency> <groupId>org.springframework</groupId> <artifactId>springloaded</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> </dependency> <!-- Ribbon相关 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-ribbon</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-config</artifactId> </dependency> <!-- feign相关 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-feign</artifactId> </dependency> <!-- hystrix和 hystrix-dashboard相关--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId> </dependency> </dependencies>
4.3>、YML文件
server: port: 9001
4.4>、主启动类
package com.lee.cloud; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.hystrix.dashboard.EnableHystrixDashboard; @EnableHystrixDashboard @SpringBootApplication public class DeptConsumer_DashBoard_9001_App { public static void main(String[] args) { SpringApplication.run(DeptConsumer_DashBoard_9001_App.class,args); } }
4.5>、全部provider微服务提供者都须要添加监控依赖
<!-- actuator监控信息完善 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
测试:
一、启动cloud-consumer-dept-9001-hystrix-dashboard 访问:http://localhost:9001/hystrix 二、启动3个eureka集群 三、启动cloud-provider-dept-8001-hystrix 访问:http://localhost8001/dept/list 四、http://localhost:8001/hystrix.stream delay:2000ms title: demo1