微服务之服务网关

我们已经知道，在微服务架构中，不同的微服务可以有不同的网络地址，各个微服务之间通过互相调用完成用户请求，客户端可能通过调用N个微服务的接口完成一个用户请求。比如：用户查看一个商品的信息，它可能包含商品基本信息、价格信息、评论信息、折扣信息、库存信息等等，而这些信息获取则来源于不同的微服务，诸如产品系统、价格系统、评论系统、促销系统、库存系统等等，那么要完成用户信息查看则需要调用多个微服务，这样会带来几个问题：

1. 客户端多次请求不同的微服务，增加客户端的复杂性，

2. 认证复杂，每个服务都要进行认证；

3. http请求增加，效率不高；

4. 存在跨域请求，比较复杂。

   那么问题来了？我们如何解决这个问题呢，可以这么想，不要让前端直接知道后台诸多微服务的存在，我们的系统本身就是从业务领域的层次上进行划分，形成多个微服务，这是后台的处理方式，对于前台而言，仍然类似于单体应用一样，一次请求即可，于是我们可以在客户端和服务端之间增加一个API网关，所有的外部请求先通过这个微服务网关，它只需跟网关进行交互，而由网关进行各个微服务的调用，如图：
   

    这样的话，我们就可以解决上面提到的问题，同时开发就可以得到相应的简化，还可以有如下优点：
   

5. 减少客户端与微服务之间的调用次数，提高效率；

6. 便于监控，可在网关中监控数据，可以做统一切面任务处理；

7. 便于认证，只需要在网关进行认证即可，无需每个微服务都进行认证；

8. 降低客户端与服务端的耦合度。

    这里可以联想到一个概念，面向对象设计中的门面模式，即对客户端隐藏细节，API网关也是类似的东西，只不过叫法不同而已。它是系统的入口，封装了应用程序的内部结构，为客户端提供统一服务，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、鉴权、监控、缓存、负载均衡、流量管控、路由转发等等，如图：
   

总结一下，服务网关大概就是四个功能：统一接入、流量管控、协议适配、安全维护，如图：

服务网关（Zuul）

    在目前的网关解决方案里，有Nginx+ Lua、Kong、Spring Cloud Zuul等等，这里以Zuul为例进行说明，它是Netflix公司开源的一个API网关组件，Spring Cloud对其进行封装做到开箱即用，同时，Zuul还可以与Eureka、Ribbon、Hystrix等组件配合使用。简单说来，Zuul实现了两个功能：路由转发、过滤器：

1. 路由转发：接受请求，转发到后端服务；

2. 过滤器：提供一系列过滤器完成权限、日志、限流等切面任务。

原理

    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