在前面的文章中,我们先后使用了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,敬请期待!
本文由博客一文多发平台 OpenWrite 发布！
