SpringCloud(第二部分)
文章目录
- 6.负载均衡Ribbon
-
- 6.1.启动两个服务实例
- 6.2.开启负载均衡
- 6.3.负载均衡策略
- 7.Hystrix
-
- 7.1.简介
- 7.2.雪崩问题
- 7.3.线程隔离，服务降级
-
- 7.3.1.原理
- 7.3.2.测试
-
- 7.3.2.1.引入依赖
- 7.3.2.2.开启熔断
- 7.3.2.3.编写降级逻辑
- 7.3.2.4.默认FallBack
- 7.3.2.5.设置超时
- 7.4.服务熔断
-
- 7.4.2.测试
- 8.Feign
-
- 8.1.简介
- 8.2.快速入门
-
- 8.2.1.导入依赖
- 8.2.2.开启feign的功能
- 8.2.3.创建Feign的客户端
- 8.2.4.测试
- 8.3.负载均衡
- 8.4.Hystrix支持
- 9.Zuul网关
-
- 9.1.简介
- 9.2.Zuul加入后的架构
- 9.3.快速入门
-
- 8.3.1.新建工程
- 8.3.2.编写配置
-
- 8.3.3.编写引导类
- 8.3.4.编写路由规则
- 8.3.5.启动测试
- 8.4.面向服务的路由
-
- 8.4.1.添加Eureka客户端依赖
- 8.4.2.添加Eureka配置，获取服务信息
- 8.4.3.开启Eureka客户端发现功能
- 8.4.4.修改映射配置
- 8.5.过滤器
-
- 8.5.1.ZuulFilter
- 8.5.2.过滤器执行生命周期
- 8.5.3.使用场景
- 8.6.自定义过滤器
6.负载均衡Ribbon
在刚才的案例中，我们启动了一个service-provider，然后通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问。
但是实际环境中，往往会开启很多个itcast-service-provider的集群。此时获取的服务列表中就会有多个，到底该访问哪一个呢？
一般这种情况下我们就需要编写负载均衡算法，在多个实例列表中进行选择。
不过Eureka中已经帮我们集成了负载均衡组件：Ribbon，简单修改代码即可使用。
什么是Ribbon：
6.1.启动两个服务实例
首先启动两个service-provider实例 一个8081 一个8082
6.2.开启负载均衡
因为Eureka中已经集成了Ribbon，所以我们无需引入新的依赖，直接修改代码。
修改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; // eureka客户端，可以获取到eureka中服务的信息
@ResponseBody
@GetMapping
public User queryUserById(@RequestParam Long id){
//根据服务名称获取服务实例，有可能是集群，所以是service集合
// List instances = discoveryClient.getInstances("service-provider");
//因为只有一个service-provider 所以获取第一个实例
// ServiceInstance serviceInstance = instances.get(0);
//获取ip和端口信息，拼接成服务地址
String baseUrl = "http://service-provider/user/" + id;
User user = this.restTemplate.getForObject(baseUrl, User.class);
return user;
}
}
6.3.负载均衡策略
Ribbon默认的负载均衡策略是简单的轮询
测试
@RunWith(SpringRunner.class)
@SpringBootTest(classes = ServiceConsumerApplication.class)
public class LoadBalanceTest {
@Autowired
private RibbonLoadBalancerClient client;
@Test
public void testLoadBalance(){
for (int i = 0; i <50 ; i++) {
ServiceInstance instance = this.client.choose("service-provider");
System.out.println(instance.getHost()+":"+instance.getPort());
}
}
}
SpringBoot帮我们提供了修改负载均衡规则的配置入口，在service-consumer的application.yml中添加如下配置：
server:
port: 80
spring:
application:
name: service-consumer
eureka:
client:
service-url:
defaultZone: http://127.0.0.1:10086/eureka
service-provider:
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule
格式是：{服务名称}.ribbon.NFLoadBalancerRuleClassName，值就是IRule的实现类。
再次测试，就变为了随机
7.Hystrix
7.1.简介
Hystrix,英文意思是豪猪，全身是刺，是一种保护机制。
Hystrix也是Netflix公司的一款组件。
主页：https://github.com/Netflix/Hystrix/
Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。
7.2.雪崩问题
微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：
如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。
如果此时，某个服务出现异常：
例如微服务I发生异常，请求阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：
服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应。
Hystix解决雪崩问题的手段有两个：
- 线程隔离
- 服务熔断
7.3.线程隔离，服务降级
7.3.1.原理
线程隔离示意图：
解读：
Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。
用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理.
服务降级：优先保证核心服务，而非核心服务不可用或弱可用。
用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息） 。
服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它服务没有响应。
触发Hystix服务降级的情况：
- 线程池已满
- 请求超时
7.3.2.测试
7.3.2.1.引入依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-hystrixartifactId>
dependency>
7.3.2.2.开启熔断
@SpringCloudApplication 包括了上述三种注解。
可以使用这个组合注解来代替之前的3个注解。
7.3.2.3.编写降级逻辑
改造service-consumer，当目标服务的调用出现故障，希望快速失败，给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑，要使用HystixCommond来完成：
@Controller
@RequestMapping("consumer/user")
public class UserController {
@Autowired
private RestTemplate restTemplate;
@GetMapping
@ResponseBody
@HystrixCommand(fallbackMethod = "queryUserByIdFallBack")
public String queryUserById(@RequestParam("id") Long id) {
String user = this.restTemplate.getForObject("http://service-provider/user/" + id, String.class);
return user;
}
public String queryUserByIdFallBack(Long id){
return "请求繁忙，请稍后再试！";
}
}
因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。失败逻辑中返回User对象没有太大意义，一般会返回友好提示。所以把queryById的方法改造为返回String，反正也是Json数据。这样失败逻辑中返回一个错误说明，会比较方便。
说明：
- @HystrixCommand(fallbackMethod = “queryByIdFallBack”)：用来声明一个降级逻辑的方法
测试：
当service-provder正常提供服务时，访问与以前一致。但是当我们将service-provider停机时，会发现页面返回了降级处理信息：
7.3.2.4.默认FallBack
可以把Fallback配置加在类上，实现默认fallback：
@Controller
@RequestMapping("consumer/user")
@DefaultProperties(defaultFallback = "queryUserByIdFallback") //指定一个全局的熔断方法
public class UserController {
@Autowired
private RestTemplate restTemplate;
@ResponseBody
@GetMapping
@HystrixCommand //标记该方法需要熔断
public String queryUserById(@RequestParam Long id){
String baseUrl = "http://service-provider/user/" + id;
String user = this.restTemplate.getForObject(baseUrl, String.class);
return user;
}
//熔断方法，返回值要和被熔断的方法一致
public String queryUserByIdFallback(){
return "服务繁忙，请稍后再试";
}
}
- @DefaultProperties(defaultFallback = “defaultFallBack”)：在类上指明统一的失败降级方法
- @HystrixCommand：在方法上直接使用该注解，使用默认的剪辑方法。
- defaultFallback：默认降级方法，不用任何参数，以匹配更多方法，但是返回值一定一致
7.3.2.5.设置超时
可以通过hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds来设置Hystrix超时时间。该配置没有提示。
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMilliseconds: 6000 # 设置hystrix的超时时间为6000ms
改造服务提供者
改造服务提供者的UserController接口，随机休眠一段时间，以触发熔断：
@GetMapping("{id}")
public User queryUserById(@PathVariable("id") Long id) {
try {
Thread.sleep(6000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return this.userService.queryUserById(id);
}
7.4.服务熔断
熔断器，也叫断路器，其英文单词为：Circuit Breaker 
熔断状态机3个状态：
- Closed：关闭状态，所有请求都正常访问。
- Open：打开状态，所有请求都会被降级。Hystix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
- Half Open：半开状态，open状态不是永久的，打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会完全关闭断路器，否则继续保持打开，再次进行休眠计时
7.4.2.测试
为了能够精确控制请求的成功或失败，在consumer的调用业务中加入一段逻辑：
@ResponseBody
@GetMapping
@HystrixCommand //标记该方法需要熔断
public String queryUserById(@RequestParam Long id){
if(id == 1){
throw new RuntimeException("服务繁忙，请稍后再试");
}
String baseUrl = "http://service-provider/user/" + id;
String user = this.restTemplate.getForObject(baseUrl, String.class);
return user;
}
如果参数是id为1，一定失败，其它情况都成功。
准备两个请求窗口：
- 一个请求：http://localhost/consumer/user/1，注定失败
- 一个请求：http://localhost/consumer/user/2，肯定成功
当疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会断开，一切请求都会被降级处理。
此时访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有几毫秒左右：
8.Feign
8.1.简介
- Feign是Netflix开发的声明式、模板化的HTTP客户端，其灵感来自Retrofit、JAXRS-2.0以及WebSocket。Feign可帮助我们更加便捷、优雅地调用HTTP API。
- 在Spring Cloud中，使用Feign非常简单–创建一个接口，并在接口上添加一些注解，代码就完成了。Feign支持多种注解，例如Feign自带的注解或者JAX-RS注解等。
- Spring Cloud对Feign进行了增强，使Feign支持了Spring MVC注解，并整合了Ribbon
和Eureka，从而让Feign的使用更加方便。
8.2.快速入门
8.2.1.导入依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-openfeignartifactId>
dependency>
8.2.2.开启feign的功能
添加注解，开启Feign功能
@SpringCloudApplication
@EnableFeignClients //开启feign客户端
public class ServiceConsumerApplication {
@Bean
@LoadBalanced //开启负载均衡
public RestTemplate restTemplate(){
return new RestTemplate();
}
public static void main(String[] args) {
SpringApplication.run(ServiceConsumerApplication.class, args);
}
}
8.2.3.创建Feign的客户端
添加一个UserClient接口
@FeignClient(value = "service-provider") //标注该类是一个feign接口
public interface UserClient {
@GetMapping("user/{id}")
User queryById(@PathVariable Long id);
}
- 首先这是一个接口，Feign会通过动态代理，帮我们生成实现类。这点跟mybatis的mapper很像
@FeignClient，声明这是一个Feign客户端，类似@Mapper注解。同时通过value属性指定服务名称- 接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果
改造原来的调用逻辑，调用UserClient接口：
@Controller
@RequestMapping("consumer/user")
public class UserController {
@Autowired
private UserClient userClient;
@ResponseBody
@GetMapping
public User queryUserById(@RequestParam Long id){
return this.userClient.queryById(id);
}
}
8.2.4.测试
8.3.负载均衡
Feign中本身已经集成了Ribbon依赖和自动配置：
8.4.Hystrix支持
开启Hystrix的集成：
feign:
hystrix:
enabled: true
1.定义一个类UserClientFallback，实现刚才编写的UserClient，作为fallback的处理类
@Component
public class UserClientFallback implements UserClient{
@Override
public User queryById(Long id) {
User user = new User();
user.setName("服务器繁忙");
return user;
}
}
2.然后在UserFeignClient中，指定刚才编写的实现类
@FeignClient(value = "service-provider",fallback = UserClientFallback.class) //标注该类是一个feign接口
public interface UserClient {
@GetMapping("user/{id}")
User queryById(@PathVariable Long id);
}
3.测试
9.Zuul网关
使用Spring Cloud实现微服务的架构
我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及均衡负载。为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。
在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？
这样架构的不足
-
破坏了服务无状态特点。
为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。
从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。
-
无法直接复用既有接口。
当我们需要对一个即有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。
为了解决上面这些问题，我们需要将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器的 服务网关。
服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。
9.1.简介
9.2.Zuul加入后的架构
不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现 鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。
9.3.快速入门
8.3.1.新建工程
添加Zuul依赖：
8.3.2.编写配置
server:
port: 10000 #服务端口
spring:
application:
name: api-gateway #指定服务名
8.3.3.编写引导类
通过@EnableZuulProxy注解开启Zuul的功能：
@SpringBootApplication
@EnableZuulProxy //开启网关功能
public class ZhZuulApplication {
public static void main(String[] args) {
SpringApplication.run(ZhZuulApplication.class, args);
}
}
8.3.4.编写路由规则
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
8.3.5.启动测试
访问的路径中需要加上配置规则的映射路径，我们访问：http://127.0.0.1:10010/service-provider/user/1
8.4.面向服务的路由
在刚才的路由规则中，把路径对应的服务地址写死了！如果同一服务有多个实例的话，这样做显然就不合理了。应该根据服务的名称，去Eureka注册中心查找服务对应的所有实例列表，然后进行动态路由才对
8.4.1.添加Eureka客户端依赖
<dependency>
<groupId>org.springframework.cloudgroupId>
<artifactId>spring-cloud-starter-netflix-eureka-clientartifactId>
dependency>
8.4.2.添加Eureka配置，获取服务信息
eureka:
client:
registry-fetch-interval-seconds: 5 # 获取服务列表的周期：5s
service-url:
defaultZone: http://127.0.0.1:10086/eureka
8.4.3.开启Eureka客户端发现功能
@SpringBootApplication
@EnableZuulProxy // 开启Zuul的网关功能
@EnableDiscoveryClient
public class ZuulDemoApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulDemoApplication.class, args);
}
}
8.4.4.修改映射配置
zuul:
routes:
service-provider: /provider/** #路由id，随意写
service-consumer: /consumer/**
prefix: /api #添加路有前缀
通过zuul.prefix=/api来指定了路由的前缀，这样在发起请求时，路径就要以/api开头。
在使用Zuul的过程中，上面讲述的规则已经大大的简化了配置项。但是当服务较多时，配置也是比较繁琐的。因此Zuul就指定了默认的路由规则：
- 默认情况下，一切服务的映射路径就是服务名本身。例如服务名为：
service-provider，则默认的映射路径就 是：/service-provider/**
也就是说，刚才的映射规则我们完全不配置也是可以的
8.5.过滤器
Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。往往是通过Zuul提供的过滤器来实现的。
8.5.1.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值来定义过滤器的执行顺序，数字越小优先级越高。
8.5.2.过滤器执行生命周期
正常流程：
- 请求到达首先会经过pre类型过滤器，而后到达route类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。
异常流程：
- 整个过程中，pre或者route过滤器出现异常，都会直接进入error过滤器，在error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
- 如果是error过滤器自己出现异常，最终也会进入POST过滤器，将最终结果返回给请求客户端。
- 如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和route不同的是，请求不会再到达POST过滤器了。
8.5.3.使用场景
- 请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了
- 异常处理：一般会在error类型和post类型过滤器中结合来处理。
- 服务调用时长统计：pre和post结合使用。
8.6.自定义过滤器
@Component
public class LoginFilter extends ZuulFilter {
/**
* 过滤器类型，前置过滤器
* @return
*/
@Override
public String filterType() {
return "pre";
}
/**
* 过滤器执行顺序
* @return
*/
@Override
public int filterOrder() {
return 10;
}
/**
* 该过滤器是否生效，true为生效
* @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("token");
// 判断
if (StringUtils.isBlank(token)){
// 过滤该请求，不对其进行路由
context.setSendZuulResponse(false);
// 设置响应状态码，401
context.setResponseStatusCode(HttpStatus.SC_UNAUTHORIZED);
// 设置响应信息
context.setResponseBody("request error");
}
// 校验通过，把登陆信息放入上下文信息，继续向后执行
context.set("token",token);
return null;
}
}
测试
没有传入token
传入token
