梦相随1006

版权归 梦相随1006 所有,未经 https://www.cnblogs.com/xin1006 作者许可,严禁转载

导航

Spring Cloud 学习笔记(3)--Greenwich.SR4

 

Feign

Feign可以把Rest的请求进行隐藏,伪装成类似SpringMVC的Controller一样。 你不用再自己拼接url,拼接参数等等操作,一切都交给Feign去做

 先写个Feign的例子

 

 

 

 Feign中本身已经集成了Ribbon依赖和自动配置

 Feign默认也有对Hystrix的集成:

 只不过,默认情况下是关闭的。我们需要通过下面的参数来开启:(在service-consumer工程添加配置内容)

feign:
hystrix:
  enabled: true # 开启Feign的熔断功能

但是,Feign中的Fallback配置不像hystrix中那样简单了

 

写一个FallBack的类实现Client接口,重写里面的方法,里面的方法就是熔断方法

 

 

正常:

 

 关掉服务提供者

使用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就担任了这样的一个角色,为微服务架构提供了前门保护的作用,同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体能够具备更高的可复用性和可测试性。

 

 Zuul

 

下面几个Zull的图参考 https://www.cnblogs.com/ll409546297/p/11898404.html 

 

 

在我们的工程当中,New --> Module... --> Spring Initializr(SDK 1.8)-->填写坐标(如下图)-->选择要引入的依赖

(Spring Cloud Routing-->Zuul ; 别忘记了选择SpringBoot版本)-->下一步 Finish

 

第一种配置:

 

 

 

 第二种配置 : zuul 与 Eureka 关联

 

 

 

配置文件再次简化(推荐使用这种)

 

第四种,就是  不配  zuul.routes , 默认就会有


 

Zuul 过滤器

Zuul作为网关的其中一个重要功能,就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的

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值来定义过滤器的执行顺序,数字越小优先级越高。

 写一个过滤器的例子:

 

 

 

posted on 2019-11-24 14:18  梦相随1006  阅读(297)  评论(0编辑  收藏  举报