我真的很小心了，但还是被 SpringEvent 坑了！

五阳
16,076 阅读5分钟

网络上比较推崇使用Spring Event 优雅的实现观察者模式。我在调研后也确实觉得这种方式能实现业务逻辑上的解耦，但线上的一次事故，让我意识到 Spring Event远远没有那么简单。

image.png

前几天，线上系统出现两条异常日志Get Bean时找不到对应的bean，调用堆栈让我非常迷惑，为什么Get Bean找不到对应的Bean呢? 堆栈中的信息 解释了原因。

Do not request a bean from a BeanFactory in a destroy method implementation

在应用上下文关闭时，不得从上下文中Get Bean。 恰好，问题出现在服务关闭期间..... 由于系统流量较高，日订单几百万，即便在低峰期单机的并发度也是比较高的，所以服务在关闭期间有少量流量进来或未处理完。

要明白问题原因和解决办法，需要先简单了解 Spring Event如何使用，总共分为三步。

  1. 声明事件
  2. 发布事件
  3. 监听事件

声明事件

自定义事件需要继承Spring ApplicationEvent。我选择使用泛型，支持子类可以灵活关联事件的内容。

public class BaseEvent<T> extends ApplicationEvent {
    private final T data;
    
    public BaseEvent(T source) {
        super(source);
        this.data = source;
    }

    public T getData() {
        return data;
    }
}

发布事件

使用Spring上下文 ApplicationContext发布事件

applicationContext.publishEvent(new BaseEvent<>(param));

Idea为Spring提供了跳转工具，点击绿色按钮位置，就可以 跳转到事件的监听器列表。

image.png

监听事件

监听器只需要 在方法上声明为 EventListener注解，Spring就会自动找到对应的监听器。Spring会根据方法入参的事件类型和 发布的事件类型 自动匹配。

@EventListener
public void handleEvent(BaseEvent<PerformParam> event) {
    //消费事件
}

我遇到的线上问题恰恰出现在发布事件后，Spring匹配Listener时，Spring需要从上下文中Get Bean，每发布一次事件需要Get Bean一次。正常情况下没事，在服务关闭期间，如果恰好发布了一个事件，就凉了。

在调研Spring Evnet期间，我重点考虑了使用方式，使用的优缺点，但确实没有想到Spring会有这个缺陷。如何避免这个问题呢？

  1. 弃用SpringEvent。
  2. 允许Spring Event 出现异常，但上层调用捕获异常，上报MQ重试。
  3. 彻底服务优雅关闭。Rpc、Http、MQ入口在进程关闭前，先禁用流量。

结合三个方案的改动成本，我选择忍痛弃用Spring Event。

这件事让我明白了，全面调研真的很困难，某些框架确实很好用，但没准在哪个点上就有坑。有时候保守不是一件坏事，至少能保证线上环境能稳定运行啊。

我的开源项目

最后夹带一点私货，五阳最近花了3个月的时间完成一个开源项目。

开源3周以来，已有近 230 多个关注和Fork

Gitee：gitee.com/juejinwuyan…

GitHub github.com/juejin-wuya…

开源平台上有很多在线商城系统，功能很全，很完善，关注者众多，然而实际业务场景非常复杂和多样化，开源的在线商城系统很难完全匹配实际业务，广泛的痛点是

  • 功能堆砌，大部分功能用不上，需要大量裁剪；
  • 逻辑差异点较多，需要大量修改；
  • 功能之间耦合，难以独立替换某个功能。

由于技术中间件功能诉求较为一致，使用者无需过多定制化，技术中间件开源项目以上的痛点不明显，然而电商交易等业务系统虽然通用性较多，但各行业各产品的业务差异化极大，所以导致以上痛点比较明显

所以我在思考，有没有一个开源系统，能提供电商交易的基础能力，能让开发者搭积木的方式，快速搭建一个完全契合自己业务的新系统呢？

  • 他们可以通过编排和配置选择自己需要的功能，而无需在一个现成的开源系统上进行裁剪
  • 他们可以轻松的新增扩展业务的差异化逻辑，不需要阅读然后修改原有的系统代码！
  • 他们可以轻松的替换掉他们认为垃圾的、多余的系统组件，而不需要考虑其他功能是否会收到影响

开发者们，可以择需选择需要的能力组件，组件中差异化的部分有插件扩展点能轻松扩展。或者能支持开发者快速的重新写一个完全适合自己的新组件然后编排注册到系统中？

memberclub 就是基于这样的想法而设计的。 它的定位是电商类交易系统工具箱， 以SDK方式对外提供通用的交易能力，能让开发者像搭积木方式，从0到1，快速构建一个新的电商交易系统！

image.png

具体介绍可参见

Gitee开源地址：gitee.com/juejinwuyan…

GitHub开源地址 : github.com/juejin-wuya…

在这个项目中你可以学习到 SpringBoot 集成 以下框架或组件。

  1. Mybatis、Mybatis-plus 集成多数据源
  2. Sharding-jdbc 多数据源分库分表
  3. redis/redisson 缓存
  4. Apollo 分布式配置中心
  5. Spring Cloud 微服务全家桶
  6. RabbitMq 消息队列
  7. H2 内存数据库
  8. Swagger + Lombok + MapStruct

同时你也可以学习到以下组件的实现原理

  1. 流程引擎的实现原理
  2. 扩展点引擎实现原理
  3. 分布式重试组件实现原理
  4. 通用日志组件实现原理 参考：juejin.cn/post/740727…
  5. 商品库存实现原理： 参考：juejin.cn/post/731377…
  6. 分布式锁组件： 参考：
  7. Redis Lua的使用
  8. Spring 上下文工具类 参考： juejin.cn/post/746927…
avatar
文章
阅读
粉丝