Spring Cloud Zuul与网关中间件

内容来源：2017年5月6日，SpringCloud 中国社区创始人许进在“Spring Cloud中国社区技术沙龙-北京站”进行《Spring Cloud Zuul与网关中间件》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：1501 | 4分钟阅读

嘉宾演讲视频回顾及PPT地址：t.cn/RnP2eZZ

摘要

SpringCloud 中国社区创始人许进在本次演讲中为你们分享本身在Spring Cloud Zuul与网关中间件的一些研发经验。

网关介绍

API网关提供API全托管服务，丰富的API管理功能，辅助企业管理⼤规模的API，以下降管理成本和安全风险。——来自阿里云的定义。

包括协议适配、协议转发、安全策略(WAF)、防刷，流量量、监控日志。

网关经常使用功能

统一接入：为各类无线应用提供统一接入服务；

高性能、高并发、高可靠性；

负载均衡，容灾切换（异地多活）。

安全防御：和安所有合做，IP黑名单，URL黑名单；

风防控制，防恶意攻击等。

协议适配：前端系统（http、http2）后端业务系统（RPC）；

长、短连接支持；

根据前端请求路由至相应的SOA服务并执行，返回结果给前端。

流量管控：服务降级；熔断；路由（异地多活中的应用）。

上图是在异地多活中网关的位置。在异地多活中，网关可能须要开发一个filter，它主要是作用户分片的路由。好比一个用户在上海帮助北京的朋友下单，应该经过网关路由分片到北京的机房，在北京的机房中把全部服务调用或者数据落地等等所有作完。因此网关在异地多活中也是至关重要的。

Spring Cloud Zuul

SpringCloud Zuul经过与Spring Cloud Eureka进行整合，将自身注册到Eureka Server中，与Eureka，Ribbon，Hystrix等整合，同时从Eureka中得到了全部其它微服务的实例信息。

首先一个http请求进来以后，必定会通过Zuul的Servlet，也可能会通过Zuul Filter Runner。Runner是统管全部Filter链的顺序或者数据的交互，Filter Runner主要是管理整个Zuul的生命周期。

用户请求进来后会有不少信息，经过Request Context的上下文在Zuul的生命周期中进行传递。

FilterLoader是当Zuul启动的时候会从本地或从动态Filter里的指定目录将Filter进行装载。

如图所示，Zuul除了自定义Filter以外，主要分为四种Filter类型。一种是“pre” Filters（易处理Filter），一种是“routing” Filters，就是服务路由的Filter。还有一种“post” Filters，以及“error” Filters。只要任何一个环节或者自定义的Filters出现异常以后，都会带着Request Context上下文信息直接跳到“error” Filters。若是所有流程跑完以后都没有一个error的话，确定会调用到内部服务。

请求转发

当注解为@EnableZuulProxy时，测试转发。经过访问⽹网关的URL: http://localhost:8041/api-url/sc/order/1

能够正常地把请求的url转发到http://localhost:8000/sc/order/2

默认路由规则

说明默认状况下，Zuul会代理理全部注册到Eureka Server的微服务，而且Zuul的路由规则以下：

http://ZUUL_HOST:ZUUL_PORT/微服务在Eureka上的serviceId/**

会被转发到serviceId对应的微服务。

http://localhost:8040/sc-zuul-first-provider/sc/order/2

网关的负载均衡

http://localhost:8040/sc-zuul-first-provider/sc/order/2

经过网关访问服务提供者，负载均衡打出对应的日志

为何要自研网关

1.网关配置实时生效，配置灰度，回滚等。

2.网关的性能，特别是防刷，限流，WAF等。

3.动态Filter，目前Zuul能够作到动态Filter，Filter配置下发，实时动态Filter。

4.对网关的监控，告警，流量调拨，网关集群。

5.流程审计，增长Dsboard便捷的操做。

基于Netty的GW架构和Zuul的设计差很少，可是在细节方面好比Filter面的处理方式、基于Netty的高性能网关入口以及Request Context的上下文处理，都有不一样的地方。

对外的GW最好的方式就是以轻量的client端引入到GW-server中。由于包括服务治理等必定是由服务治理内部的一些服务注册与发现进行处理，client主要是作一个转发或者一些简单功能处理。

这样作的好处就是，当网关和服务治理框架升级的时候，二者之间的耦合就至关低了，网关随着版本的迭代能够自行升级。至于内部的REST服务或RPC服务只是经过client端作一个薄薄的转发，这样就能够作到解耦。

Filter只须要作单一职责。如上图所示，Filter有一个抽象的接口，当Filter启动的时候会对数据进行一些处理。还有一个抽象的Filter主要是作一些每一个Filter自己数据的CRUD。

Filter数据的CRUD

每一个Fliter有本身的缓存数据，缓存数据的CRUD经过观察者模式按key更新。

网关设计原则

1.每一个Filter基于责任链，只作专注的一件事。

2.每一个Filter有各自独立的数据。

3.损耗性能的Filter顺序日后放。

4.启动读取配置顺序，先远端，若远端失败，则读取本地。

5.集群网关，要注意数据的diff和灰度。

6. 尽可能作到和服务治理框架解耦，易于接入，易于升级。

我今天的分享就到这里，谢谢你们！