西宁网站开发整站优化方案

JSON Web token 检查JWT ，是用于对应用程序上的用户进行身份验证的标记。也就是说，使用JWTS的应用程序 不再需要保存有关其用户的cookie或其他session数据。此特性便于 可伸缩性，同时保存应用程序的安全。

在身份验证过程中，当用户使用其凭据成功登录时，将返回JSON Web token，并且 必须在本地保存（通常在本地存储中）。

每当用户要 访问受保护的路由或资源（端口）时， 用户代理（user agent）必须连同请求一起发送JWT，通常在授权标头中使用Bearer schema。 后端服务器接收带有JWT的请求时，首先要做的是验证token。

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

头部（Header）

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

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

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

载荷（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：

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

1. 轮询模式：按照一定顺序来依次调用服务实例
2. 权重策略：根据每个服务的响应时间分配一个权重，响应时间越快，权重越大。刚开始是使用轮询模式并开启一个计时器，每一段时间收集一次所有服务提供者的平均响应时间，然后再给每个服务提供者提供一个权重，权重越高被选中的概率也就越大
3. 随机策略：从服务提供者的列表中随机选择一个服务实例
4. 最小连接数策略：选取连接数最小的服务实例
5. 重试策略：按照轮询获取服务，如果服务实例试下，则在指定的时间之内不断的进行重试来获取服务
6. 可用性敏感策略：先过滤掉非健康的服务实例，然后在选择连接数较小的服务实例
7. 区域敏感策略：根据服务所在区域的性能和服务的可用性来选择服务实例，在没有区域的环境下，该策略和轮询策略类似

什么是雪崩？

微服务调用链路中的某个服务故障，引起整个链路中的所有微服务都不可用，这就是雪崩

一个服务无法正常工作 其他依赖于它的微服务也会跟着无法正常工作，这种 连锁反应就叫做雪崩

处理雪崩主要有三方面 预防雪崩和 缓解雪崩和 解决雪崩

流量控制： 限制业务访问的QPS（QPS： 每秒钟处理的请求的数量），避免服务因流量的突增而故障（预防雪崩）

比如设置QPS=2，就是每秒钟最多处理两个请求

超时处理： 设定超时时间，请求超过 一定时间没有响应就返回错误信息，不会无休止等待（但是不能解决根本 只能缓解） 因为 如果释放的资源没有进入的快

舱壁模式： 限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离（资源浪费的情况）

我们把服务器中的 资源划分为一个个的线程池， 给每个业务分配了一个线程池。比如服务A中业务1分到了10个 业务2分到了10 业务1依赖服务B，就是 意味着它最多用10个线程去访问服务B。如果此时服务B发送故障，那么这个业务会阻塞占用我们的线程，但是最多只占用我们的10个线程，我们 服务A的其他业务还能继续使用

熔断降级：由断路器 统计业务执行的异常比例，如果 超出阈值则会熔断该业务，拦截访问该业务的一切请求。（能解决资源浪费的情况，这是一种比较好的方案）

去 统计服务A里的业务执行情况，根据业务访问的服务中的 异常比列来决定是否熔断，如果异常比例超出阈值，则将其熔断

服务A还要 继续访问该服务则会被拦截，会 快速失败直接释放资源。

先熔断后降级

FILE