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

传统开发方式,所有的服务都是本地的,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/

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

感谢您的阅读!

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐