上一篇介绍了SpringCloud(一):
- https://www.jianshu.com/p/dac81a7bde30
- https://www.jianshu.com/p/de3c5f0806f3
Feign
Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样，不用再自己拼接url,拼接参数等操作
快速入门
导入依赖
org.springframework.cloud
spring-cloud-starter-openfeign
Feign的客户端
@FeignClient("user-service")
public interface UserClient {
@GetMapping("/user/{id}")
User queryById(@PathVariable("id") Long id);
}
- 首先这是一个接口,Feign会通过动态代理，帮我们生成实现类。
- @FeignClient 声明这是一个Feign客户端，同时通过value属性指定服务名称
- 接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果
改造原来的调用逻辑，使用UserClient访问：
@RestController
@RequestMapping("consumer")
@Slf4j
public class ConsumerController {
@Autowired
private RestTemplate restTemplate;
@Autowired
private DiscoveryClient discoveryClient;
@Autowired
private UserClient userClient;
@GetMapping("{id}")
@HystrixCommand
public User queyById(@PathVariable("id") Long id) {
return userClient.queryById(id);
}
}
开启Feign功能
我们在启动类上，添加注解，开启Feign功能
@SpringCloudApplication
@EnableFeignClients//开启Feign功能呢个
public class ConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsumerApplication.class, args);
}
}
- Feign中已经自动集成了Ribbon负载均衡，我们在这里不需要自己定义RestTemplate了
启动测试
负载均衡
Feign中本身已经集成了Ribbon依赖和自动配置
我们使用Feign不需要额外引入依赖
Feign内置的ribbon默认设置了请求超时时长，默认是1000ms，我们可以通过手动配置来修改这个超时时长
ribbon:
ReadTimeout: 2000 # 读取超时时长
ConnectTimeout: 1000 # 建立链接的超时时长
ribbon内部由重试机制，一旦超时，会自动重新发起请求，如果希望关闭重试，可以添加配置
ribbon:
ReadTimeout: 2000 # 数据通信超时时长
ConnectTimeout: 500 # 连接超时时长
MaxAutoRetries: 0 # 当前服务器的重试次数
MaxAutoRetriesNextServer: 1 # 重试多少次服务
OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试
Hystix支持
Feign默认也集成了Hystix，只不过默认情况下是关闭的，我们需要通过下面的参数来开启
feign:
hystrix:
enabled: true # 开启Feign的熔断功能
开启后，我们需要配置Fallback 降级逻辑，Feign的降级逻辑不像Hystrix中那样简单了
- 首先，我们定义一个类，实现刚才编写的UserFeignClient 作为fallback的处理类
@Component
public class UserClientFallBack implements UserClient {
@Override
public User queryById(Long id) {
User user = new User();
user.setId(id);
user.setName("用户查询异常");
return user;
}
}
- 然后在UserFeignClient中，指定刚才编写的实现类
@FeignClient(value = "user-service",fallback = UserClientFallBack.class)
public interface UserClient {
@GetMapping("/user/{id}")
User queryById(@PathVariable("id") Long id);
}
-
重启测试
我们关闭user-service 查看页面的服务降级
image.png
请求压缩
SpringCloud Feign支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。通过下面的参数即可开启请求与响应的压缩功能
feign:
hystrix:
enabled: true # 开启Feign的熔断功能
compression:
request:
enabled: true # 开启请求压缩
response:
enabled: true # 开启响应压缩
同时，我们也可以对请求的数据类型，以及处罚压缩的大小下限进行设置：
feign:
hystrix:
enabled: true # 开启Feign的熔断功能
compression:
request:
enabled: true # 开启请求压缩
mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
min-request-size: 2048 # 设置触发压缩的大小下限
日志级别
@FeignClient注解修改的客户端在被代理时，都会创建一个新的Feign.Logger实例。我们需要额外指定这个日志的级别才可以
- 设置指定包名下的日志级别都为debug
logging:
level:
com.itheima: debug
- 编写配置类，定义日志级别
@Configuration
public class FeignConfig {
@Bean
Logger.Level feignLoggerLevel(){
return Logger.Level.FULL;
}
}
这里指定的Level级别是Full,Feign支持4种级别
- NONE：不记录任何日志信息，默认
- BASIC：仅记录请求的方法，URL以及相应状态码和执行时间
- HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
- FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据
- 在FeignClient中指定配置类：
@
FeignClient(value = "user-service", fallback = UserClientFallback.class,
configuration = FeignConfig.class)
public interface UserClient {
@GetMapping("/user/{id}")
User queryById(@PathVariable("id") Long id);
}
Zuul网关
网关的核心功能呢个是：过滤(鉴权)和路由
Zuul加入后的架构
- 不管是来自于客户端(pc或移动端)的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现鉴权、动态路由等操作，Zuul就是我们服务的统一入口
快速入门
新建工程
添加依赖
org.springframework.cloud
spring-cloud-starter-netflix-zuul
编写启动类
@SpringBootApplication
@EnableZuulProxy //开启zuul网关功能
public class ZuulApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulApplication.class, args);
}
}
编写配置
server:
port: 10010
spring:
application:
name: api-gateway
编写路由规则
我们这里需要用zuul来代理user-service 我们可以看到Eureka的监控面板
- ip为 127.0.0.1
- 端口为：8081
映射规则：
zuul:
routes:
user-service:
path: /user-service/** #映射路径
url: http://127.0.0.1:8081 # 映射路径对应的实际url地址
启动测试
我们在访问的路径中加上配置规则的映射路径
http://127.0.0.1:10010/user-service/user/1
页面响应：
面向服务的路由
在上面的路由规则中，我们将路径对应的服务地址写死了。这样做不合理
我们应该根据服务的名称，去Eureka注册中心查找服务对应的所有实例列表，然后进行动态路由
添加Eureka客户端依赖
org.springframework.cloud
spring-cloud-starter-netflix-eureka-client
开启Eureka客户端发现
@SpringBootApplication
@EnableZuulProxy //开启zuul网关功能
@EnableDiscoveryClient //开启Eureka客户端发现
public class ZuulApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulApplication.class, args);
}
}
添加Eureka配置，获取服务信息
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
修改zuul映射配置，通过服务名称获取
zuul:
routes:
user-service:
path: /user-service/** #映射路径
serviceId: user-service # 指定服务名称
启动测试
简化的路由配置
在刚才的配置中，我们配置的规则是：
- zuul.routes.
.path=/xxx/**：来指定映射路径。 - zuul.routes.
.serviceId=/user-service 来指定服务名
在大多数情况下 我们的路由名称往往和服务名会写成一样的。因此zuul提供了一种简化的配置语法： zuul.routes. =
我们简化上面的配置
zuul:
routes:
# 简化写法
user-service: /user-service/** #指定映射路径
这样可以省去对服务名称的配置
默认路由规则
- 默认情况下，一切服务的映射路径就是服务名本身
- 例如服务名为:user-service 则默认的映射路径就是/user-service/**
也就是说，刚才的映射规则我们完全不配置也是可以的
如果想要禁用某个路由规则，则可以
- 例如服务名为:user-service 则默认的映射路径就是/user-service/**
zuul:
ignored-services:
- eureka-server
路由前缀
配置实例
zuul:
# 禁用某个路由规则
ignored-services:
- eureka-server
prefix: /api #添加路由前缀
routes:
user-service: /user-service/** # 指定映射路径
我们通过zuul.prefix=/api来指定了路由的前缀，这样在发起请求时，路径就要以/api开头
按照上面的配置 /api/user-service/user/1 ===》/user-service/user/1
过滤器
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
}
- filterType：返回字符串，代表过滤器类型。包含以下4种：
- pre：请求在被路由之前执行
- route：在路由请求时调用
- post：在routing和error过滤器之后调用
- error：处理请求时发生错误调用
- filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高
- shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行
- run：过滤器的具体业务逻辑
过滤器执行生命周期
官方执行流程图
- 正常流程
- 请求到达首先会经过pre类型过滤器，而后到达routing类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应
- 异常流程：
- 整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error处理完毕后，会将请求交给POST过滤器，最后返回给用户
- 如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回
- 如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的是，请求不会再到达POST过滤器了
过滤器的使用场景
- 请求鉴权：一般放在pre过滤器中，如果发现没有访问权限，直接就拦截了
- 异常处理：一般会在error类型和post类型过滤器中结合来处理
- 服务调用时长统计：pre和post结合使用
自定义过滤器
接下来我们来自定义一个过滤器，模拟一个登录的校验。基本逻辑：如果请求中有access-token参数则认为请求有效，放行
自定义过滤器类
@Component
@Slf4j
public class LoginFilter extends ZuulFilter {
@Override
public String filterType() {
log.info("filterType");
return FilterConstants.PRE_TYPE;
}
@Override
public int filterOrder() {
log.info("filterOrder");
return FilterConstants.PRE_DECORATION_FILTER_ORDER -1;
}
@Override
public boolean shouldFilter() {
log.info("shouldFilter");
return true;
}
@Override
public Object run() throws ZuulException {
//获取请求上下文
RequestContext ctx = RequestContext.getCurrentContext();
//获取request对象
HttpServletRequest request = ctx.getRequest();
//获取请求参数
String token = request.getParameter("access-token");
//判断token是否存在
if (StringUtils.isBlank(token)) {
//不存在未登录 进行拦截
ctx.setSendZuulResponse(false);
//设置返回状态码
ctx.setResponseStatusCode(HttpStatus.SC_UNAUTHORIZED);
}
return null;
}
}
测试
没有token参数时，访问失败
添加token后，正常访问
负载均衡和熔断
Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是默认的，因此建议我们手动进行配置
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 6000
ribbon:
ConnectTimeout: 1000
ReadTimeout: 2000
MaxAutoRetries: 0 # 自动重试设置0
MaxAutoRetriesNextServer: 1
Zuul的高
启动多个Zuul服务，自动注册到Eureka，形成集群。如果是服务内部访问，你访问Zuul，自动负载均衡。
但是，Zuul更多是外部访问，PC端、移动端等。他们无法通过Eureka进行负载均衡，那么该怎么办？
一般在这种情况下，我们会使用其它的服务网关，来对Zuul进行代理。如Nginx
bootstrap.yml和application.yml
bootstrap.yml用来程序引导时执行，应用于更加早起配置信息读取。
application.yml应用程序特有配置信息，可以用来配置后续各个模块中需使用的公共参数等
bootstrap.yml先于application.yml加载
从技术上来说，bootstrap.yml是被一个父级的Spring ApplicationContext加载的。
这个父级的Spring ApplicationContext加载的。
这个父级的Spring ApplicationContext是先加载的，在加载application.yml的ApplicationContext之前
可以通过设置 spring.cloud.bootstrap.enabled=false来禁用bootstrap
集中配置组件SpringCloudConfig
SpringCloudConfig简介
在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件Spring cloud config，它支持配置服务放在配置服务的内存中。也支持放在远程Git仓库中。在Spring cloud config组件中，分两个角色 一个是config server 二是config client
- Config Server 是一个可横向扩展、集中式的配置服务器，它用于集中管理用用程序各个环境下的配置，默认使用Git存储配置文件内容，也可以使用SVN存储，或者是本地文件存储
- Config Client 是Config Server的客户端，用于操作存储在Config Server中的配置内容，微服务在启动时会请求Config Server获取配置文件的内容
配置服务端
将配置文件提交到码云
- 注册一个码云(gitee.com)帐号，并登陆到管理控制台
- 创建仓库leyou-config
- 上传配置文件，将user_service工程的application.yml改名为item-dev.yml后上传
配置中心微服务
- 创建工程module ly-config
- 引入依赖
org.springframework.cloud
spring-cloud-config-server
org.springframework.boot
spring-boot-starter-actuator
- 创建启动类
@SpringBootApplication
@EnableConfigServer // 开启配置服务
public class ConfigServerApplication {
public static void main(String[] args) {
SpringApplication.run(ConfigServerApplication.class, args);
}
}
- 编写配置文件application.yml
spring:
application:
name: config-server
cloud:
config:
server:
git:
uri: https://gitee.com/probuing/leyou-config.git
server:
port: 12000
- 启动浏览器访问 http://localhost:12000/item-dev.yml 可以看到配置的内容
配置客户端
- 在user_service工程中添加配置依赖
org.springframework.cloud
spring-cloud-starter-config
- 在ly_item_service工程中添加bootstrap.yml 删除application.yml
spring:
cloud:
config:
name: item
profile: dev
label: master
uri: http://127.0.0.1:12000
消息总线组件SpringCloudBus
SpringCloudBus简介
SpringCloudBus可以实现配置的自动更新
配置服务端
- 修改ly_config的pom 引入依赖
org.springframework.cloud
spring-cloud-starter-bus-amqp
- 修改application.yml配置
spring:
rabbitmq:
host: 127.0.0.1
port: 5672
virtual-host: /leyou
username: leyou
password: leyou
management: #暴露触发消息总线的地址
endpoints:
web:
exposure:
include: bus-refresh
配置客户端
- 我们修改user_service工程，引入依赖
org.springframework.cloud
spring-cloud-starter-bus-amqp
- 在码云的配置文件中配置rabbitMQ的地址
spring:
rabbitmq:
host: 127.0.0.1
port: 5672
virtual-host: /leyou
username: leyou
password: leyou
（3）启动 注册中心、配置中心、服务提供方、消费方项目看是否正常运行
（4）修改码云上的配置文件 ，将数据库连接IP 改为127.0.0.1 ，在本地部署一份数据库。
（5）测试 Url: http://127.0.0.1:12000/actuator/bus-refresh Method: post