SpringCloud
- 参考黑马教程学习
- 1、初识微服务
- 1.1 什么是微服务?
- 1.2 系统架构演变
- 1.2.1 集中式架构
- 1.2.2 垂直拆分架构
- 1.2.3 分布式服务
- 1.3.4 流动计算架构(SOA)
- 1.2.5 微服务
- 1.3 服务的调用方式
- 1.3.1 Spring 的远程调用
- 2、SpringCloud
- 2.1 什么是SpringCloud?
- 2.2 微服务场景模拟
- 2.2.1 服务提供者
- 2.2.1.1 配置文件
- 2.2.1.2 实体类
- 2.2.1.3 UserMapper
- 2.2.1.4 UserService
- 2.2.1.5 UserController
- 2.2.2 服务调用者
- 2.2.2.1 项目启动类
- 2.2.2.2 application.yml
- 2.2.2.3 UserController
- 2.2.2.4 User实体类
- 2.2.3 启动测试
- 2.3 Eureka注册中心
- 2.3.1 什么是eureka?
- 2.3.2 eureka示例
- 2.3.2.1 引入dependencies
- 2.3.2.2 编写application.yml
- 2.3.2.3 项目引导类
- 2.3.2.4 访问
- 2.3.3 将服务注册到eureka
- 2.3.3.1 pom.xml
- 2.3.3.2 application.yml
- 2.3.3.3 项目引导类
- 2.3.4 从eureka中拉取服务列表
- 2.3.4.1 pom.xml
- 2.3.4.2 修改配置文件
- 2.3.4.3 项目引导类
- 2.3.4.4 Controller
- 2.3.4 服务提供者
- 2.3.5 服务消费者
- 2.3.6 失效剔除和自我保护
- 2.4 负载均衡Ribbon
- 2.4.1 开启两个服务提供方
- 2.4.2 开启负载均衡
- 2.4.3 修改负载均衡策略
- 2.5 Hystrix熔断机制
- 2.5.1 Hystrix的作用
- 2.5.2 什么是系统雪崩?
- 2.5.3 线程隔离,服务降级
- 2.5.3.1 动手实践
- 2.5.3.2 设置超时时间
- 2.5.4 服务熔断
- 2.5.4.1 服务熔断示例
- 2.5.5 Fegin远程调用
- 2.5.5.1 什么是fegin?
- 2.5.5.2 引入依赖
- 2.5.5.3 开启fegin功能
- 2.5.5.4 定义远程调用接口
- 2.5.5.5 Fegin的负载均衡
- 2.5.5.6 Fegin的熔断
- 2.5.6 Zuul网关
- 2.5.6.1 编写配置文件
- 2.5.6.2 项目引导类
- 2.5.6.3 定义映射规则
- 2.5.6.4 面向服务的路由
- 2.5.6.5 路由前缀
- 2.5.6.6 过滤器
- 2.5.6.7 自定义过滤器
- 2.5.6.8 Zull的负载均衡和熔断
参考黑马教程学习
1、初识微服务
1.1 什么是微服务?
微服务顾名思义,就是一个完整的系统被拆分成为各个微小的模块,它本质上也是一种服务。具有如下特点
- 单一职责:微服务中每一个服务都对应唯一的业务能力,做到单一职责
- 微:微服务的服务拆分粒度很小,例如一个用户管理就可以作为一个服务。每个服务虽小,但“五脏俱全”。
- 面向服务:面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现,做到与平台和语言无关,也不限定用什么技术实现,只要提供Rest的接口即可。
- 自治:自治是说服务间互相独立,互不干扰
- 团队独立:每个服务都是一个独立的开发团队,人数不能过多。
- 技术独立:因为是面向服务,提供Rest接口,使用什么技术没有别人干涉
- 前后端分离:采用前后端分离开发,提供统一Rest接口,后端不用再为PC、移动段开发不同接口
- 数据库分离:每个服务都使用自己的数据源
- 部署独立,服务间虽然有调用,但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件,可复用,可替换,降低耦合,易维护
1.2 系统架构演变
随着互联网的发展,网站应用的规模不断扩大。需求的激增,带来的是技术上的压力。系统架构也因此不断的演进、升级、迭代。从单一应用,到垂直拆分,到分布式服务,到SOA,以及现在火热的微服务架构。演变的流程图如下:
1.2.1 集中式架构
集中式架构就是将所有的功能集成在一个应用上面,这就是集中式架构,当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。此时,用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
存在的问题:
- 代码耦合,开发维护困难
- 无法针对不同模块进行针对性优化
- 无法水平扩展
- 单点容错率低,并发能力差
1.2.2 垂直拆分架构
当访问量逐渐增大,单一应用无法满足需求,此时为了应对更高的并发和业务需求,我们根据业务功能对系统进行拆分:
优点:
- 系统拆分实现了流量分担,解决了并发问题
- 可以针对不同模块进行优化
- 方便水平扩展,负载均衡,容错率提高
缺点:
- 系统间相互独立,会有很多重复开发工作,影响开发效率
1.2.3 分布式服务
当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。此时,用于提高业务复用及整合的分布式调用是关键。
优点:
- 将基础服务进行了抽取,系统间相互调用,提高了代码复用和开发效率
缺点:
- 系统间耦合度变高,调用关系错综复杂,难以维护
1.3.4 流动计算架构(SOA)
SOA :面向服务的架构
当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。此时,用于提高机器利用率的资源调度和治理中心(SOA)是关键
缺点:
- 服务间会有依赖关系,一旦某个环节出错会影响较大
- 服务关系复杂,运维、测试部署困难,不符合DevOps思想
1.2.5 微服务
1.3 服务的调用方式
无论是微服务还是SOA,都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢?
常见的远程调用方式有以下2种:
- RPC:Remote Produce Call远程过程调用,类似的还有RMI。自定义数据格式,基于原生TCP通信,速度快,效率高。早期的webservice,现在热门的dubbo,都是RPC的典型代表
- Http:http其实是一种网络传输协议,基于TCP,规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议,也可以用来进行远程服务调用。缺点是消息封装臃肿,优势是对服务的提供和调用方没有任何技术限定,自由灵活,更符合微服务理念。
现在热门的Rest风格,就可以通过http协议来实现。
1.3.1 Spring 的远程调用
Spring提供了一个RestTemplate模板工具类,对基于Http的客户端进行了封装,并且实现了对象与json的序列化和反序列化,非常方便。RestTemplate并没有限定Http的客户端类型,而是进行了抽象,目前常用的3种都有支持:
- HttpClient
- OkHttp
- JDK原生的URLConnection(默认的)
直接在项目引导类上注册RestTemplate对象
@SpringBootApplication
public class HttpDemoApplication {
public static void main(String[] args) {
SpringApplication.run(HttpDemoApplication.class, args);
}
@Bean
public RestTemplate restTemplate() {
return new RestTemplate();
}
}
测试RestTemplate的远程调用
@RunWith(SpringRunner.class)
@SpringBootTest(classes = HttpDemoApplication.class)
public class HttpDemoApplicationTests {
@Autowired
private RestTemplate restTemplate;
@Test
public void httpGet() {
// 调用springboot案例中的rest接口
User user = this.restTemplate.getForObject("http://localhost/user/1", User.class);
System.out.println(user);
}
}
通过RestTemplate的getForObject()方法,传递url地址及实体类的字节码,RestTemplate会自动发起请求,接收响应,并且帮我们对响应结果进行反序列化。
2、SpringCloud
2.1 什么是SpringCloud?
SpringCloud是Spring家族提供的一个基于http远程调用的一个微服务的框架,它其实就是几大组件的集合,要想玩好SpringCloud,就必须学好这几大组件。
以上包含配置管理,服务发现,智能路由,负载均衡四大功能,除此之外还有熔断器,以下就是SpringCloud五大组件。
2.2 微服务场景模拟
2.2.1 服务提供者
2.2.1.1 配置文件
server:
port: 8081
spring:
datasource:
url: jdbc:mysql://localhost:3306/springcloud?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=utf8
username: root
password: 111111
mybatis:
type-aliases-package: cn.gzgs.service.pojo
2.2.1.2 实体类
@Data
@Table(name = "user")//绑定数据库的表,这个很重要,是我们不写sql语句的基础
public class User implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)//标识主键,这个很重要
private Long id;
private String userName;
private String password;
private String type;
}
2.2.1.3 UserMapper
@Mapper
public interface UserMapper extends tk.mybatis.mapper.common.Mapper<User>{
}
2.2.1.4 UserService
@Service
public class UserService {
@Autowired
private UserMapper userMapper;
public User queryById(Long id) {
return this.userMapper.selectByPrimaryKey(id);
}
}
2.2.1.5 UserController
@RestController
@RequestMapping("user")
public class UserController {
@Autowired
private UserService userService;
@GetMapping("{id}")
public User queryById(@PathVariable("id") Long id) {
return this.userService.queryById(id);
}
}
2.2.2 服务调用者
2.2.2.1 项目启动类
@SpringBootApplication
public class GzgsServiceConsumerApplication {
@Bean
public RestTemplate restTemplate() {
return new RestTemplate();
}
public static void main(String[] args) {
SpringApplication.run(ItcastServiceConsumerApplication.class, args);
}
}
2.2.2.2 application.yml
server:
port: 80
2.2.2.3 UserController
@Controller
@RequestMapping("consumer/user")
public class UserController {
@Autowired
private RestTemplate restTemplate;
@GetMapping
@ResponseBody
public User queryUserById(@RequestParam("id") Long id){
User user = this.restTemplate.getForObject("http://localhost:8081/user/" + id, User.class);
return user;
}
}
2.2.2.4 User实体类
与服务提供者的User一样
2.2.3 启动测试
通过访问服务调用者提供的地址访问服务提供者的资源
2.3 Eureka注册中心
2.3.1 什么是eureka?
eureka是服务的管理组件,SpringCloud通过这个组件实现了服务的自动注册、发现、状态监控。
Eureka就好比是滴滴,负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务,而是把自己的需求告诉Eureka,然后Eureka会把符合你需求的服务告诉你。
同时,服务提供方与Eureka之间通过心跳机制进行监控,当某个服务提供方出现问题,Eureka自然会把它从服务列表中剔除。
这就实现了服务的自动注册、发现、状态监控。
Eureka架构中的三个核心角色:
- 服务注册中心
Eureka的服务端应用,提供服务注册和发现功能,就是刚刚我们建立的gzgs-eureka。 - 服务提供者
提供服务的应用,可以是SpringBoot应用,也可以是其它任意技术实现,只要对外提供的是Rest风格服务即可。本例中就是我们实现的gzgs-service-provider。 - 服务消费者
消费应用从注册中心获取服务列表,从而得知每个服务方的信息,知道去哪里调用服务方。本例中就是我们实现的gzgs-service-consumer。 - 心跳(续约):提供者定期通过http方式向Eureka刷新自己的状态
2.3.2 eureka示例
2.3.2.1 引入dependencies
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
2.3.2.2 编写application.yml
server:
port: 10086 # 端口
spring:
application:
name: eureka-server # 应用名称,会在Eureka中显示
eureka:
client:
service-url: # EurekaServer的地址,现在是自己的地址,如果是集群,需要加上其它Server的地址。
defaultZone: http://127.0.0.1:${server.port}/eureka
2.3.2.3 项目引导类
@SpringBootApplication
@EnableEurekaServer // 声明当前springboot应用是一个eureka服务中心
public class GzgsEurekaApplication {
public static void main(String[] args) {
SpringApplication.run(ItcastEurekaApplication.class, args);
}
}
2.3.2.4 访问
2.3.3 将服务注册到eureka
2.3.3.1 pom.xml
<!-- Eureka客户端 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<!-- SpringCloud的依赖 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Finchley.SR2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
2.3.3.2 application.yml
server:
port: 8081
spring:
datasource:
url: jdbc:mysql://localhost:3306/springcloud
username: root
password: root
driverClassName: com.mysql.jdbc.Driver
application:
name: service-provider # 应用名称,注册到eureka后的服务名称
mybatis:
type-aliases-package: cn.itcast.service.pojo
eureka:
client:
service-url: # EurekaServer地址
defaultZone: http://127.0.0.1:10086/eureka?serverTimezone=UTC&useSSL=false&useUnicode=true&characterEncoding=utf8
2.3.3.3 项目引导类
@SpringBootApplication
@EnableDiscoveryClient //开启eureka客户端的功能
public class GzgsServiceProviderApplication {
public static void main(String[] args) {
SpringApplication.run(ItcastServiceApplication.class, args);
}
}
2.3.4 从eureka中拉取服务列表
2.3.4.1 pom.xml
避免篇幅过长,省略,具体和2.3.3.1一样
2.3.4.2 修改配置文件
server:
port: 80
spring:
application:
name: service-consumer
eureka:
client:
service-url:
defaultZone: http://localhost:10086/eureka
2.3.4.3 项目引导类
@SpringBootApplication
@EnableDiscoveryClient // 开启Eureka客户端
public class GzgsServiceConsumerApplication {
@Bean
public RestTemplate restTemplate(){
return new RestTemplate();
}
public static void main(String[] args) {
SpringApplication.run(GzgsServiceConsumerApplication.class, args);
}
}
2.3.4.4 Controller
@Controller
@RequestMapping("consumer/user")
public class UserController {
@Autowired
private RestTemplate restTemplate;
@Autowired
private DiscoveryClient discoveryClient; // eureka客户端,可以获取到eureka中服务的信息
@GetMapping
@ResponseBody
public User queryUserById(@RequestParam("id") Long id){
// 根据服务名称,获取服务实例。有可能是集群,所以是service实例集合
List<ServiceInstance> instances = discoveryClient.getInstances("service-provider");
// 因为只有一个Service-provider。所以获取第一个实例
ServiceInstance instance = instances.get(0);
// 获取ip和端口信息,拼接成服务地址
String baseUrl = "http://" + instance.getHost() + ":" + instance.getPort() + "/user/" + id;
User user = this.restTemplate.getForObject(baseUrl, User.class);
return user;
}
}
随着业务的增加,为减少eureka的压力,可以使用高可用的eureka,即启动两个eureka,相互注册,它们会同步服务注册的信息。
2.3.4 服务提供者
服务提供者要向EurekaServer注册服务,并且完成服务续约等工作。
服务注册
服务提供者在启动时,会检测配置属性中的:eureka.client.register-with-eureka=true
参数是否正确,事实上默认就是true。如果值确实为true,则会向EurekaServer发起一个Rest请求,并携带自己的元数据信息,Eureka Server会把这些信息保存到一个双层Map结构中。
- 第一层Map的Key就是服务id,一般是配置中的
spring.application.name
属性 - 第二层Map的key是服务的实例id。一般host+ serviceId + port,例如:
locahost:service-provider:8081
- 值则是服务的实例对象,也就是说一个服务,可以同时启动多个不同实例,形成集群。
服务续约
在注册服务完成以后,服务提供者会维持一个心跳(定时向EurekaServer发起Rest请求),告诉EurekaServer:“我还活着”。这个我们称为服务的续约(renew);
有两个重要参数可以修改服务续约的行为:
eureka:
instance:
lease-expiration-duration-in-seconds: 90
lease-renewal-interval-in-seconds: 30
- lease-renewal-interval-in-seconds:服务续约(renew)的间隔,默认为30秒
- lease-expiration-duration-in-seconds:服务失效时间,默认值90秒
也就是说,默认情况下每个30秒服务会向注册中心发送一次心跳,证明自己还活着。如果超过90秒没有发送心跳,EurekaServer就会认为该服务宕机,会从服务列表中移除,这两个值在生产环境不要修改,默认即可。
但是在开发时,这个值有点太长了,经常我们关掉一个服务,会发现Eureka依然认为服务在活着。所以我们在开发阶段可以适当调小。
eureka:
instance:
lease-expiration-duration-in-seconds: 10 # 10秒即过期
lease-renewal-interval-in-seconds: 5 # 5秒一次心跳
2.3.5 服务消费者
获取服务列表
当服务消费者启动时,会检测eureka.client.fetch-registry=true
参数的值,如果为true,则会拉取Eureka Server服务的列表只读备份,然后缓存在本地。并且每隔30秒
会重新获取并更新数据。我们可以通过下面的参数来修改:
eureka:
client:
registry-fetch-interval-seconds: 5
生产环境中,我们不需要修改这个值。
但是为了开发环境下,能够快速得到服务的最新状态,我们可以将其设置小一点。
2.3.6 失效剔除和自我保护
服务下线
当服务进行正常关闭操作时,它会触发一个服务下线的REST请求给Eureka Server,告诉服务注册中心:“我要下线了”。服务中心接受到请求之后,将该服务置为下线状态。
失效剔除
有些时候,我们的服务提供方并不一定会正常下线,可能因为内存溢出、网络故障等原因导致服务无法正常工作。Eureka Server需要将这样的服务剔除出服务列表。因此它会开启一个定时任务,每隔60秒对所有失效的服务(超过90秒未响应)进行剔除。
可以通过eureka.server.eviction-interval-timer-in-ms
参数对其进行修改,单位是毫秒,生产环境不要修改。
这个会对我们开发带来极大的不变,你对服务重启,隔了60秒Eureka才反应过来。开发阶段可以适当调整,比如:10秒
自我保护
我们关停一个服务,就会在Eureka面板看到一条警告:
这是触发了Eureka的自我保护机制。当一个服务未按时进行心跳续约时,Eureka会统计最近15分钟心跳失败的服务实例的比例是否超过了85%。在生产环境下,因为网络延迟等原因,心跳失败实例的比例很有可能超标,但是此时就把服务剔除列表并不妥当,因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来,不予剔除。生产环境下这很有效,保证了大多数服务依然可用。
但是这给我们的开发带来了麻烦, 因此开发阶段我们都会关闭自我保护模式:(gzgs-eureka)
eureka:
server:
enable-self-preservation: false # 关闭自我保护模式(缺省为打开)
eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间(缺省为60*1000ms)
2.4 负载均衡Ribbon
当我们同一功能的服务提供方有两个的时候,这种情况下当我们访问服务提供方的时候就有两个选择,那么具体选用那一个提供方就可以通过Ribbon负载均衡来实现,它可以避免某一服务方请求过多而另一个服务方闲暇的情况。
2.4.1 开启两个服务提供方
然后修改配置文件端口即可
2.4.2 开启负载均衡
因为Eureka中已经集成了Ribbon,所以我们无需引入新的依赖,直接修改代码。
修改gzgs-service-consumer的引导类,在RestTemplate的配置方法上添加@LoadBalanced
注解:
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
修改调用方式,不再手动获取ip和端口,而是直接通过服务名称调用:
@Controller
@RequestMapping("consumer/user")
public class UserController {
@Autowired
private RestTemplate restTemplate;
//@Autowired
//private DiscoveryClient discoveryClient; // 注入discoveryClient,通过该客户端获取服务列表
@GetMapping
@ResponseBody
public User queryUserById(@RequestParam("id") Long id){
// 通过client获取服务提供方的服务列表,这里我们只有一个
// ServiceInstance instance = discoveryClient.getInstances("service-provider").get(0);
String baseUrl = "http://service-provider/user/" + id;
User user = this.restTemplate.getForObject(baseUrl, User.class);
return user;
}
}
2.4.3 修改负载均衡策略
在服务消费方修改配置文件
service-provider:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
测试
@RunWith(SpringRunner.class)
@SpringBootTest(classes = GzgsServiceConsumerApplication.class)
public class LoadBalanceTest {
@Autowired
private RibbonLoadBalancerClient client;
@Test
public void testLoadBalance(){
for (int i = 0; i < 100; i++) {
ServiceInstance instance = this.client.choose("service-provider");
System.out.println(instance.getHost() + ":" +instance.getPort());
}
}
}
2.5 Hystrix熔断机制
Hystrix,英文意思是豪猪,全身是刺,看起来就不好惹,是一种保护机制。
Hystrix也是Netflix公司的一款组件。
2.5.1 Hystrix的作用
Hystix是Netflix开源的一个延迟和容错库,用于隔离访问远程服务、第三方库,防止出现级联失败。,相当于家庭电路里面的保险丝,当电路发生短路的时候会自动关闭电路,以免发生灾难,Hystrix的作用也是如此,用于解决系统的雪崩问题。
2.5.2 什么是系统雪崩?
如上图,一个用户请求需要依赖A、H、I、P四个业务,当业务I的系统发生故障的时候,整个系统就会进入阻塞状态,随着请求的增多,最终系统会扛不住压力造成雪崩效应,这就是系统的雪崩问题。
Hystix解决雪崩问题的手段有两个:线程隔离和服务熔断。
2.5.3 线程隔离,服务降级
线程隔离的原理图如下,
Hystrix为每个依赖服务调用分配一个小的线程池,如果线程池已满调用将被立即拒绝,默认不采用排队.加速失败判定时间。
用户的请求将不再直接访问服务,而是通过线程池中的空闲线程来访问服务,如果线程池已满,或者请求超时,则会进行降级处理,什么是服务降级?
服务降级:优先保证核心服务,而非核心服务不可用或弱可用。
用户的请求故障时,不会被阻塞,更不会无休止的等待或者看到系统崩溃,至少可以看到一个执行结果(例如返回友好的提示信息) 。
服务降级虽然会导致请求失败,但是不会导致阻塞,而且最多会影响这个依赖服务对应的线程池中的资源,对其它服务没有响应。
触发Hystix服务降级的情况:
- 线程池已满
- 请求超时
2.5.3.1 动手实践
1)、引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
2)、在项目引导类上开启熔断
//以下三个注解可以使用@SpringCloudApplication来代替
@SpringBootApplication
@EnableDiscoveryClient//开启eureka客户端功能
@EnableCircuitBreaker //开启熔断机制
@EnableFeignClients//开启fegin客户端功能
public class GzsgServiceConsumerApplication {
@Bean
@LoadBalanced //开启负载均衡
public RestTemplate restTemplate(){
return new RestTemplate();
}
public static void main(String[] args) {
SpringApplication.run(GzsgServiceConsumerApplication.class, args);
}
}
3)、编写熔断逻辑
@Controller
@RequestMapping("consumer/user")
@DefaultProperties(defaultFallback ="fallbachMethod")
public class UserController {
@Autowired
private UserClient userClient;
@GetMapping
@ResponseBody
@HystrixCommand//标记该方法需要熔断
public String queryUserById(@RequestParam("id") Integer id){
String user = this.userClient.queryById(id);
return user;
}
public String fallbachMethod(){
return "服务器正忙,请稍后再试!";
}
}
要注意,因为熔断的降级逻辑方法必须跟正常逻辑方法保证:相同的参数列表和返回值声明。失败逻辑中返回User对象没有太大意义,一般会返回友好提示。所以我们把queryById的方法改造为返回String,反正也是Json数据。这样失败逻辑中返回一个错误说明,会比较方便。
2.5.3.2 设置超时时间
在之前的案例中,请求在超过1秒后都会返回错误信息,这是因为Hystix的默认超时时长为1,我们可以通过配置修改这个值:
我们可以通过hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds
来设置Hystrix超时时间。该配置没有提示。
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms
修改代码,模仿熔断
@GetMapping("{id}")
public User queryUserById(@PathVariable("id") Long id) {
try {
Thread.sleep(6000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return this.userService.queryUserById(id);
}
2.5.4 服务熔断
熔断器,也叫断路器,其英文单词为:Circuit Breaker
熔断状态机3个状态:
- Closed:关闭状态,所有请求都正常访问。
- Open:打开状态,所有请求都会被降级。Hystix会对请求情况计数,当一定时间内失败请求百分比达到阈值,则触发熔断,断路器会完全打开。默认失败比例的阈值是50%,请求次数最少不低于20次。
- Half Open:半开状态,open状态不是永久的,打开后会进入休眠时间(默认是5S)。随后断路器会自动进入半开状态。此时会释放部分请求通过,若这些请求都是健康的,则会完全关闭断路器,否则继续保持打开,再次进行休眠计时
2.5.4.1 服务熔断示例
修改consumer中的代码
@GetMapping("{id}")
@HystrixCommand
public String queryUserById(@PathVariable("id") Long id){
if(id == 1){
throw new RuntimeException("太忙了");
}
String user = this.restTemplate.getForObject("http://service-provider/user/" + id, String.class);
return user;
}
当我们疯狂访问id为1的请求时(超过20次),就会触发熔断。断路器会断开,一切请求都会被降级处理。
此时你访问id为2的请求,会发现返回的也是失败,而且失败时间很短,只有几毫秒左右:
不过,默认的熔断触发要求较高,休眠时间窗较短,为了测试方便,我们可以通过配置修改熔断策略:
circuitBreaker.requestVolumeThreshold=10
circuitBreaker.sleepWindowInMilliseconds=10000
circuitBreaker.errorThresholdPercentage=50
解读:
- requestVolumeThreshold:触发熔断的最小请求次数,默认20
- errorThresholdPercentage:触发熔断的失败请求最小占比,默认50%
- sleepWindowInMilliseconds:休眠时长,默认是5000毫秒
2.5.5 Fegin远程调用
2.5.5.1 什么是fegin?
fegin的调用需要在消费方修改
2.5.5.2 引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
2.5.5.3 开启fegin功能
我们在启动类上,添加注解,开启Feign功能
@SpringCloudApplication
@EnableFeignClients // 开启feign客户端
public class ItcastServiceConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ItcastServiceConsumerApplication.class, args);
}
}
删除RestTemplate:feign已经自动集成了Ribbon负载均衡的RestTemplate。所以,此处不需要再注册RestTemplate。
2.5.5.4 定义远程调用接口
UserClient接口
@FeignClient(value = "service-provider") // 标注该类是一个feign接口
public interface UserClient {
@GetMapping("user/{id}")
User queryById(@PathVariable("id") Long id);
}
- 首先这是一个接口,Feign会通过动态代理,帮我们生成实现类。这点跟mybatis的mapper很像
-
@FeignClient
,声明这是一个Feign客户端,类似@Mapper
注解。同时通过value
属性指定服务名称 - 接口中的定义方法,完全采用SpringMVC的注解,Feign会根据注解帮我们生成URL,并访问获取结果
修改UserController
@Controller
@RequestMapping("consumer/user")
public class UserController {
@Autowired
private UserClient userClient;
@GetMapping
@ResponseBody
public User queryUserById(@RequestParam("id") Long id){
User user = this.userClient.queryUserById(id);
return user;
}
}
2.5.5.5 Fegin的负载均衡
Feign中本身已经集成了Ribbon依赖和自动配置,因此我们不需要额外引入依赖,也不需要再注册RestTemplate
对象。可以在配置文件中配置如下来定义负载均衡算法:
service-provider:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
2.5.5.6 Fegin的熔断
Feign默认也有对Hystrix的集成,只不过,默认情况下是关闭的。我们需要通过下面的参数来开启:(在gzgs-service-consumer工程添加配置内容)
feign:
hystrix:
enabled: true # 开启Feign的熔断功能
1)、定义UserClientFallback,实现刚才编写的UserClient,作为fallback的处理类
@Component
public class UserClientFallback implements UserClient {
@Override
public String queryById(Integer id) {
return "服务器正忙,请稍后!";
}
}
2)然后在UserFeignClient中,指定刚才编写的实现类
/**
* User远程调用deign接口
*/
@Component
@FeignClient(value = "service-provider",fallback = UserClientFallback.class)//表明该类是一个feign接口
public interface UserClient {
@GetMapping("user/{id}")
String queryById(@PathVariable("id") Integer id);
}
请求访问consumer即可。
2.5.6 Zuul网关
引入Zull之后的系统架构图
2.5.6.1 编写配置文件
server:
port: 10010 #服务端口
spring:
application:
name: api-gateway #指定服务名
2.5.6.2 项目引导类
@SpringBootApplication
@EnableDiscoveryClient//开启eureka客户端功能
@EnableZuulProxy //开启zuul网关功能
public class GzgsZuulApplication {
public static void main(String[] args) {
SpringApplication.run(GzgsZuulApplication.class, args);
}
}
2.5.6.3 定义映射规则
server:
port: 10010 #服务端口
spring:
application:
name: api-gateway #指定服务名
zuul:
routes:
service-provider: # 这里是路由id,随意写
path: /service-provider/** # 这里是映射路径
url: http://127.0.0.1:8081 # 映射路径对应的实际url地址
这样就将符合path
规则的一切请求,都代理到 url
参数指定的地址
如上将 /service-provider/**
开头的请求,代理到http://127.0.0.1:8081
在上面中,我们将对应的服务地址写死了,在实际开发中是不会这样的,应该根据从eureka中拉去服务列表进行动态路由才对。
2.5.6.4 面向服务的路由
1)、添加Eureka客户端依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
2)、添加Eureka配置,获取服务信息
eureka:
client:
registry-fetch-interval-seconds: 5 # 获取服务列表的周期:5s
service-url:
defaultZone: http://127.0.0.1:10086/eureka
3)、在项目引导类上开启eureka客户端功能
@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能
@EnableDiscoveryClient
public class ZuulDemoApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulDemoApplication.class, args);
}
}
4)、修改映射规则
zuul:
routes:
service-provider: # 这里是路由id,随意写
path: /service-provider/** # 这里是映射路径
serviceId: service-provider # 指定服务名称
5)、简化映射规则配置
zuul:
routes:
service-provider: /service-provider/** # 这里是映射路径
在使用Zuul的过程中,上面讲述的规则已经大大的简化了配置项。但是当服务较多时,配置也是比较繁琐的。因此Zuul就指定了默认的路由规则:
- 默认情况下,一切服务的映射路径就是服务名本身。例如服务名为:
service-provider
,则默认的映射路径就 是:/service-provider/**
也就是说,刚才的映射规则我们完全不配置也是OK的。
2.5.6.5 路由前缀
zuul:
routes:
service-provider: /service-provider/**
service-consumer: /service-consumer/**
prefix: /api # 添加路由前缀
我们通过zuul.prefix=/api
来指定了路由的前缀,这样在发起请求时,路径就要以/api开头。
2.5.6.6 过滤器
Zuul作为网关的其中一个重要功能,就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。
ZuulFilter
ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法:
public abstract ZuulFilter implements IZuulFilter{
abstract public String filterType();
abstract public int filterOrder();
boolean shouldFilter();// 来自IZuulFilter
Object run() throws ZuulException;// IZuulFilter
}
-
shouldFilter
:返回一个Boolean
值,判断该过滤器是否需要执行。返回true执行,返回false不执行。 -
run
:过滤器的具体业务逻辑。 filterType
:返回字符串,代表过滤器的类型。包含以下4种:
-
pre
:请求在被路由之前执行 -
route
:在路由请求时调用 -
post
:在route和errror过滤器之后调用 -
error
:处理请求时发生错误调用
-
filterOrder
:通过返回的int值来定义过滤器的执行顺序,数字越小优先级越高。
这张是Zuul官网提供的请求生命周期图,清晰的表现了一个请求在各个过滤器的执行顺序。
2.5.6.7 自定义过滤器
@Component
public class LoginFilter extends ZuulFilter {
/**
* 过滤器类型,前置过滤器
* @return
*/
@Override
public String filterType() {
return "pre";
}
/**
* 过滤器的执行顺序
* @return
*/
@Override
public int filterOrder() {
return 10;
}
/**
* 该过滤器是否生效
* @return
*/
@Override
public boolean shouldFilter() {
return true;
}
/**
* 登陆校验逻辑
* @return
* @throws ZuulException
*/
@Override
public Object run() throws ZuulException {
//获取zuul上下文对象
RequestContext context = RequestContext.getCurrentContext();
//上下文对象获取请求对象
HttpServletRequest request = context.getRequest();
// 获取token信息
String token = request.getParameter("access-token");
// 判断
if (StringUtils.isBlank(token)) {
// 过滤该请求,不对其进行路由
context.setSendZuulResponse(false);
// 设置响应状态码,401
context.setResponseStatusCode(HttpStatus.SC_UNAUTHORIZED);
// 设置响应信息
context.setResponseBody("{\"status\":\"401\", \"text\":\"request error!\"}");
}
// 校验通过,把登陆信息放入上下文信息,继续向后执行
context.set("token", token);
return null;
}
}
2.5.6.8 Zull的负载均衡和熔断
Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值,比如熔断超时时间只有1S,很容易就触发了。因此建议我们手动进行配置:
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 2000 # 设置hystrix的超时时间为6000ms