Day 8:微服务网关和 JWT 令牌

学习目标

  • 掌握微服务网关的系统搭建
  • 了解什么是微服务网关以及它的作用
  • 掌握系统中心微服务的搭建
  • 掌握用户密码加密存储 bcrypt
  • 了解 JWT 鉴权的介绍
  • 掌握 JWT 的鉴权的使用 :使用 Jwt 令牌来存储用户登录信息,在微服务网关中识别登录信息(用户的身份)
  • 掌握网关使用 JWT 进行校验
  • 掌握网关限流

1 微服务网关

1.1 微服务网关的概述

1.1.1 微服务网关解决的问题:

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

  • 客户端会多次请求不同的微服务,增加了客户端的复杂性
  • 存在跨域请求,在一定场景下处理相对复杂
  • 认证复杂,每个服务都需要独立认证
  • 难以重构,随着项目的迭代,可能需要重新划分微服务。例如,可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信,那么重构将会很难实施
  • 某些微服务可能使用了防火墙 / 浏览器不友好的协议,直接访问会有一定的困难

微信截图_20200929153822

1.1.2 微服务网关你的作用

  • 整合各个微服务功能,形成一套系统
  • 在微服务网关中实现统一日志记录
  • 实现用户的操作跟踪
  • 实现限流操作
  • 用户权限认证操作

微信截图_20200929154129

2 网关系统使用

2.1 需求分析

​ 由于我们开发的系统 有包括前台系统和后台系统,后台的系统 给管理员使用。那么也需要调用各种微服务,所以我们针对系统管理搭建一个网关系统。分析如下:

微信截图_20200929154610

2.2 网关过滤配置

​ 路由过滤器允许以某种方式修改传入的HTTP请求或传出的HTTP响应。路径过滤器的范围限定为特定路径。Spring Cloud Gateway 包含许多内置的 GatewayFilter 工厂。如上图,根据请求路径路由到不同微服务去,这块可以使用Gateway的路由过滤功能实现。

​ 过滤器有 20 多个实现类,包括头部过滤器、路径类过滤器、Hystrix 过滤器和变更请求 URL 的过滤器,还有参数和状态码等其他类型的过滤器。

​ 内置的过滤器工厂有 22 个实现类,包括头部过滤器、路径过滤器、Hystrix 过滤器 、请求URL 变更过滤器,还有参数和状态码等其他类型的过滤器。根据过滤器工厂的用途来划分,可以分为以下几种:Header、Parameter、Path、Body、Status、Session、Redirect、Retry、 RateLimiter 和 Hystrix。

过滤配置

2.3 网关限流

​ 网关可以做很多的事情,比如限流,当我们的系统被频繁的请求的时候,就有可能将系统压垮,所以为了解决这个问题,需要在每一个微服务中做限流操作,但是如果有了网关,那么就可以在网关系统做限流,因为所有的请求都需要先通过网关系统才能路由到微服务中。

项目有两层网关,第一层是 Nginx 网关,主要是对大量流量的一个抵御。第二层是微服务网关,通过 Nginx 网关之后,流量可能依旧较大,故此时可以用微服务网关控制对每个微服务进行限流,达到保护的作用

两层网关限流

2.3.1 令牌桶算法

令牌桶算法是比较常见的限流算法之一,大概描述如下:
1)所有的请求在处理之前都需要拿到一个可用的令牌才会被处理;
2)根据限流大小,设置按照一定的速率往桶里添加令牌;
3)桶设置最大的放置令牌限制,当桶满时、新添加的令牌就被丢弃或者拒绝;
4)请求达到后首先要获取令牌桶中的令牌,拿着令牌才可以进行其他的业务逻辑,处理完业务逻辑之后,将令牌直接删除;
5)令牌桶有最低限额,当桶中的令牌达到最低限额的时候,请求处理完之后将不会删除令牌,以此保证足够的限流

如下图:

1557910299016

这个算法的实现,有很多技术,Guaua 是其中之一,redis 客户端也有其实现。

3 JWT讲解

3.1 需求分析

我们之前已经搭建过了网关,使用网关在网关系统中比较适合进行权限校验。

1562059385713

那么我们可以采用JWT的方式来实现鉴权校验。

JWT 总结:

JWT 是用于微服务之间传递用户信息的一段加密字符串,该字符串是一个 JSON 格式,各个微服务可以根据该 JSON 字符串识别用户的身份信息,也就是改 JSON 字符串中会封装用户的身份信息。

3.2 什么是JWT

JSON Web Token(JWT)是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。

3.3 JWT的构成

一个JWT实际上就是一个字符串,它由三部分组成,头部、载荷与签名

头部(Header)

头部用于描述关于该JWT的最基本的信息,例如其类型以及签名所用的算法等。这也可以被表示成一个JSON对象。

{"typ":"JWT","alg":"HS256"}

在头部指明了签名算法是HS256算法。 我们进行BASE64编码http://base64.xpcha.com/,编码后的字符串如下:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

小知识:Base64是一种基于64个可打印字符来表示二进制数据的表示方法。由于2的6次方等于64,所以每6个比特为一个单元,对应某个可打印字符。三个字节有24个比特,对应于4个Base64单元,即3个字节需要用4个可打印字符来表示。JDK 中提供了非常方便的 BASE64Encoder 和 BASE64Decoder,用它们可以非常方便的完成基于 BASE64 的编码和解码

载荷(playload)

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品,这些有效信息包含三个部分

(1)标准中注册的声明(建议但不强制使用)

iss: jwt签发者
sub: jwt所面向的用户
aud: 接收jwt的一方
exp: jwt的过期时间,这个过期时间必须要大于签发时间
nbf: 定义在什么时间之前,该jwt都是不可用的.
iat: jwt的签发时间
jti: jwt的唯一身份标识,主要用来作为一次性token,从而回避重放攻击。

(2)公共的声明(不参与校验)

公共的声明可以添加任何的信息,一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息,因为该部分在客户端可解密.

(3)私有的声明(不参与校验)

私有声明是提供者和消费者所共同定义的声明,一般不建议存放敏感信息,因为base64是对称解密的,意味着该部分信息可以归类为明文信息。

这个指的就是自定义的claim。比如下面面结构举例中的admin和name都属于自定的claim。这些claim跟JWT标准规定的claim区别在于:JWT规定的claim,JWT的接收方在拿到JWT之后,都知道怎么对这些标准的claim进行验证(还不知道是否能够验证);而private claims不会验证,除非明确告诉接收方要对这些claim进行验证以及规则才行。

定义一个payload:

{"sub":"1234567890","name":"John Doe","admin":true}

然后将其进行base64加密,得到Jwt的第二部分。

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9

签证(signature)

jwt 的第三部分是一个签证信息(校验数据是否被篡改),这个签证信息由三部分组成:

header (base64后的)

payload (base64后的)

secret (秘钥->加盐)

这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串,然后通过header中声明的加密方式进行加盐secret组合加密,然后就构成了jwt的第三部分。

TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

将这三部分用.连接成一个完整的字符串,构成了最终的jwt:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

注意:secret是保存在服务器端的,jwt的签发生成也是在服务器端的,secret就是用来进行jwt的签发和jwt的验证,所以,它就是你服务端的私钥,在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

3.5 鉴权处理

鉴权过程

3.5.1 思路分析

  1. 用户通过访问微服务网关调用微服务,同时携带头文件信息
  2. 在微服务网关这里进行拦截,拦截后获取用户要访问的路径
  3. 识别用户访问的路径是否需要登录,如果需要,识别用户的身份是否能访问该路径[这里可以基于数据库设计一套权限]
  4. 如果需要权限访问,用户已经登录,则放行
  5. 如果需要权限访问,且用户未登录,则提示用户需要登录
  6. 用户通过网关访问用户微服务,进行登录验证
  7. 验证通过后,用户微服务会颁发一个令牌给网关,网关会将用户信息封装到头文件中,并响应用户
  8. 用户下次访问,携带头文件中的令牌信息即可识别是否登录

Q.E.D.

知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议

Live in the future, then build what's missing.