微服务之服务网关
微服务之服务网关
简介
我们已经知道，在微服务架构中，不同的微服务可以有不同的网络地址，各个微服务之间通过互相调用完成用户请求，客户端可能通过调用N个微服务的接口完成一个用户请求。比如：用户查看一个商品的信息，它可能包含商品基本信息、价格信息、评论信息、折扣信息、库存信息等等，而这些信息获取则来源于不同的微服务，诸如产品系统、价格系统、评论系统、促销系统、库存系统等等，那么要完成用户信息查看则需要调用多个微服务，这样会带来几个问题：
1. 客户端多次请求不同的微服务，增加客户端的复杂性，
2. 认证复杂，每个服务都要进行认证；
3. http请求增加，效率不高；
4. 存在跨域请求，比较复杂。
那么问题来了？我们如何解决这个问题呢，可以这么想，不要让前端直接知道后台诸多微服务的存在，我们的系统本身就是从业务领域的层次上进行划分，形成多个微服务，这是后台的处理方式，对于前台而言，仍然类似于单体应用一样，一次请求即可，于是我们可以在客户端和服务端之间增加一个API网关，所有的外部请求先通过这个微服务网关，它只需跟网关进行交互，而由网关进行各个微服务的调用，如图：
微服务之服务网关
这样的话，我们就可以解决上面提到的问题，同时开发就可以得到相应的简化，还可以有如下优点：
1. 减少客户端与微服务之间的调用次数，提高效率；
2. 便于监控，可在网关中监控数据，可以做统一切面任务处理；
3. 便于认证，只需要在网关进行认证即可，无需每个微服务都进行认证；
4. 降低客户端与服务端的耦合度。
这里可以联想到一个概念，面向对象设计中的门面模式，即对客户端隐藏细节，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，则成功访问，如图：
微服务之服务网关
以上就是对服务网关的理解和简单应用，后续再进行补充完善。
如果觉得文章对你有启发，就请顺手点一下“❤”，或者关注一下再走啦。么么哒！
