服务网关和Zuul

现在我们来设想一个场景,当前起了10个微服务,比如订单,广告,商品,支付,用户,等等等等,那客户端要怎么调用呢,

和每一个服务一个一个打交道,这显然是不现实的,肯定需要一个角色,来充当request请求的统一入口,充当这个角色的,

就是服务网关,一旦有了服务网关,所有请求都通过它,随着而来我们可以想一下,他要发挥什么作用,他要具备什么样的

要素

一旦有了服务网关,所有请求都通过它,随着而来我们可以想一下,他要发挥什么作用,他要具备什么样的要素,

服务网关作为请求的入口,可以预见他必须保证,24小时可用,网关瘫痪,系统全挂,完全不能对外服务,影响可能是

致命的,所以稳定性和高可用,是我心目中对网关的第一要求,第二点是性能和并发性,所有的请求都会经过网关,可想

而知,网关的访问压力是巨大的,所以网关的性能也必须高,然后网关的安全性也是非常注重的,要确保服务使用的安全,

防止外部的恶意访问,有些比如金融行业,它会采用通信数据加密措施,最后是扩展性,因为各种请求都经过网关服务,

所以网关上大有文章可做,理论上网关上是处理费业务功能的绝佳场所,诸如协议转发,防刷,流量管控,日志监控,都可以

考虑,大家要明白,网关并不是微服务出现后的新鲜事物,业界的成熟网关方案挺多的,我举一些例子吧,常见的有Nginx+Lua,

Nginx大名鼎鼎,用的也非常的多,性能和高可用是Nginx傲视群雄的资本,它性能极高,先天的全异步IO设置,极少的进程间切换,

以及许多优化设计,都使得Nginx天生适合高并发请求,扩展性上Nginx做的非常棒,它本身上被设计为不同层次不同类型,且耦合度

极低的模块组成,当对某一个模块修复Bug,或者升级时,国内就有很多基于Nginx二次开发的,比如KONG,它是API管理软件,他本身是

基于Nginx+Lua的,但是比Nginx提供了更简单的配置方式,由于本身是源于Nginx,所以在性能和稳定性上,是没有什么大问题的,不过

KONG是一款商业软件,有很多付费的商业插件,所以这个东西好还是很好地,就是得花钱,然后下一种方案就是TYK,Tyk是一种开源的,

轻量级快速可伸缩的API网关,支持配额和速度限制,支持认证数据分析,支持多用户多组织,感觉一直为他打广告,各种好处,

他还提供全RESTFul API,值得注意,Tyk是GO语言开发的,大家应该有所了解,GO语言最近也是特别的火,作为GOOGLE爸爸的亲儿子,

GO在并发编程上,从语言层面上,就有天然的优势,Tyk在性能和扩展性上,最后就是我们的主角,Spring Cloud Zuul,Zuul是Netflix

出品的基于路由和服务端的负载均衡器,可以说他天生服务于微服务,这个是他的特点和优势,Zuul的优势在于,如果你是以JAVA技术栈

为主,构建微服务的话,和Spring Cloud的治理体系,Zuul提供了认证,限流,动态路由,监控,弹性,安全,负载均衡,看我特性特别多,

还没讲完,协助单点压测,静态响应,等边缘服务的框架,我是觉得你使用Spring的话,特别是你使用了SpringCloud,那么你再使用Zuul,

如果你团队规模不大,没有专门的网关开发人员的情况下,Zuul是一款快速的好方案,从前几个要素来衡量的话,Zuul在性能上,

并不具备优势,直白一些就是不能和Nginx比性能,当然据说,第二代Zuul有较大的提升,但是还是有待观察,所以这方面我持保留意见,

那小伙伴可能要说了,你把Zuul说的这么烂的样子,那我还学他干嘛,其实话也不能这么说,我们学技术的,一定要灵活,要学会混搭,

原始我们的点餐项目,是Nginx在前,tomcat在后,Nginx做了负载均衡和反向代理,现在我们依然可以让Nginx发挥负载均衡和反向

代理的优势,后面的TOMCAT呢,可以换成Zuul,让Nginx继续发挥他性能上的优势,而让Zuul好好发挥他性能上的优势,这不就皆大欢喜了吗,

项目改造工程中,合理利用原来的资源,发挥新加入的事务的优势,因地制宜解决问题,这一点特别重要,Zull虽然在并发性性能等方面,

相较于Nginx呢,那肯定是有所不足,但是他作为SpringCloud完整服务构建体系,前置网关服务,还是一个非常不错的选择,有一种说法呢,

叫做路由加过滤器,等于Zuul,Servlet的过滤器,相信大家都不会陌生,个人觉得Zuul组建的核心,就是一系列的过滤器,我们用Zull就应该

利用Zuul的特点,发挥它的优势,过滤器可以说是实现API网关,最核心的组件了,每一个进入Zuul HTTP请求,都会经过这一系列的过滤器,

处理之后,得到响应并返回给客户端,Zuul里面定义了四种,标准过滤器类型,第一是前置,路由,后置Post,最后一个是Error,这四个类型

会详细的给大家介绍

这幅图就是Zuul整个组建的架构图,可以看到,他们过滤器之间,是没有直接通信的,他们之间有一个Request Context,

就是上下文,通过这来进行数据传递

我们在看在Zuul组件里面,一次HTTP请求,生命周期是什么样子的,上面就是一个请求进来,这些红的就是他的过滤器,

最下面这个Orgin Server,就是我们后面的服务,比如上面提到的Product服务,可以看到进过一系列的过滤器之后,

才返回这个请求,那么这些过滤器,我们依次的来看一下,他首先是到Pre过滤器,他不是一个过滤器,在这个类型下面又

写了很多个过滤器类,所以看似一次简单的请求返回,其实这里实现 还是很复杂很多的,首先到达的是Pre Filter,

过滤器,从名字也可以看出来,这里做的事情主要是对路由前置的一些加工,比如我们要做的参数校验,你就放到这个地方来做,

接下来是Routing Filter,Routing Filter做的事情,就是将WEB的请求,给他转发到Orgin Server上去,那你觉得他这个HTTP

请求,他用的方式性能不够高,或者不够优雅,你想重写它的HTTP请求,那么你可以到这个地方来做,再往后呢,POST Filter,

这个时候你已经拿到了返回的结果,假如你想对结果进行处理和加工,那么你可以在这个地方来做,下面有一个Error Filter,

Error Filter是在上面提到的这三个,过滤器发生异常之后,他就会到达Error Filter,所以如果要做一些统一异常处理的话,

你要在Error Filter这个类里来做,最左边左下方,左下方的Custom Filter,定制的过滤器,他的意思是说我们自己定义的可以

放到这边来,事实上不仅可以放到Pre Filter这边,也可以放到Post这边,都是可以的