‘壹’ spring中如何使用策略模式
这里使用登录做例子介绍如何实现登录的多种策略
上图是策略模式的基础模型。
context
Context上下文角色，也叫Context封装角色，起承上启下的作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化。
Strategy
策略角色，接口类，封装相同类型策略公共方法，具体策略实现算法
ConcreteStrategy
具体策略实现Strategy中的抽象方法，编写具体算法实现。
至此基本的策略模式就说完了，具体实现看下面在spring中我们如何实现这种策略模式来实现多种登录方式：
在spring中怎样实现Context 上下文角色
/**
}
具体策略实现
@Component
@Slf4j
public class PhoneChatLoginStrategy implements LoginService {
@Override
public LoginType getLoginType() {
return LoginType.PHONE;
}
}
@Component
@Slf4j
public class WeChatLoginStrategy implements LoginService {
@Override
public LoginType getLoginType() {
return LoginType.WE_CHAT;
}
}
每个策略我们提供了一个枚举，这样方便我们取具体策略。
public enum LoginType {
QQ,
WE_CHAT,
PHONE;
}
我们这里写了两个登录策略，具体调用：
@RestController
@RequestMapping("/user")
@Slf4j
public class PublicUserController {
@Autowired
private LoginStrategyFactory loginStrategyFactory;
}
这样我们就完成了在spring中使用策略模式完成多种登录策略。
‘贰’ Spring Tx源码解析(二)
上一篇 我们介绍了 spring-tx 中的底层抽象，本篇我们一起来看看围绕这些抽象概念 spring-tx 是如何打造出声明式事务的吧。笼统的说， spring-tx-5.2.6.RELEASE 的实现主要分为两个部分：
这两部分彼此独立又相互成就，并且每个部分都有着大量的源码支撑，本篇我们先来分析 spring-tx 中的AOP部分吧。
EnableTransactionManagement 注解想必大家都很熟悉了，它是启用 Spring 中注释驱动的事务管理功能的关键。
EnableTransactionManagement 注解的主要作用是向容器中导入 ，至于注解中定义的几个属性在 Spring AOP源码解析 中有过详细分析，这里就不再赘述了。
由于我们并没有使用 AspectJ ，因此导入容器的自然是 这个配置类。
这个配置类的核心是向容器中导入一个类型为 的Bean。这是一个 PointcutAdvisor ，它的 Pointcut 是 ， Advice 是 TransactionInterceptor 。
利用 TransactionAttributeSource 解析 @Transactional 注解的能力来选取标注了 @Transactional 注解的方法，而 TransactionInterceptor 则根据应用提出的需求（来自对 @Transactional 注解的解析）将方法增强为事务方法，因此 可以识别出那些标注了 @Transactional 注解的方法，为它们应用上事务相关功能。
TransactionInterceptor 能对方法进行增强，但是它却不知道该如何增强，比如是为方法新开一个独立事务还是沿用已有的事务？什么情况下需要回滚，什么情况下不需要？必须有一个‘人’告诉它该如何增强，这个‘人’便是 TransactionAttributeSource 。
@Transactional 注解定义了事务的基础信息，它表达了应用程序期望的事务形态。 TransactionAttributeSource 的主要作用就是解析 @Transactional 注解，提取其属性，包装成 TransactionAttribute ，这样 TransactionInterceptor 的增强便有了依据。
前面我们已经见过， spring-tx 使用 来做具体的解析工作，其父类 定义了解析 TransactionAttribute 的优先级，核心方法是 computeTransactionAttribute(...) 。
默认只解析 public 修饰的方法，这也是导致 @Transactional 注解失效的一个原因，除此之外它还实现了父类中定义的两个模板方法：
同时为了支持 EJB 中定义的 javax.ejb.TransactionAttribute 和 JTA 中定义的 javax.transaction.Transactional 注解， 选择将实际的提取工作代理给 TransactionAnnotationParser 。Spring 提供的 @Transactional 注解由 进行解析。
的源码还是很简单的，它使用 AnnotatedElementUtils 工具类定义的 find 语义来获取 @Transactional 注解信息。 RuleBasedTransactionAttribute 中 rollbackOn(...) 的实现还是挺有意思的，其它的都平平无奇。
RollbackRuleAttribute 是用来确定在发生特定类型的异常（或其子类）时是否应该回滚，而 NoRollbackRuleAttribute 继承自 RollbackRuleAttribute ，但表达的是相反的含义。 RollbackRuleAttribute 持有某个异常的名称，通过 getDepth(Throwable ex) 算法来计算指定的 Throwable 和持有的异常在继承链上的距离。
程序猿只有在拿到需求以后才能开工， TransactionInterceptor 也一样，有了 TransactionAttributeSource 之后就可以有依据的增强了。观察类图， TransactionInterceptor 实现了 MethodInterceptor 接口，那么自然要实现接口中的方法：
可以看到， TransactionInterceptor 本身是没有实现任何逻辑的，它更像一个适配器。这样分层以后， TransactionAspectSupport 理论上就可以支持任意类型的 Advice 而不只是 MethodInterceptor 。实现上 TransactionAspectSupport 确实也考虑了这一点，我们马上就会看到。
invokeWithinTransaction(...) 的流程还是非常清晰的：
第一步前文已经分析过了，我们来看第二步。
TransactionInfo 是一个非常简单的类，我们就不费什么笔墨去分析它了。接着看第三步，这一步涉及到两个不同的操作——提交或回滚。
至此， TransactionInterceptor 于我们而言已经没有任何秘密了。
本篇我们一起分析了 spring-tx 是如何通过 spring-aop 的拦截器将普通方法增强为事务方法的，下篇就该说道说道 PlatformTransactionManager 抽象下的事务管理细节啦，我们下篇再见~~
‘叁’ 设计模式-Spring中常用的设计模式
设计模式是一种思想，是一种更快更好更优雅地解决问题的一种思想。这种思想在很多优秀的框架中都有落地。比如 Spring 框架。
接下来，我将从我的角度出发，粗浅的想一下，Spring 框架中常用的一些设计模式。
Spring 框架核心解决的问题是什么呢？个人理解是为了解决对象之间复杂的依赖关系，降低耦合。或者可以这么说，做项目我们也可以什么框架都不用，实现功能的时候，创建多个类，自己去维护类什么时候创建、使用、销毁等生命周期以及类之间的关系。自己维护的很好或者功能很简单的话，也可以不使用框架。框架本身也就是一个黑盒工具而已，开源使我们可以将其白盒化。
既然Spring框架的核心内容假设是解决对象之间复杂的依赖关系。 通俗来说便是“要啥给啥”。为了实现这个目的，Spring 核心的 IOC 容器出现了，对象都放在这个容器里，需要的时候从里面取。那就涉及到几点：
1. 创建对象，保存对象，保存对象之间的关联关系
2. 获取对象
涉及到如何创建，是只创建一次还是创建多次，有关联关系，先创建A还是先创建B等。 单例模式、原型模式、工厂模式、策略模式 可以来帮忙。
工厂模式：
Spring 中的 BeanFactory、FactoryBean
单例模式 ：
保证一个类仅有一个实例，并提供一个全局访问点。Spring 下默认创建的 Bean 都是单例对象。
常用的单例模式写法又有很多：最简单的就是 懒汉式了，还有 饿汉式、注册式、序列化方式、枚举方式等。
原型模式 ：
Java 中的克隆对象。以某个对象为原型，复制出一个新的对象。两个对象内容相同，但是对象实例不同。
用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。
策略模式：
一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。
在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。
定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
获取对象的时候，有策略方法，也可以通过代理进行功能增强等。策略模式、代理模式、模板方法模式、适配器模式、装饰器模式等
代理模式：
为其他对象提供一种代理以控制对这个对象的访问。从结构上来看和 装饰器模式类似， 但 Proxy 是控制，更像是一种对功能的限制，而 装饰器是增加职责。
Spring 的 AOP 代理，应该是很出名的。JdkDynamicAopProxy、Cglib2AopProxy。
模板模式：
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。比如 JdbcTemplate
适配器模式 ：
将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
Spring AOP 模块对 BeforeAdvice、AfterAdvice、ThrowsAdvice 三种通知类型的支持实际上是借助适配器模式来实现的，这样的好处是使得框架允许用户向框架中加入自己想要支持的任何一种通知类型，上述三种通知类型是 Spring AOP 模块定义的，它们是 AOP 联盟定义的 Advice 的子类型。
属于结构型模式，适配类与被适配类之间没有必然联系。满足 has-a 关系。
装饰器模式 ：
属于结构型模式。满足 is-a 关系。
Spring 中用到的包装器模式在类名上有两种表现：一种是类名中含有 Wrapper，另一种是类名中含有 Decorator。基本上都是动态地给一个对象添加一些额外的职责。
观察者模式：
定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象 都得到通知并被自动更新。
当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。
Spring 中 Observer 模式常用的地方是 Listener 的实现。如 ApplicationListener。
‘肆’ Spring Security PasswordEncoder
Spring Security使用单向密码转换存储密码，也就是加密后的用户密码无法恢复成明文，只能用作密码比较。另外随着计算机性能的提升，传统的SHA-256哈希加密方式不再安全。Spring Security采用了自适应单向加密方式，它通过刻意消耗计算机计算能力来加强密码被破解的难度，比如一个密码加密一次需要100毫秒，可能破解整个系统的密码只需要几小时，如果一个密码加密一次需要1秒那么破解整个系统的密码就需要几天。以 BCryptPasswordEncoder 为例，它内部有一个叫 strength 的工作因素，其值范围是4~31，值越大其循环加密的次数就越多。
当通过 BCryptPasswordEncoder.encode 进行加密的时候， strength 这个参数会被附加到 salt 中， BCrypt.hashpw 通过 salt 获取 strength ，然后通过 BCrypt.crypt_raw 来使用。
在 BCrypt.crypt_raw 中的入参 log_rounds 就是之前提到的 strength ，它通过 rounds = 1 << log_rounds; 左移获得一个循环数，最终通过该循环数提高整个加密过程的计算能力消耗。
PasswordEncoder 接口是Spring Security提供的统一密码接口，主要为整个安全框架提供一个统一的加密过程。其主要的实现类如下:
DelegatingPasswordEncoder 是Spring Security默认使用的加密算法。我们从它的名称其实可以猜测出来它本身并不是一个具体的算法实现类，而是一个算法代理类。这个类主要目的是兼容老旧系统，方便老旧系统的升级改造。
DelegatingPasswordEncoder 可以通 PasswordEncoderFactories.() 来创建一个默认的实现方式。
PasswordEncoderFactories.() 会首先创建一个 Map ，然后将各种 PasswordEncoder 的具体算法对象存入 Map 中。那么如何使用 DelegatingPasswordEncoder 呢？
以上就是 DelegatingPasswordEncoder 所存储的密码例子，其具体格式如下
其中 {id} 就是所使用的加密算法， encodedPassword 就是 {id} 所对应的具体加密算法加密后的值。
以 {bcrypt} 为例， DelegatingPasswordEncoder 会首先解析出 {bcrypt} ，然后在 Map 中查找具体的实现算法，最终由 BCryptPasswordEncoder 来完成加密或匹配过程。