使用了Ribbon的负载均衡功能,大大简化了远程调用时的代码,你可能以后需要编写类似的大量重复代码,格式基本相同,无非参数不一样。有没有更优雅的方式,来对这些代码再次优化呢?
Feign也叫伪装:
Feign可以把Rest的请求进行隐藏,伪装成类似SpringMVC的Controller一样。你不用再自己拼接url,拼接参数等等操作,一切都交给Feign去做。
项目主页:https://github.com/OpenFeign/feign
目标:Feign的作用;使用Feign实现consumer-demo代码中调用服务
解析:
总结:
Feign主要作用:自动根据参数拼接http请求地址。
启动器依赖;
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-openfeignartifactId>
dependency>
Feign客户端接口类:
//声明当前类是一个Feign客户端,指定服务名为user-service
@FeignClient("user-service")
public interface UserClient {
//http://user-service/user/123
@GetMapping("/user/{id}")
User queryById(@PathVariable("id") Long id);
}
/user
,请不要忘记;因为Feign需要拼接可访问的地址注意:Feign客户端接口类方法形参的@PathVariable("id")必须指定值,否则可能报错,无法通过编译
开启Feign功能
在 ConsumerApplication 启动类
上,添加注解,开启Feign功能
@EnableFeignClients//开启Feign功能
Feign中已经自动集成了Ribbon负载均衡,因此不需要自己定义RestTemplate进行负载均衡的配置
目标:可以配置Feign内置ribbon配置项和Hystrix熔断的Fallback配置
分析:
都可以通过配置项在Feign中开启使用。
总结:
负载均衡
Feign中本身已经集成了Ribbon依赖和自动配置,因此不需要额外引入依赖,也不需要再注册 RestTemplate 对象。
Fegin内置的ribbon默认设置了请求超时时长,默认是1000
,我们可以通过手动配置来修改这个超时时长,因为ribbon内部有重试机制,一旦超时,会自动重新发起请求。如果不希望重试,可以添加配置:
ribbon:
ConnectTimeout: 1000 # 连接超时时长
ReadTimeout: 2000 # 数据通信超时时长
MaxAutoRetries: 0 # 当前服务器的重试次数
MaxAutoRetriesNextServer: 0 # 重试多少次服务
OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试
服务熔断
Feign默认也有对Hystrix的集成,只不过,默认情况下是关闭的。需要通过下面的参数来开启;
feign:
hystrix:
enabled: true # 开启Feign的熔断功能
但是,Feign中的Fallback配置不像Ribbon中那样简单了
1. 首先,要定义一个类,实现Feign客户端接口类
,作为fallback的处理类,编写错误信息
package com.heima.consumer.client.fallback;
import com.heima.consumer.client.UserClient;
import com.heima.consumer.pojo.User;
import org.springframework.stereotype.Component;
/**
* @author 嘿嘿嘿1212
* @version 1.0
* @date 2019/11/3 13:47
*/
@Component
public class UserClientFallback implements UserClient {
@Override
public User queryById(Long id) {
User user = new User();
user.setId(id);
user.setName("用户异常");
return user;
}
}
然后在Feign客户端接口类
中,指定刚才编写的实现类
/**
* @author 嘿嘿嘿1212
* @version 1.0
* @date 2019/11/3 11:49
*/
@FeignClient(value="user-service",fallback = UserClientFallback.class)
public interface UserClient {
/**
* 根据id查询id
* @param id 用户id
* @return 用户
*/
@GetMapping("/user/{id}")
User queryById(@PathVariable("id") Long id);
}
重启测试
请求压缩
Spring Cloud Feign 支持对请求和响应进行GZIP压缩,以减少通信过程中的性能损耗。通过下面的参数即可开启请求与响应的压缩功能,我们也可以对请求的数据类型,以及触发压缩的大小下限进行设置:
feign:
compression:
request:
enabled: true # 开启请求压缩
mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
min-request-size: 2048 # 设置触发压缩的大小下限
response:
enabled: true
注:上面的数据类型、压缩大小下限均为默认值
日志级别
前面讲过,通过 logging.level.xx=debug 来设置日志级别。然而这个对Fegin客户端而言不会产生效果。因为@FeignClient 注解修改的客户端在被代理时,都会创建一个新的Fegin.Logger实例。我们需要额外指定这个日志的级别才可以。
配置日志级别,例如:
logging:
level:
com.itheima: debug
编写FeignConfig配置类
,定义日志级别
/**
* @author 嘿嘿嘿1212
* @version 1.0
* @date 2019/11/3 14:08
*/
@Configuration
public class FeignConfig {
@Bean
Logger.Level feignLoggerLevel() {
return Logger.Level.FULL;
}
}
Feign客户端接口类
上的@FeignClient
注解中指定配置类:
@FeignClient(value = "user-service", fallback = UserClientFallback.class,
configuration = FeignConfig.class)
在服务消费工程consumer-demo中的配置文件:
ribbon:
ConnectTimeout: 1000 # 连接超时时长
ReadTimeout: 2000 # 数据通信超时时长
MaxAutoRetries: 0 # 当前服务器的重试次数
MaxAutoRetriesNextServer: 0 # 重试多少次服务
OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试
feign:
hystrix:
enabled: true # 开启Feign的熔断功能
compression:
request:
enabled: true # 开启请求压缩
mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
min-request-size: 2048 # 设置触发压缩的大小下限
response:
enabled: true
logging:
level:
com.itheima: debug
Spring Cloud Gateway组件的核心是一系列的过滤器,通过这些过滤器可以将客户端发送的请求转发(路由)到对应的微服务。 Spring Cloud Gateway是加在整个微服务最前沿的防火墙和代理器,隐藏微服务结点IP端口信息,从而加强安全保护。Spring Cloud Gateway本身也是一个微服务,需要注册到Eureka服务注册中心。
学习目标:Spring Cloud Gateway网关的作用
总结:
Spring Cloud Gateway的核心就是一系列的过滤器,可以将客户端的请求转发到不同的微服务。主要作用:过滤和路由。安全校验
学习目标:搭建网关服务工程测试网关服务作用
解析:
需求:通过网关系统heima-gateway将包含有 /user 的请求 路由到 http://127.0.0.1:9091/user/用户id
实现步骤:
http://127.0.0.1:10010/user/8 --> http://127.0.0.1:9091/user/8
总结:
引导类添加注解(用于eureka发现服务)
@EnableDiscoveryClient
启动器依赖
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-gatewayartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
dependencies>
配置文件
server:
port: 10010
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
# 路由id,可以任意
- id: user-service-route
# 代理的服务地址
uri: http://127.0.0.1:9091
# 路由断言: 可以匹配映射路径
predicates:
- Path=/user/**
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
prefer-ip-address: true
将符合 Path 规则的一切请求,都代理到 uri 参数指定的地址
本例中,我们将路径中包含有 /user/** 开头的请求,代理到http://127.0.0.1:9091
在刚才的路由规则中,把路径对应的服务地址写死了!如果同一服务有多个实例的话,这样做显然不合理。
应该根据服务的名称,去Eureka注册中心查找 服务对应的所有实例列表,然后进行动态路由!
因为已经配置了Eureka客户端,可以从Eureka获取服务的地址信息。
路由配置中uri所用的协议为lb时(以uri: lb://user-service为例),gateway将使用 LoadBalancerClient把
user-service通过eureka解析为实际的主机和端口,并进行ribbon负载均衡。
学习目标:使用在eureka注册的服务作为路由地址
解析:
如果将路由服务地址写死明显是不合理的;在Spring Cloud Gateway中可以通过配置动态路由解决。
总结:
面向服务的路由;只需要在配置文件中指定路由路径类似: lb://user-service
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
# 路由ID,可以任意
- id: user-service-route
# 代理的服务名
uri: lb://user-service
#路由断言
predicates:
- Path=/user/**
lb 之后编写的服务名必须要在eureka中注册才能使用
底层是使用ribbon负载均衡实现
目标:可以对请求到网关服务的地址添加或去除前缀
分析:
提供服务的地址:http://127.0.0.1:9091/user/8
添加前缀:对请求地址添加前缀路径之后再作为代理的服务地址;
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
# 路由ID,可以任意
- id: user-service-route
# 代理的服务地址
uri: lb://user-service
#路由断言
predicates:
#- Path=/user/**
- Path=/**
filters:
#添加请求路径的前缀
- PrefixPath=/user
http://127.0.0.1:10010/8 --> http://127.0.0.1:9091/user/8 添加前缀路径/user
去除前缀:将请求地址中路径去除一些前缀路径之后再作为代理的服务地址;
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
# 路由ID,可以任意
- id: user-service-route
# 代理的服务地址
uri: lb://user-service
#路由断言
predicates:
#- Path=/user/**
- Path=/api/user/**
filters:
# 表示过滤1个路径,2表示俩个路径,以此类推
- StripPrefix=1
http://127.0.0.1:10010/api/user/8 --> http://127.0.0.1:9091/user/8 去除前缀路径/api
总结:
客户端的请求地址与微服务的服务地址如果不一致的时候,可以通过配置路径过滤器实现路径前缀的添加和去除。
Gateway作为网关的其中一个重要功能,就是实现请求的鉴权。而这个动作往往是通过网关提供的过滤器来实现的。前面的 路由前缀 章节中的功能也是使用过滤器实现的。
Gateway自带过滤器有几十个,详细的说明在官网链接
spring:
application:
name: api-gateway
cloud:
gateway:
default-filters: # 响应头过滤器,对输出的响应设置其头部属性名称为X-Response-Default-MyName,值为itcast;如果有多个参数多则重写一行设置不同的参数
- AddResponseHeader=X-Response-Default-MyName, itcast
过滤器类型:Gateway实现方式上,有两种过滤器
spring.cloud.gateway.default-filters
上会对所有路由生效也算是全局的过滤器;但是这些过滤器的实现上都是要实现GatewayFilterFactory
接口。GlobalFilter
接口即可。Spring Cloud Gateway 的 Filter 的生命周期也类似Spring MVC的拦截器有两个:“pre” 和 “post”。“pre”和 “post” 分别会在请求被执行前调用和被执行后调用。
pre 和 post 可以通过过滤器的 GatewayFilterChain 执行filter方法前后来实现。
学习目标:Gateway默认过滤器的用法和过滤器类型
总结:
目标:按照默认过滤器编写并配置一个自定义局部过滤器,该过滤器可以通过配置文件中的参数名称获取请求的参数值
分析:
需求:在过滤器(MyParamGatewayFilterFactory)中将http://localhost:10010/api/user/8?name=itcast中的参数name的值获取到并输出到控制台;并且参数名是可变的,也就是不一定每次都是name;需要可以通过配置过滤器的时候做到配置参数名。
实现步骤:
小结:
配置;与其他过滤器的配置一致。
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
# 路由ID,可以任意
- id: user-service-route
# 代理的服务地址
uri: lb://user-service
#路由断言
predicates:
#- Path=/user/**
- Path=/api/user/**
filters:
# 表示过滤1个路径,2表示俩个路径,以此类推
- StripPrefix=1
# 自定义过滤器
- MyParam=name
实现过滤器
package com.itheima.gateway.filter;
import org.springframework.cloud.gateway.filter.GatewayFilter;
import org.springframework.cloud.gateway.filter.factory.AbstractGatewayFilterFactory;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.stereotype.Component;
import java.util.Arrays;
import java.util.List;
//传入参数类
@Component
public class MyParamGatewayFilterFactory extends AbstractGatewayFilterFactory<MyParamGatewayFilterFactory.Config> {
//配置类中传入参数指定接收配置类内接收的变量
static final String PARAM_NAME = "param";
public MyParamGatewayFilterFactory() {
super(Config.class);
}
public List<String> shortcutFieldOrder() {
return Arrays.asList(PARAM_NAME);
}
@Override
public GatewayFilter apply(Config config) {
return (exchange, chain) -> {
// http://localhost:10010/api/user/8?name=itcast config.param ==> name
//获取请求参数中param对应的参数名 的参数值
ServerHttpRequest request = exchange.getRequest();
if(request.getQueryParams().containsKey(config.param)){
request.getQueryParams().get(config.param).
forEach(value -> System.out.printf("------------局部过滤器--------%s = %s------", config.param, value));
}
return chain.filter(exchange);
};
}
//定义参数类
public static class Config{
//对应在配置过滤器的时候指定的参数名
private String param;
public String getParam() {
return param;
}
public void setParam(String param) {
this.param = param;
}
}
}
学习目标:定义一个全局过滤器检查请求中是否携带有token参数
解析:
需求:编写全局过滤器,在过滤器中检查请求地址是否携带token参数。如果token参数的值存在则放行;如果token的参数值为空或者不存在则设置返回的状态码为:未授权也不再执行下去。
实现步骤:
总结:
@Component
public class MyGlobalFilter implements GlobalFilter, Ordered {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
System.out.println("--------------全局过滤器MyGlobalFilter------------------");
String token = exchange.getRequest().getQueryParams().getFirst("token");
if(StringUtils.isBlank(token)){
//设置响应状态码为未授权
exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
return exchange.getResponse().setComplete();
}
return chain.filter(exchange);
}
@Override
public int getOrder() {
//值越小越先执行
return 1;
}
}
Gateway中默认就已经集成了Ribbon负载均衡和Hystrix熔断机制。但是所有的超时策略都是走的默认值,比如熔断超时时间只有1S,很容易就触发了。因此建议手动进行配置
一般网关都是所有微服务的统一入口,必然在被调用的时候会出现跨域问题。
跨域:在js请求访问中,如果访问的地址与当前服务器的域名、ip或者端口号不一致则称为跨域请求。若不解决则不能获取到对应地址的返回结果。
如:从在http://localhost:9090中的js访问 http://localhost:9000的数据,因为端口不同,所以也是跨域请求。
启动多个Gateway服务,自动注册到Eureka,形成集群。如果是服务内部访问,访问Gateway,自动负载均衡,没问题。
但是,Gateway更多是外部访问,PC端、移动端等。它们无法通过Eureka进行负载均衡,那么该怎么办?
此时,可以使用其它的服务网关,来对Gateway进行代理。比如:Nginx
学习目标:Gateway网关的负载均衡和熔断参数配置
总结:
网关服务配置文件:
server:
port: 10010
spring:
application:
name: api-gateway
cloud:
gateway:
routes:
# 路由id,可以任意
- id: user-service-route
# 代理的服务地址
#uri: http://127.0.0.1:9091
# lb表示从eureka中获取具体服务
uri: lb://user-service
# 路由断言: 可以匹配映射路径
predicates:
#- Path=/user/**
#- Path=/**
- Path=/api/user/**
filters:
# 添加请求路径的前缀
#- PrefixPath=/user
#1表示过滤1个路径,2表示两个路径,以此类推
- StripPrefix=1
- MyParam=name
# 默认过滤器,对所有路由都生效
default-filters:
- AddResponseHeader=X-Response-Foo, Bar
- AddResponseHeader=abc-myname,heima
# 进行跨域请求处理,指定请求的域名http://docs.spring.io与方式GET
globalcors:
corsConfigurations:
'[/**]':
#allowedOrigins: * # 这种写法或者下面的都可以,*表示全部
allowedOrigins:
- "http://docs.spring.io"
allowedMethods:
- GET
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
instance:
prefer-ip-address: true
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 6000
ribbon:
ConnectTimeout: 1000
ReadTimeout: 2000
MaxAutoRetries: 0
MaxAutoRetriesNextServer: 0
上述
globalcors:
下配置表示:可以允许来自http://docs.spring.io
的get请求方式获取服务数据。
allowedOrigins
指定允许访问的服务器地址,如:http://localhost:10000
也是可以的。
‘[/**]’ 表示对所有访问到网关服务器的请求地址
官网具体说明:https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.1.1.RELEASE/multi/multi__cors_configuration.html
Gateway网关一般直接给终端请求使用;Feign一般用在微服务之间调用。
在分布式系统中,由于服务数量非常多,配置文件分散在不同的微服务项目中,管理不方便。为了方便配置文件集中管理,需要分布式配置中心组件。在Spring Cloud中,提供了Spring Cloud Config,它支持配置文件放在配置服务的本地,也支持放在远程Git仓库(GitHub、码云)。
学习目标:分布式配置中心的作用
spring cloud config作用:可以通过修改在git仓库中的配置文件实现其它所有微服务的配置文件的修改。
目标:创建码云的远程公开git仓库,搭建配置中心微服务config-server
分析:
创建git仓库:在码云上创建仓库
application为应用名称
profile用于区分开发环境,测试环境、生产环境等
搭建配置中心config-server:使用spring boot方式搭建和配置
小结:
<dependencies>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-config-serverartifactId>
dependency>
dependencies>
server:
port: 12000
spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: https://gitee.com/goheima/heima-config.git
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
需要在启动引导类中添加@EnableConfigServer
开启配置服务
可以在uri
后配置username
与password
进行私仓的连接
在gitee中修改了配置文件会在配置中心服务及时更新。
学习目标:改造用户微服务user-service,配置文件信息不再由微服务项目提供,而是从配置中心获取
解析:
需求:将服务提供工程user-service的application.yml配置文件删除,修改为从配置中心config-server中获取。
实现步骤:
小结:
将原来的application.yml删除;然后添加bootstrap.yml配置文件,该文件也是spring boot的默认配置文件,其内容经常配置一些项目中固定的配置项。如果是项目经常变动的应该配置到application.yml中,现在使用了配置中心则应该配置到git仓库中对于的配置文件。
依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-configartifactId>
<version>2.1.1.RELEASEversion>
dependency>
配置文件bootstrap.yml
spring:
cloud:
config:
# 要与仓库中的配置文件的application保持一致
name: user
# 要与仓库中的配置文件的profile保持一致
profile: dev
# 要与仓库中的配置文件所属的版本(分支)一样
label: master
discovery:
# 使用配置中心
enabled: true
# 配置中心服务名
service-id: config-server
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
bootstrap.yml文件也是Spring Boot的默认配置文件,而且其加载的时间相比于application.yml更早。
application.yml和bootstrap.yml虽然都是Spring Boot的默认配置文件,但是定位却不相同。bootstrap.yml
可以理解成系统级别的一些参数配置,这些参数一般是不会变动的。application.yml 可以用来定义应用级别的参数,如果搭配 spring cloud config 使用,application.yml 里面定义的文件可以实现动态替换。
总结就是,bootstrap.yml文件相当于项目启动时的引导文件,内容相对固定。application.yml文件是微服务
的一些常规配置参数,变化比较频繁。
前面已经完成了将微服务中的配置文件集中存储在远程Git仓库,并且通过配置中心微服务从Git仓库拉取配置文件,当用户微服务启动时会连接配置中心获取配置信息从而启动用户微服务。
如果我们更新Git仓库中的配置文件,那用户微服务是否可以及时接收到新的配置信息并更新呢?
问题是不能.
如果想在不重启微服务的情况下更新配置该如何实现呢? 可以使用Spring Cloud Bus来实现配置的自动更新。
需要注意的是Spring Cloud Bus底层是基于RabbitMQ实现的,默认使用本地的消息队列服务,所以需要提前
启动本地RabbitMQ服务(安装RabbitMQ以后才有)
Spring Cloud Bus是用轻量的消息代理将分布式的节点连接起来,可以用于广播配置文件的更改或者服务的监控管理。也就是消息总线可以为微服务做监控,也可以实现应用程序之间相互通信。Spring Cloud Bus可选的消息代理有RabbitMQ和Kafka。
使用了Bus之后:
学习目标:了解Spring Cloud Bus作用
总结:
Spring Cloud Bus作用:将git仓库的配置文件更新,在不重启系统的情况下实现及时同步到各个微服务。
学习目标:启动RabbitMQ通过修改码云中的配置文件后发送Post请求实现及时更新用户微服务中的配置项
解析:
需求:在码云的git仓库中修改user-dev.yml配置文件,实现不重启user-service的情况下可以及时更新配置文件。
实现步骤:
总结:
config-server(配置中心)的依赖添加内容
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-busartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-stream-binder-rabbitartifactId>
dependency>
config-server(配置中心)的配置文件添加内容
server:
port: 12000
spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: https://gitee.com/goheima/heima-config.git
# 配置rabbitmq信息;如果是都与默认值一致则不需要配置
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
management:
endpoints:
web:
exposure:
# 暴露触发消息总线的地址
include: bus-refresh
user-service(用户服务)的依赖添加内容
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-busartifactId>
dependency>
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-stream-binder-rabbitartifactId>
dependency>
<dependency>
<groupId>org.springframework.bootgroupId>
<artifactId>spring-boot-starter-actuatorartifactId>
dependency>
user-service(用户服务)的配置文件添加内容
# 配置rabbitmq信息;如果是都与默认值一致则不需要配置
rabbitmq:
host: localhost
port: 5672
username: guest
password: guest
UserController(用户服务)的修改
测试步骤:
第一步:依次启动注册中心 eureka-server 、配置中心 config-server 、用户服务 user-service
第二步:访问用户微服务http://localhost:9091/user/8;查看IDEA控制台输出结果
第三步:修改Git仓库中配置文件 user-dev.yml 的 test.name 内容
第四步:使用Postman或者RESTClient工具发送POST方式请求访问地址http://127.0.0.1:12000/actuator/bus-refresh
第五步:访问用户微服务系统控制台查看输出结果,如何于修改后内容一致则成功,反之失败
学习目标:了解Spring Cloud中的Eureka、GateWay、Config、Bus、Feign等技术的综合应用
总结: