内容来源：2017年5月6日，SpringCloud 中国社区创始人许进在“Spring Cloud中国社区技术沙龙-北京站”进行《Spring Cloud Zuul与网关中间件》演讲分享。IT 大咖说（ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。
阅读字数：1501 | 4分钟阅读
获取嘉宾演讲视频回放及PPT，请点击：http://t.cn/Rsvo4Kl
摘要
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. 尽量做到和服务治理框架解耦，易于接入，易于升级。
我今天的分享就到这里，谢谢大家！
网友评论