在分布式系统中,我们会需要 ID 生成器的组件,这个组件可以实现帮助我们生成顺序的或者带业务含义的 ID。
目前有很多经典的 ID 生成方式,比如数据库自增列(自增主键或序列)、Snowflake 算法、美团 Leaf 算法等等,所以,会有一些公司级或者业务级的 ID 生成器组件的诞生。本文就是通过 BeanPostProcessor 实现动态注入 ID 生成器的实战。
在 Spring 中,实现注入的方式很多,比如 springboot 的 starter,在自定义的 Configuration 中初始化 ID 生成器的 Bean,业务代码中通过 @AutoWired 或者 @Resource 注入即可,开箱即用。这种方式简单直接,但是缺点也是过于简单,缺少了使用方自定义的入口。
考虑一下实际场景,在同一个业务单据中,要保持 ID 的唯一,但是在不同单据中,可以重复。而且,这些算法在生成 ID 的时候,为了保持多线程返回结果唯一,都会锁定共享资源。如果不同业务,并发情景不同,可能低并发的业务被高并发的业务阻塞获取 ID,造成一些性能的损失。所以,我们要考虑将 ID 生成器,根据业务隔离开,这样 springboot 的 starter 就会显得不够灵活了。
实现
根据上面的需求,我们可以分几步实现我们的逻辑:
自定义属性注解,用于判断是否需要注入属性对象 定义 ID 生成器接口、实现类,以及工厂类,工厂类是为了根据定义创建不同的 ID 生成器实现对象 定义 BeanPostProcessor,查找使用自定义注解定义的属性,实现注入自定义注解
首先自定义一个注解,可以定义一个 value 属性,作为隔离业务的标识:
1 2 3 4 5 6 7 8 9 10 |
@Retention (RetentionPolicy.RUNTIME) @Target ({ElementType.FIELD, ElementType.METHOD}) public @interface IdGeneratorClient { /** * ID 生成器名称 * * @return */ String value() default "DEFAULT" ; } |
定义 ID 生成器
定义 ID 生成器的接口:
1 2 3 4 5 |
public interface IdGenerator { String groupName();
long nextId(); } |
实现 ID 生成器接口,偷懒使用 AtomicLong 实现自增,同时考虑 ID 生成器是分组的,通过 ConcurrentHashMap 实现 ID 生成器的持有:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
class DefaultIdGenerator implements IdGenerator { private static final Map<String, AtomicLong> ID_CACHE = new ConcurrentHashMap<>( new HashMap<>()); private final String groupName;
DefaultIdGenerator( final String groupName) { this .groupName = groupName; synchronized (ID_CACHE) { ID_CACHE测试数据puteIfAbsent(groupName, key -> new AtomicLong( 1 )); } }
@Override public String groupName() { return this .groupName; }
@Override public long nextId() { return ID_CACHE.get( this .groupName).getAndIncrement(); } } |
如前面设计的,我们需要一个工厂类来创建 ID 生成器,示例中使用最简单的实现,我们真正使用的时候,还可以通过更加灵活的 SPI 实现(关于 SPI 的实现,这里挖个坑,后面专门写一篇填坑):
1 2 3 4 5 6 7 8 9 |
public enum IdGeneratorFactory { INSTANCE;
private static final Map<String, IdGenerator> ID_GENERATOR_MAP = new ConcurrentHashMap<>( new HashMap<>());
public synchronized IdGenerator create( final String groupName) { return ID_GENERATOR_MAP测试数据puteIfAbsent(groupName, key -> new DefaultIdGenerator(groupName)); } } |
定义 BeanPostProcessor
前面都是属于基本操作,这里才是扩展的核心。我们的实现逻辑是:
扫描 bean 的所有属性,然后找到定义了 IdGeneratorClient 注解的属性 获取注解的 value 值,作为 ID 生成器的分组标识 使用 IdGeneratorFactory 这个工厂类生成 ID 生成器实例,这里会返回新建的或已经定义的实例 通过反射将 ID 生成器实例写入 bean
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
public class IdGeneratorBeanPostProcessor implements BeanPostProcessor {
@Override public Object postProcessBeforeInitialization( final Object bean, final String beanName) throws BeansException { return bean; }
@Override public Object postProcessAfterInitialization( final Object bean, final String beanName) throws BeansException { parseFields(bean); return bean; }
private void parseFields( final Object bean) { if (bean == null ) { return ; } Class<?> clazz = bean.getClass(); parseFields(bean, clazz);
while (clazz.getSuperclass() != null && !clazz.getSuperclass().equals(Object. class )) { clazz = clazz.getSuperclass(); parseFields(bean, clazz); } }
private void parseFields( final Object bean, Class<?> clazz) { if (bean == null || clazz == null ) { return ; }
for ( final Field field : clazz.getDeclaredFields()) { try { final IdGeneratorClient annotation = AnnotationUtils.getAnnotation(field, IdGeneratorClient. class ); if (annotation == null ) { continue ; }
final String groupName = annotation.value();
final Class<?> fieldType = field.getType(); if (fieldType.equals(IdGenerator. class )) { final IdGenerator idGenerator = IdGeneratorFactory.INSTANCE.create(groupName); invokeSetField(bean, field, idGenerator); continue ; }
throw new RuntimeException( "未知字段类型无法初始化,bean: " + bean + ",field: " + field); } catch (Throwable t) { throw new RuntimeException( "初始化字段失败,bean=" + bean + ",field=" + field, t); } } }
private void invokeSetField( final Object bean, final Field field, final Object param) { ReflectionUtils.makeAccessible(field); ReflectionUtils.setField(field, bean, param); } } |
实现 BeanPostProcessor 接口需要完成 postProcessBeforeInitialization 和 postProcessAfterInitialization 两个方法的定义。下图是 Spring 中 Bean 的实例化过程:
从图中可以知道,Spring 调用 BeanPostProcessor 的这两个方法时,bean 已经被实例化,所有能注入的属性都已经被注入了,是一个完整的 bean。而且两个方法的返回值,可以是原来的 bean 实例,也可以是包装后的实例,这就要看我们的定义了。
测试我们的代码
写一个测试用例,验证我们的实现是否生效:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
@ SpringBoot Test class SpringBeanPostProcessorApplicationTests { @IdGeneratorClient private IdGenerator defaultIdGenerator; @IdGeneratorClient ( "group1" ) private IdGenerator group1IdGenerator;
@Test void contextLoads() { Assert.notNull(defaultIdGenerator, "注入失败" ); System.out.println(defaultIdGenerator.groupName() + " => " + defaultIdGenerator.nextId());
Assert.notNull(group1IdGenerator, "注入失败" ); for ( int i = 0 ; i < 5 ; i++) { System.out.println(defaultIdGenerator.groupName() + " => " + defaultIdGenerator.nextId()); System.out.println(group1IdGenerator.groupName() + " => " + group1IdGenerator.nextId()); } }
} |
运行结果为:
DEFAULT => 1
DEFAULT => 2
group1 => 1
DEFAULT => 3
group1 => 2
DEFAULT => 4
group1 => 3
DEFAULT => 5
group1 => 4
DEFAULT => 6
group1 => 5
可以看到,默认的 ID 生成器与定义名称为 group1 的 ID 生成器是分别生成的,符合预期。
文末思考
我们实现了通过 BeanPostProcessor 实现自动注入自定义的业务对象,上面的实现还比较简单,有很多可以扩展的地方,比如工厂方法实现,可以借助 SPI 的方式更加灵活的创建 ID 生成器对象。同时,考虑到分布式场景,我们还可以在 ID 生成器实现类中,通过注入 rpc 实例,实现远程 ID 生成逻辑。
玩法无限,就看我们的想象了。
源码
附上源码: https://github测试数据/howardliu-cn/effective-spring/tree/main/spring-beanpostprocessor
参考
Spring BeanPostProcessor Example Spring BeanPostProcessor推荐阅读
SpringBoot 实战:一招实现结果的优雅响应 SpringBoot 实战:如何优雅的处理异常 SpringBoot 实战:通过 BeanPostProcessor 动态注入 ID 生成器 SpringBoot 实战:自定义 Filter 优雅获取请求参数和响应结果 SpringBoot 实战:优雅的使用枚举参数 SpringBoot 实战:优雅的使用枚举参数(原理篇) SpringBoot 实战:在 RequestBody 中优雅的使用枚举参数 SpringBoot 实战:在 RequestBody 中优雅的使用枚举参数(原理篇)到此这篇关于SpringBoot之通过BeanPostProcessor动态注入ID生成器案例详解的文章就介绍到这了,更多相关SpringBoot之通过BeanPostProcessor动态注入ID生成器内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!
原文链接:https://HdhCmsTesthowardliu.cn/spring-beanpostprocessor/
查看更多关于SpringBoot之通过BeanPostProcessor动态注入ID生成器案例详解的详细内容...