微服务架构中的网关

在前面的文章中我们讲到了微服务架构,当我们把一个庞大的单体系统拆分成多个微服务之后,把每个微服务部署在不同的服务器上。这时候系统的架构如下图所示:

上图架构存在扩展性差的问题。不同的微服务一般有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信,会有以下问题:

  • 客户端会多请求不同的微服务,增加了客户端的复杂性。
  • 存在跨域请求,在一定场景下处理相对复杂。
  • 认证复杂,每个服务都需要独立认证。
  • 安全隐患,微服务暴露给客户端的接口增加,增加服务的受攻击面。

微服务网关主要作用:
1.最主要功能是整合各个微服务功能,使之形成一套或多套系统。
2.安全,提供了统一访问入口,降低服务受攻击面。
3.在微服务网关中实现日志统一记录。
4.实现用户的操作跟踪。
5.实现限流操作,可以保护微服务,防止雪崩效应。
6.用户统一权限认证操作。

于是系统架构变成了如下:

下面来着重说明一下网关是如何整合多个微服务功能形成一个或者多个系统。

假如我们现在有文件上传,商品,用户,订单,支付,权限等多个微服务,现在需要开发一个网站后台管理系统,由这个系统去管理这些微服务模块。这时候可以创建一个独立网关gateway,当管理后台管理员请求gateway,由gateway负责去路由到不同的微服务,这样就实现了把不同的微服务整合到一起形成一个系统。

当一个普通的用户请求,这个普通用户只需要浏览商品,下单,支付功能。这时候可以新创建一个用户中心gateway,由用户中心网关去负责路由调用支付或者下单模块。

最终整系统架构抽象成如下架构:

用户请求微服务一个完整流程

以上图中用户请求商品微服务获取一个商品为例。

大概的流程分为2步:

1.登录鉴权

step1:首先用户请求网关,并且附带请求url(/api/goods)+令牌参数。
step2:网关server对令牌参数进行鉴权过滤,由于首次登录用户没有令牌,鉴权过滤失败,提示用户未登录,请先登录。
step3:用户请求登录url(/api/user),网关将请求转发至用户微服务。
step4:用户微服务处理登录,登录成功,给client颁发一个令牌(通过header头信息,cookie,参数等形式返回)。
step5:client得到令牌之后,重复step1.微服务网关验证通过,解析路由规则(/api/goods)将请求转发给商品微服务。

2.微服务网关路由

发表评论

电子邮件地址不会被公开。 必填项已用*标注