文章目录
继续接着上一篇的项目来整合Fegin,Hystrix,Rule。上一篇地址 https://blog.csdn.net/qq_36882793/article/details/96301559
项目地址: https://download.csdn.net/download/qq_36882793/11389879
一、Fegin 远程调用
（一）简介
Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做。
项目主页：https://github.com/OpenFeign/feign
即在之前的项目中，我们调用dirver服务是通过RestTesmplate来通过拼接url来实现服务调用，并不合适。通过Fegin我们可以简化这种操作。
（二）搭建
- 引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
-
在乘客服务启动类中添加 @EnableFeignClients 注解 启动Fegin客户端。另外@SpringBootApplication这里的注解换成了@SpringCloudApplication，这个注解集成了@SpringBootApplication、@EnableDiscoveryClient、@EnableCircuitBreaker 注解。
-
我们新建一个client文件夹，创建接口PassengerClient。在接口上添加注解@FeignClient 标志该类是一个fegin接口，value值是需要跳转的服务的服务名（即ApplicationName）。可以看到PassengerController中的callTaxi 方法调用的是eurake-dirver服务中的taskOrders方法，所以我们要在PassengerClient声明一个taskOrders 接口来代理该方法。
如下图所示，这里通过@RequestMappering 来指定调用的路径为eurake-driver服务的driver/taksOrders 路径。这里的taskOrders接口方法和 eurake-driver中的taskOrders方法在定义上在返回值相同，参数列表相同，
-
回到PassengerController 中，Fegin 中已经集成了RestTemplate, 所以无需我们自己再注入。也集成Ribbon负载均衡，并且默认启动了负载均衡。所以我们也不用引入和集成Ribbon包。这里注入PassengerClient，并通过他来调用司机的服务。
-
测试调用：
二、开启Hystrix熔断功能
（一）简介：
Hystrix,英文意思是豪猪，全身是刺，看起来就不好惹，是一种保护机制。
Hystrix也是Netflix公司的一款组件。
主页：https://github.com/Netflix/Hystrix/
熔断状态机3个状态：
- Closed：关闭状态，所有请求都正常访问。
- Open：打开状态，所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
- Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进行休眠计时
（二）搭建
Feign默认也有对Hystrix的集成，但是默认情况下是关闭的。
- application.yml中添加（在乘客服务中添加）
feign:
hystrix:
enabled: true # 开启熔断功能
- 实现Fegin接口。这里如果服务不通，则会返回熔断类的结果。注意要加上@Component 将类注入到Spring容器中
3.在PassengerClient中指定熔断类：
- 测试，这里关闭driver和driver2服务。然后在请求。发现调用到了熔断方法
三、搭建Zuul网关
（一）简介
（二）实践
- 建立一个新项目，模仿服务提供者(passenger或者driver进行搭建)。将服务加入到Eureka 注册中心
yml文件
server:
port: 10005
eureka:
client:
service-url: # 注册到服务中心 (滴滴平台)
defaultZone: http://127.0.0.1:10000/eureka
instance: # 使用自定义ip
preferIpAddress: true
instance-id: ${spring.application.name}:${server.port}
spring:
application: # 应用名称，在服务中心显示
name: eureka-zuul
- 启动类添加注解 @EnableZuulProxy 开启网关功能
- 配置yml中的zuul网关代理的地址
zuul:
routes:
service-provider: # 路由id，可以随便
path: /eurake_passenger/** # 这里是映射路径 --- 即 访问时的地址。** 代表所有
url: http://127.0.0.1:10001 # 映射路径对应的实际url地址 --- 即真实访问的服务地址
-
测试：我们通过地址访问到了服务
-
但是上述我们将url地址写死为127.0.0.1，当服务迁移时则无法使用，所以我们需要建立面向服务的映射关系。说来也简单。。。。。将zull的yml文件url改为对应的服务名称即可。同时也会启用负载均衡
-
测试： 依旧可以访问到
-
简化路由配置:
上面的routes配置可以简化为如下，也是没人配置，这时routes的配置key值是服务名称，value值是映射路径:
zuul:
routes:
eureka-passenger : /eurake_passenger/** # 这里是映射路径
- Zuul过滤器配置： Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。
ZuulFilter是过滤器的顶级父类。其中定义的4个最重要的方法
public abstract ZuulFilter implements IZuulFilter{
abstract public String filterType(); //返回字符串，代表过滤器的类型。包含以下4种： pre：请求在被路由之前执行 route：在路由请求时调用; post：在route和errror过滤器之后调用; error：处理请求时发生错误调用
abstract public int filterOrder(); // 通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高
boolean shouldFilter();// 返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行
Object run() throws ZuulException;// 过滤器的具体业务逻辑
}
zuul过滤器执行的生命周期:
正常流程：
- 请求到达首先会经过pre类型过滤器，而后到达route类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。
异常流程：
- 整个过程中，pre或者route过滤器出现异常，都会直接进入error过滤器，在error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
- 如果是error过滤器自己出现异常，最终也会进入POST过滤器，将最终结果返回给请求客户端。
- 如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和route不同的是，请求不会再到达POST过滤器了。
- 创建一个过滤器MyFilter:
package com.kingfish.filter;
import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import com.netflix.zuul.exception.ZuulException;
import org.apache.http.HttpStatus;
import org.springframework.stereotype.Component;
import javax.servlet.http.HttpServletRequest;
/**
* @Data: 2019/7/20
* @Des: 自定义zuul过滤器
*/
@Component
public class MyFilter extends ZuulFilter {
/**
* 过滤器类型，这里设置为前置过滤器
*
* @return
*/
@Override
public String filterType() {
return "pre";
}
/**
* 过滤器的执行顺序
*
* @return
*/
@Override
public int filterOrder() {
return 1;
}
/**
* 该过滤器是否生效
* @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();
// 获取name信息
String name = request.getParameter("name");
// 判断
if ("李四".equals(name)) {
// 过滤该请求，不对其进行路由
context.setSendZuulResponse(false);
// 设置响应状态码，401
context.setResponseStatusCode(HttpStatus.SC_UNAUTHORIZED);
// 设置响应信息
context.setResponseBody("{\"status\":\"401\", \"text\":\"request error!\"}");
}
// 校验通过，把name信息放入上下文信息，继续向后执行
context.set("name", name);
return null;
}
}
- 测试:
注: Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1秒，可通过以下配置进行配置
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 2000 # 设置hystrix的超时时间为6000ms
682
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
