我们已经知道,在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求。比如:用户查看一个商品的信息,它可能包含商品基本信息、价格信息、评论信息、折扣信息、库存信息等等,而这些信息获取则来源于不同的微服务,诸如产品系统、价格系统、评论系统、促销系统、库存系统等等,那么要完成用户信息查看则需要调用多个微服务,这样会带来几个问题:
-
客户端多次请求不同的微服务,增加客户端的复杂性,
-
认证复杂,每个服务都要进行认证;
-
http请求增加,效率不高;
-
存在跨域请求,比较复杂。
那么问题来了?我们如何解决这个问题呢,可以这么想,不要让前端直接知道后台诸多微服务的存在,我们的系统本身就是从业务领域的层次上进行划分,形成多个微服务,这是后台的处理方式,对于前台而言,仍然类似于单体应用一样,一次请求即可,于是我们可以在客户端和服务端之间增加一个API网关,所有的外部请求先通过这个微服务网关,它只需跟网关进行交互,而由网关进行各个微服务的调用,如图:
这样的话,我们就可以解决上面提到的问题,同时开发就可以得到相应的简化,还可以有如下优点:
-
减少客户端与微服务之间的调用次数,提高效率;
-
便于监控,可在网关中监控数据,可以做统一切面任务处理;
-
便于认证,只需要在网关进行认证即可,无需每个微服务都进行认证;
-
降低客户端与服务端的耦合度。
这里可以联想到一个概念,面向对象设计中的门面模式,即对客户端隐藏细节,API网关也是类似的东西,只不过叫法不同而已。它是系统的入口,封装了应用程序的内部结构,为客户端提供统一服务,一些与业务本身功能无关的公共逻辑可以在这里实现,诸如认证、鉴权、监控、缓存、负载均衡、流量管控、路由转发等等,如图:
总结一下,服务网关大概就是四个功能:统一接入、流量管控、协议适配、安全维护,如图:
服务网关(Zuul)
在目前的网关解决方案里,有Nginx+ Lua、Kong、Spring Cloud Zuul等等,这里以Zuul为例进行说明,它是Netflix公司开源的一个API网关组件,Spring Cloud对其进行封装做到开箱即用,同时,Zuul还可以与Eureka、Ribbon、Hystrix等组件配合使用。简单说来,Zuul实现了两个功能:路由转发、过滤器:
- 路由转发:接受请求,转发到后端服务;
- 过滤器:提供一系列过滤器完成权限、日志、限流等切面任务。
原理
Zuul的核心是一系列过滤器,开发者通过实现过滤器接口,可以做大量切面任务,即AOP思想的应用。Zuul的过滤器之间没有直接的相互通信,而是通过本地ThreadLocal变量进行数据传递的。
配置步骤
(1)添加Zuul依赖,非常简单;
(2)在启动类添加@EnableZuulProxy注解,开启路由功能:
(3)路由配置:
说明:凡是以/cjgl/打头的请求,路由到ly-microservice-cjgl微服务。
(4)测试,打开浏览器,输入:http://10.17.1.123:6061/api/cjgl/hello,则可以看到被转发到ly-microservice-clgl微服务,如图:
ly-microservice-clgl微服务
安全认证
Zuul不仅实现路由转发,还可以充当过滤器,进行安全认证等操作,这里我们做一个示例,ZuulFilter是Zuul中核心组件,可以通过继承该抽象类,重写其中的方法实现。
我们这里要求用户请求时,必须传递一个token参数,没带token参数进行请求表示非法访问,我们给予拦截,并给客户端提示,操作步骤如下:
(1)新建AccessFilter类,继承ZuulFilter类,重写其中的run方法,如图:
(2)修改启动类,增加bean注入,如图:
(3)重启服务,再次输入:http://10.17.1.123:6061/api/cjgl/hello,则访问被拦截,提示“无访问权限”,因为没有带accessToken参数,如图:
(4)加上accessToken参数,再访问:http://10.17.1.123:6061/api/cjgl/hello?accessToken=666,则成功访问,如图:
链接:https://www.jianshu.com/p/977b291e1247