标签：令牌 URL 梳理 并发 token 权限 鉴权 资源
oauth2的思想类似于post 2次TCP
1、客户端url -> 授权服务器 (申请获取授权)
客户端url <- 授权服务器 (返回唯一授权标识token)
2、客户端url + token -> 资源服务器 (验证token 放行)
所以系统的工程划分为：授权工程和鉴权工程
授权：可供网关gateway实现微服务对外权限的授予 （应用在登陆领域）
鉴权：可供网关gateway实现微服务对外权限的签定 （应用在API领域）
授权服务的工作流程梳理：
extends WebSecurityConfigurerAdapter重写configure 配置formLogin登录入口URL (spring security的验证配置)
extends AuthorizationServerConfigurerAdapter重写configure 配置token、身份认证器，配置认证方式等 （认证服务配置）
implements TokenEnhancer 自定义token携带内容 （token增强器）
implements UserDetailsService.自定义查询数据库中用户信息
签权服务的工作流程梳理：
URL -> gateway filter
step1: 不需要鉴权的url放行
step2: 未携带token 直接跳出
step3: 调用签权服务看用户是否有权限 如果有则放行 请求资源微服务
签权服务
step1: token是否有效 （通过jwt解析判断是否有效）等一些验证工作(鉴权客户端)
step2: 从鉴权服务端 处理是否有权限（用户权限资源 与 请求的URL 比对是否有权限）
注：
用户权限资源：通过security获取authentication的用户名得到拥有权限资源
其中的权限资源 则通过 rbac 的资源服务器去查询
请求的URL：通过URL请求+ Method 则是取 初始化资源数据
step4：step3返回true 则放行 否则反之
在鉴权服务端在启动时初始化资源数据
-------------------------------------------------------------------------------------------------
socket再io的资源的读写之间回生成一个线程，严重的资源浪费
socket中nio是一个线程 采用多路复用机制，线程内部client轮询连接是否有数据可读，server轮询是否又新的连接，NIO底层由epoll实现，空轮询会导致cpu升高，编程复杂
Netty封装了JDK的NIO，只需要关心业务逻辑
Netty在内部使用了回调来处理事件；当一个回调被触发时ChannelHandler实现处理当一个新的连接已经被建立时，ChannelHandler的channelActive()回调方法将会被调用
ChannelFuture提供了几种额外的方法，这些方法使得我们能够注册一个或者多个ChannelFutureListener实例。监听器的回调方法operationComplete()
轮询客户服务端继承ChannelInboundHandlerAdapter 重写 -主要工作是等待并接受服务器发回的消息
channelRead()——对于每个传入的消息都要调用；响应
channelReadComplete()——通知ChannelInboundHandler最后一次对channel-Read()的调用是当前批量读取中的最后一条消息；
exceptionCaught()——在读取操作期间，有异常抛出时会调用。
ngix + Keepalived（分流 + 健康状态选举）
解决并发超卖问题：
数据库压力导致响应变慢，查询慢、写入慢甚至是服务无响应、宕机
数据库会首先出现访问瓶颈，将操作非常频繁的数据在内存缓存中进行，然后将数据异步写回数据库
在缓存数据库中(redis/memcached)解决锁的问题，缓存数据库提供了两种解决方式。
第一个是乐观锁，第二个是队列。
乐观锁：在加锁的数据上增加版本号
大数据量的考虑问题：
考虑表拆分-（表名字不一样，但是结构完全一样）
按业务分，比如 手机号的表，我们可以考虑 130开头的作为一个表，131开头的另外一张表 以此类推
如果是交易系统，我们可以考虑按时间轴拆分，当日数据一个表，历史数据弄到其它表
限流问题：
限流就是限制系统的输入和输出流量已达到保护系统的目的，比如：延迟处理，拒绝处理，或者部分拒绝处理等等
令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。 当桶满时，新添加的令牌被丢弃或拒绝。
1、使用guava提供工具库里的RateLimiter类(内部采用令牌捅算法实现)进行限流 （不适应分布式限流）
2、使用Redis实现，存储两个key，一个用于计时，一个用于计数。请求每调用一次，计数器增加1，若在计时器时间内计数器未超过阈值，则可以处理任务
标签：令牌,URL,梳理,并发,token,权限,鉴权,资源 来源： https://www.cnblogs.com/webster1/p/12246262.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。