在前面的文章中,我们先后使用了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:
可以看到,再通过应用名的方式来访问直接报404,而通过我们设置的代理地址,则能正常访问.
zuul安全访问
作为所有微服务访问的统一入口，zuul也是可以进行加密访问的,同理是使用spring security:
feign访问zuul
在之前的文章中,我们使用了feign来简化代码开发,现在我们集成了网关zuul,所有的服务都走zuul,因此,我们之前的代码也需要进行改造,使用feign集成zuul来访问微服务.
我们说feign是通过eureka-server拉取服务,因此要使feign集成zuul,首先zuul也需要注册到eureka:
可以发现我们的zuul降级已经成功了,这样不会因此zuul代理的服务不可用而导致抛出异常了.
下一篇文章,我们继续介绍spring cloud 分布式配置中心config,敬请期待!
本文由博客一文多发平台 OpenWrite 发布！