SpringSecurity、ShardingSphere、Seata 零碎笔记
都是2020年随手记的老笔记， 不成体系、 不成文章。 仅作参考用。
现在写博客随意点了，所以干脆复制上来。 虽说是零散的， 但也是以前的一点点小积累， 以后我可以随时来博客看而不是找文档。
SpringSecurity主要是用来解决安全访问控制的
他对 Web 资源的保护是以 Filter 实现的.
当SpringSecurity初始化时, 会创建一个名为SpringSercurityFilterChain的Servlet过滤器，类型是 FilterChainProxy, 他实现了javax.servlet.Filter, 所以外部的请求都会走一遍这里。
FilterChainProxy是一个代理，真正起作用的是其中包含的多个Filter, 同时这些Filter是作为Bean被Spring管理的, 他们是SpringSecutiry的核心， 但是他们并不直接处理用户的认证、也不处理用户的授权，而是将他们交给认证管理器、决策管理器进行处理。
当然它并不只是一个Filter，而是由多个Filter组成的 Filter链条。
一个安全框架，最重要的当然是 认证 和 鉴权。 SpringSecurity对于这两个关键步骤 有着特定的处理对象，其中效验用户的身份这个行为会委托给 AuthenticationManager 类、如果是要效验用户的权限呢？ 那就会委托给 AccessDecisionManager 这个类。
所以SpringSecurity最基础的一个流程大概可以这样描述: 基于Filter链来拦截用户请求， 最终他效验用户身份的,则是 AuthenticationManager 、AccessDecisionManager 这两个关键类。从而对用户的身份进行认证、对用户访问资源的行为进行授权
FilterChainProxy 里几个重要的 Filter:
SecurityContextPersistenceFilter : 这个Filter是整个拦截过程的入口和出口, 会在请求开始时从配置好的SecurityContextRepository中获取SecurityContext。 然后把它设置给SecurityContextHolder, 在请求完成后反过来再将SecurityContextHolder持有的SecurityContext保存到SecurityContextRepository， 同时把SecurityContextHolder持有的SecurityContext给清除掉。
UsernamePasswordAuthenticationFilter:这个Filter主要是用来处理来自表单提交的用户名和密码，其内部还有登陆成功/失败后进行处理的 AuthenticationSuccessHandler 和 AuthenticationFailureFilter。
FilterSecurityInterceptor: 这个就是用来保护 web 资源的, 使用 AccessDecisionManager 对当前用户进行授权
ExceptionTranslationFilter: 能够捕获来自 FilterChain 所有的异常并进行处理, 但他只会处理 AuthenticationException和AccessDeniedException，其他的异常他会继续抛出
Apache ShardingSphere
三种接入端:
-
Sharding-JDBC
-
代码层面
-
-
Sharding-Proxy
-
中间件 –> Docker
-
-
Sharding-Sidecar
-
开发中 –> K8S
-
× 就算开发出来, 最好也别用, 都到K8S这种地步了，不如上TiDB这种分布式数据库 (一站式解决)
-
Sharding-JDBC
需要维护多份配置, 难以维护
配置的时候, 数据源交给ShardingSphere保管了
Sharding-Proxy
中间件形式, 单一职责原则, 维护方面
需要创建逻辑库、逻辑表,
AT模式 (最常使用的模式)
TC 事务协调者
Seata Server 就是 TC事务协调者
XID 全局事务ID
RM 资源管理器
你的每个服务就是资源管理器， 也就是事务参与者
TM 事务管理者
比如用户下单场景请求了交易服务， 交易服务调用了订单、积分服务。 那这个场景下交易服务就是 TM
XID 全局事务ID
Branch ID 分支事务ID
当事务发起者感知到其他的事务参与者出错时。 他就可以根据分支事务ID (Branch ID) 找到全局ID （XID）， 由全局ID通知协调者 TC。 TC知道到需要回滚后将回滚指令下发给所有RM
实现这种AT模式， 需要一个全局锁。 基本思想是和2PC一样的。
2PC的情况是复杂业务下锁粒度太大。性能低。
但 Seata 有奇淫巧计， 他这个中间件需要连数据库建表才能使用， 这个表就是 undo_log 表。
引入 Seata 的SDK后， 他会给你在 jdbc 层生成代理 拦截你的所有SQL。 然后每次独立事务都会提交， 将事务提交前后的信息维护在 undo_log 表里
如果分布式事务过程中某个环节出错了， 那就像上面说的一样回滚。 这个回滚借助的就是 undo_log 表里记录的信息， 通过这个信息反向给他 update 回去。
这样一次微服务调用过程中所有经过的节点的事务都实际提交了， 锁也就是分散的小锁了。 性能比传统 2PC 高很多。
