zuul API网关服务的学习(1)

原创
2019/06/20 13:42
阅读数 763

在学习了spring cloud的Eureka注册服务,Ribbon客户端负载均衡,Hystrix断路器,已经声明式服务调用Feign后,我们现在理解微服务的架构如下图所示

        在整个系统架构对外提供服务时,当客户端应用单击某个功能的时候往往会发出一些对微服务获取资源的请求到后端,这些请求通过FS、 Nginx等设施的路由和负载均衡分配后, 被转发到各个不同的服务实例上。 而为了让这些设施能够正确路由与分发请求, 运维人员需要手工维护这些路由规则与服务实例列表, 当有实例增减或是IP地址变动等情况发生的时候, 也需要手工地去同步修改这些信息以保持实例信息与中间件配置内容的一致性。随着系统规模越来越大,人工做这件事会越来越复杂,错误率也会越来越高。所以我们需要一套机制来有效降低维护路由规则与服务实例列表的难度。

        我们在服务端实现的微服务接口, 往往都会有一定的权限校验机制, 比如对用户登录状态的校验等; 同时为了防止客户端在发起请求时被篡改等安全方面的考虑, 还会有一些签名校验的机制存在。 这时候, 由千使用了微服务架构的理念, 我们将原本处千一个应用中的多个模块拆成了多个应用, 但是这些应用提供的接口都需要这些校验逻辑, 我们不得不在这些应用中都实现这样一套校验逻辑。 随着微服务规模的扩大, 这些校验辑的冗余变得越来越多, 突然有一天我们发现这套校验逻辑有个BUG需要修复,或者需要对其做一些扩展和优化,此时我们就不得不去每个应用里修改这些逻辑, 而这样的修改不仅会引起开发入员的抱怨, 更会加重测试人员的负担。 所以, 我们也需要一套机制能够很好地解决微服务架构中, 对于微服务接口访问时各前置校验的冗余问题。

        为了解决上面这些常见的架构问题,API网关的概念应运而生。API网关是一个更为智能的应用服务器, 它的定义类似于面向对象设计模式中的Facade模式, 它的存在就像是整个微服务架构系统的门面一样,所有的外部客户端访问都需要经过它来进行调度和过滤。它除了要实现请求路由、 负载均衡、 校验过滤等功能之外, 还需要更多能力, 比如与服务治理框架的结合、 请求转发时的熔断机制、 服务的聚合等一系列高级功能。

Zuul的应用场景

传统开发方式,所有的服务都是本地的,UI可以直接调用,现在功能拆分成独立的服务,跑在独立的虚拟机上的java进程了。客户端如何访问他呢?

后台有N个服务,前台就需要记住管理N个服务,一个服务下线/更新/升级,前台就要重新部署,这明显不符合我们拆分的理念。微服务在系统内部通常无状态,用户登录信息和权限管理最后有个统一的地方维护管理(OAuth)。

不同的微服务有不同的网络地址,而外部的客户端可能要调用多个服务的接口才能完成一个业务需求。比如一个电影购票可能调用用户微服务,电影微服务等,如果客户端直接和微服务通信,会存在如下常见问题:

  • 客户端多次请求不同微服务,增加客户端的复杂性

  • 跨域问题,一定场景下处理相对复杂

  • 认证复杂,每个服务都要独立认证

  • 难重构,随着项目迭代,可能需重新划分微服务,重构难以实施

  • 某些微服务可能使用了其他协议,直接访问会有问题

以上问题可以借助微服务网关API Gateway来解决,微服务网关介于客户端和服务器端之间,所有的外部请求都会先经过微服务网关:

这样客户端只需和网关交互,无需直接调用特定微服务的接口,方便监控,易于认证,减少客户端和各微服务间的交互。

zuul的作用:

  • 提供统一服务入口,微服务对前台透明

  • 聚合后台服务,节省流量,提升性能

  • 安全,过滤,流控等API管理功能

  • 提供统一服务出口,解耦

过滤器类型:

  • PRE:请求路由之前调

  • ROUTING:路由到微服务

  • POST:路由到微服务之后

  • ERROR:其他阶段发生错误后执行

除了默认的过滤器类型,Zuul还允许创建自定义的过滤器类型。

Zuul高可用

通过将多个zuul节点注册到Eureka Server实现高可用。存在以下两种情况:

Zuul客户端注册到了Eureka Server

Zuul客户端自动从Eureka Server查询Zuul Server列表,并用Ribbon负载均衡请求Zuul集群。

未注册到Eureka Server

微服务可能被其他微服务调用,也可能直接被终端app调用,这种情况,我们需要借助额外的负载均衡器来实现Zuul的高可用,比如Nginx等。

Zuul聚合微服务

许多场景下,一个外部请求,可能要查询后端多个微服务。比如一个电影售票系统,在购票订单页上,需要查电影微服务,还有用户微服务,如果让系统直接请求各个微服务,就算使用Zuul转发,网络开销、流量耗费、时长都不是很好,这时我们就可以使用Zuul聚合微服务请求,即应用系统值发送一个请求给Zuul,由Zuul请求用户微服务和电影微服务,并把数据返给应用系统。

参考:

https://blog.csdn.net/chengqiuming/article/details/80860981
https://blog.csdn.net/zhanglh046/article/details/78651993/

展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部