【微服务】Zuul的必要性

接着上一篇，我们谈谈客户端如何访问微服务？

传统开发方式，所有的服务都是本地的，UI可以直接调用，现在功能拆分成独立的服务，跑在独立的虚拟机上的java进程了。客户端如何访问他呢？后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不符合我们拆分的理念。微服务在系统内部通常无状态，用户登录信息和权限管理最后有个统一的地方维护管理（OAuth）。

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

• 客户端多次请求不同微服务，增加客户端的复杂性
• 跨域问题，一定场景下处理相对复杂
• 认证复杂，每个服务都要独立认证
• 难重构，随着项目迭代，可能需重新划分微服务，重构难以实施
• 某些微服务可能使用了其他协议，直接访问会有问题

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

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

Zuul

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请求用户微服务和电影微服务，并把数据返给应用系统。
具体参考：使用Zuul聚合微服务

本文参考：https://blog.csdn.net/zhanglh046/article/details/78651993/

下篇为您介绍服务之间如何通信？期待您的来访。

感谢您的阅读！