Spring-cloud微服务实战【八】：API网关zuul

  在前面的文章中,咱们前后使用了eureka/ribbon/feign/hystrix搭建了一个看似完美的微服务了,那是否还有值得继续优化的地方呢?答案确定是有的,若是从整个微服务内部来看,基本已经完整了,可是咱们的微服务不可避免的须要对外部提供服务,此时,咱们将关注点聚焦在对外提供服务这一块.

  假若有一个外部服务,须要调用咱们的整个微服务中许多不一样的服务,好比用户服务,订单服务,物流服务等等,思考一下,直接调用微服务会有什么问题?
  1.首先,外部服务必须知道咱们的微服务在eureka注册中心的应用名,根据应用名去调用(若是不走eureka注册中心而直接调用服务就失去了微服务的意义),而咱们并不想对外部服务暴露这些信息.言下之意,咱们既想要对外屏蔽咱们的内部信息,又能在屏蔽信息的状况下对外提供服务.
  2.其次,微服务采用restful API的架构风格,外部服务直接访问微服务内部的服务,势必要在各个微服务内新增权限校验的逻辑,而这偏偏破坏了restful API无状态的特色.
  3.外部服务屡次调用微服务内部的不一样服务,增长了外部服务的复杂性,不以利后期的维护.

  所以,为了解决这些问题,咱们须要将权限控制这样的东西从咱们的服务中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，这就是API网关.而spring cloud中的API网关就是zuul,接下来,让咱们来了解一下zuul.

什么是API网关zuul?

  zuul就是spring cloud中的API网关,相似于设计模式里面的Facade门面模式:

  他的存在就像是整个微服务的门面，全部的外部客户端访问都须要通过它来进行转发与过滤,它的核心是一系列的过滤器,它的主要做用包括:
1.身份验证和安全性:肯定每一个资源的身份验证要求并拒毫不知足这些要求的请求
2.监控和统计:监控和统计数据,为咱们提供准确的生产视图.
3.动态路由:相似于Nginx,根据须要动态地将请求路由到后端不一样的微服务.

  接下来,让咱们来用代码演示一下zuul,首先新增一个module:

  而后老规矩,三个步骤,首先配置maven依赖:

  而后配置文件:

  主要是端口号,以及eureka-server的地址,因为网关确定是须要从eureka中发现服务的,因此须要配置eureka-server的信息,前后启动eureka-server,producer-hystrix(该服务须要密码验证)以及user-hystrix(该服务无需密码验证):

  而后启动zuul网关访问试一下,咱们先访问一下无需密码访问的user:

  而后再试一下须要密码访问的producer:

  发现须要帐号密码登陆,由于咱们的producer启用了security,有安全验证,所以咱们须要在header中配置验证信息.以前咱们说过,zuul的核心是一系列的过滤器,其各类功能都是经过过滤器实现的,所以咱们须要经过过滤器实现该功能,zuul的过滤器有以下几种类型:


  很明显,咱们须要pre类型的过滤器,实现zuul过滤器的方式是继承ZuulFilter而且覆盖相应的方法,其中最重要的方法是run方法,该方法是咱们处理业务逻辑的实现方法.

  建立该过滤器后,必须建立一个bean才能生效:

  而后再访问试一试:

  嗯?为何仍是这样?咱们配置的过滤器未生效?是代码有问题吗?其实不是的,这是spring cloud的一个大坑,这是由于spring cloud zuul 对2.0.0.RELEASE 以上的高版本支持很差,这也是zuul一直被人诟病的地方,所以spring cloud官方从2.0.0.RELEASE开始,也是推出了本身的微服务网关spring-cloud-starter-gateway,目的也是想替代zuul,有兴趣的童鞋能够去研究一下gateway,咱们说了,要解决这个问题,是由于zuul版本过高,对springboot 支持不太好形成的,还记得以前咱们的zuul配置吗?

  咱们的springboot和cloud都是用的2.1.2版本,只要咱们把版本下降就能解决这个问题了:


  springboot咱们使用2.0.7版本,而zuul咱们使用2.0.0版本,而后在重启一下zuul服务访问:

   能够发现,咱们的过滤器已经生效了,在header中设置了帐号密码信息,经过了producer的security验证.可是还有一个问题,前面咱们说到,因为是对外服务,咱们并不想过多暴露咱们内部服务的相关信息,好比路径中的微服务的应用名,所以咱们还须要进行配置:

  前面两条,用于告诉zuul,凡是访问/producer-proxy/的路径,所有转发到dhp-micro-service-producer服务,第三条告诉zuul忽略全部服务,这样,再想经过直接访问微服务名的方式就没法访问了,只能经过指定的/producer-proxy/这个代理地址来访问:




  能够看到,再经过应用名的方式来访问直接报404,而经过咱们设置的代理地址,则能正常访问.

zuul安全访问

  做为全部微服务访问的统一入口，zuul也是能够进行加密访问的,同理是使用spring security:


  则访问的时候就须要进行安全验证:

  验证成功后就能正常访问了:

feign访问zuul

  在以前的文章中,咱们使用了feign来简化代码开发,如今咱们集成了网关zuul,全部的服务都走zuul,所以,咱们以前的代码也须要进行改造,使用feign集成zuul来访问微服务.
咱们说feign是经过eureka-server拉取服务,所以要使feign集成zuul,首先zuul也须要注册到eureka:

  而后新增一个使用feign访问zuul的service(本文直接在consumer中完成,实际生产环境可能因为有多个服务会须要调用,所以能够单独抽一个module出来):

  读过我以前文章的童鞋们应该明白,首先表示我这个接口使用feign代理,而且关注的服务是DHP-MICRO-SERVICE-ZUUL-GATEWAY,因为全部服务都有安全验证,所以有一个FeignClientConfig配置验证信息:

  若是调用服务失败,咱们还须要服务降级,所以有一个ZuulProxyServiceFallbackFactory:

  此时,相关准备工做已经就绪,开始使用,首先在consumer-feign中新增maven依赖:

  而后编码实现:

  而后依次启动eureka-server,producer,user,zuul,consumer访问试一试:

  能够看到,咱们成功经过zuul访问到了producer和user.但这还不够,咱们如今是经过消费者经过zuul代理访问服务方,此时zuul从功能上相似于Nginx,主要是转发,假如zuul转发到的服务挂了,会直接显示错误页面,好比咱们如今把producer停掉再访问一下:

  这显然是不行的,所以zuul自己也须要进行降级处理,新增一个降级处理的类:


  该降级处理类的主要做用是构建一个请求失败的http相应信息.此时再重启zuul试一下:

  能够发现咱们的zuul降级已经成功了,这样不会所以zuul代理的服务不可用而致使抛出异常了.

  下一篇文章,咱们继续介绍spring cloud 分布式配置中心config,敬请期待!

  本文的github地址

本文由博客一文多发平台 OpenWrite 发布！