规划建立一个网站 项目wordpress指定上传目录

JWT

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

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

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

6.1 组成

一个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的第二部分。

杂七杂八：

Ribbon的七种负载均衡策略

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

利用Sentinel处理微服务雪崩问题的四种常见方式

什么是雪崩？

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

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

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

1.预防雪崩：

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

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

2.缓解雪崩

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

3.解决雪崩

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

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

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

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

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

先熔断后降级

FILE