1. zuul网关和基本使用场景


一. API网关是怎么演化出来的?

我们最开始的服务是单题服务, 所有的功能业务都是在一台服务器上. 可以通过过滤器来实现安全的校验, 如权限校验等. 

 单体时代,整个微服务的架构也比较简单. 后来随着业务的复杂度越来越高, 我们切换到了微服务时代

 

进入微服务时代, 有如下特点: 
1. 原来单体服务被拆分为n个小的微服务
2. 这些微服务有一些公共的跨横切面的功能逻辑, 比如:安全,路由,日志等等。 如果每个微服务都来处理这些功能, 微服务就会很复杂, 微服务不但要处理业务逻辑,还要处理安全,路由,日志等逻辑, 开发的负担就会比较重。 所以 ,我们把这些公共的服务抽取出来, 放在网关这样的一个服务上, 这就是在微服务上为什么会产生网关这样的概念。

总结: 把微服务公共的功能抽取出来, 形成一个独立的组件,独立的服务,处理跨横切面的逻辑

3. 另一方面, 在单体时代, 我们的客户端主要是浏览器, 在微服务时代, 客户端可能是浏览器,可能是手机, 可能是我们对外提供的API。
如果让这些客户端单独对接微服务, 也是很复杂的。 如果让他们都对接网关服务,外面的各种平台只需要对接一个入口, 通过网关接入就可以了,不需要知道很多内部细节。

 

总结:网关是怎么诞生的?

1. 是将各个微服务跨横切面的东西抽取出来, 做成独立的网关服务

2. 作为单点的入口, 让外面各种形态可以方便的接入企业内部的微服务。

 

二. 网关的基本功能

 

 如上图所示, 网关的主要功能有: 单点入口, 路由转发, 熔断限流, 日志监控, 安全认证等等

1. 单点入口: 有了网关以后, 客户端只需要看到一个入口, 不需要看到内部复杂的细节

2. 路由转发: 客户端请求来了, 对应到网关只有一个入口, 那么具体请求的是哪一个服务呢?网关要做一个路由转发

3. 限流熔断: 在微服务时代, 微服务有很多, 每一个微服务都可能会出错或者产生延迟, 如果没有好的限流熔断机制, 很容器造成客户端被阻塞, 或者产生严重的后果,如雪崩效应. 网关要做一个限流熔断,保护后台服务的这样的一个功能.

4. 日志监控: 所有的请求经过网关, 我们都可以写日志,对他进行监控. 整个服务的健康状态, 有没有人利用网关做坏事情等. 我们还要时刻掌握网关的性能状况. 可以在网关上增加监控来做到

5. 安全认证: 所有的请求都通过网关进入到微服务, 网关就像是一道门, 一个请求进来, 我们要在门口检查一下, 他是不是安全的. 是否是经过认证的. 

 

三. Netflix Zuul网关

在Nexflix官网上, 描述: zuul是一个边界服务, 提供动态路由, 监控, 弹性, 安全等功能.

亮点: 可动态发布的过滤器机制.

网关是整个服务的门口, 我们不能经常性的重启发布网关服务. 他有一些跨横切面的功能, 我们最好是能够动态的去插拔, 不需要重新部署的情况下, 动态的修改网关跨横切面的逻辑. 这是zuul提供的可动态发布的过滤器,大大提高了灵活性

  • Zuul在英文中是怪兽的意思, 寓意看门神兽
  • 2014年被纳入spring cloud体系 

四.Zuul网关高级应用场景 

4.1 红绿部署

 

 绿色集群是老系统, 红色集群是新系统. 当新功能上线以后, 通过网关切流量, 先切部分流量到红色集群,也就是新系统. 做金丝雀测试. 测试没问题, 在逐渐切换到红色集群,直至所有的流量全部切换到红色集群. 期间, 有任何错误, 可以直接切换回老系统

4.2 开发者测试分支

有些功能比较关键, 需要开发人员去线上做测试. 这叫开发者测试分支. 测试分支不是直接调用生成得了流量, 而是开发人员用自己的流量的方式, 去调用测试集群. 这种能力也是通过zuul网关来支持的.

zuul网关,可以把内部开发请求的流量, 达到测试集群, 去做测试. 这样既可以测试生成环境的功能, 又不会影响生产的实际流量. 网关会做流量的判断

 

4.3 埋点测试

还可以使用网关实现埋点测试. 应用发到生产上以后, 可以分为埋点的和不埋点的. 埋点就是你要对应用的一些逻辑进行埋点. 比如instruments埋点或者调用链埋点. 有时候,埋点是有性能开销的.  我们把代码全部发不到生产上去, 可能会有性能问题. 埋点需要知道系统的性能情况, 要做买点测试. 我就可以将埋点的应用发到生产上, 测试人员就可以测埋点的集群. 通过买点测试可以详细了解应用的情况. 等到埋点测试完成, 发现性能是ok的, 我们就可以吧埋点去掉. 发到生产上. 

4.4 压力测试

 

 应用咋上线之前, 会先部署到Squeeze压力测试的集群中. 这时其实是要用生产流量的. 但这个生产流量是镜像的或者拷贝复制的. 真实的生成流量, 还是到真实的应用当中. 因为这个请求是镜像的或这个拷贝的,所以流量处理完以后不会返回给客户端, 他会被丢弃掉. 这个请求主要是用来测试应用上线前压力测试的. 

 

4.5 调试路由

 有的时候生成环境除了一些问题, 我们需要用到调试路由. 比如, 测试人员在header中增加一些参数. 或者特殊的信息放在里面. 请求过来以后, 网关会把这部分流量分配到调试集群. 这样就可以做线上的调试, 来发现一些问题. 

 

4.6 金色雀测试

 我们也可以利用网关实现金丝雀测试. 新的应用上线之前, 分为baseLine集群和canary集群.通过网关, 调拨少量的流量到canary金丝雀, 如果流量没有问题,说明整个应用是健康的. 再全量的切换到新的版本. 如有问题,随时切换回去. 

 

4.7 粘性金丝雀

粘性金丝雀测试也是金丝雀测试. 如果不带粘性, 那么流量过来到网关, 网关是会随机分配给baseLine和金丝雀集群的. 如果是粘性, 网关有黏住你的能力, 如果某一次你走的是金丝雀, 那么网关会记住你的信息,如ip, 下次你来了, 还让你走金丝雀集群. 他就不会随便跳了. 这在有些情况下是必须的,  不能让ip跳来跳去, 不然可能导致功能或结果不一致, 黏住就是一致的了.

 4.8 跨区域高可用

 

 

Neffilx的网关是分区部署的, 分部部署在AWS的三个区域, 三个区域的zuul都是高可用的. 一个挂掉, 可以切换到另一个区域的服务器

4.9 防爬虫共计

 

 netflix在网关上面对所有的流量进行监控, 发现异常流量, 爬虫或者是攻击性的, 他有能力拒绝请求, 保护后面的服务

 4.10 健康检查和屏蔽坏节点

 Netflix会对请求进行度量分析, 监控. 如果某一个后台的微服务节点出错了, 或者不响应了.netflix有自动摘除无用服务器, 屏蔽坏的节点. 这样用户的体验就更好.


免责声明!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系本站邮箱yoyou2525@163.com删除。



 
粤ICP备18138465号  © 2018-2025 CODEPRJ.COM