1. 被小事化大这个直觉压住的一次选型先说结论项目里只有十几个事件场景、峰值 TPS 撑死几百、团队里也没有专职运维同学的时候我宁可先不碰消息队列也不想去舞台上搭一个专业班子来演一场小区联欢会。这个项目做的是某后台管理系统的基础底座核心诉求是用户资料变更后需要同步刷新搜索索引、清理缓存、给审计日志落一条记录偶尔还要给运营发一个站内通知。都是非常典型的事件发生后做点后续动作的场景。第一反应当然是用消息队列因为解耦削峰异步化这些词太熟了熟到几乎不用过脑子。但真把 RabbitMQ 或者 Kafka 这类组件拉进来之后我停下来算了一笔账越算越觉得不对劲。这笔账主要有三笔第一部署链路变长了。原来一个服务包起来就能跑引入 MQ 之后至少要保证 Broker 高可用生产环境至少得两个节点还要考虑持久化目录、磁盘监控、网络分区。哪怕用云上的托管服务也多了控制台、配额、topic 管理这些东西。第二业务团队的使用门槛变高了。事件的发送方式、消费组的分配、ack 机制、backlog 积压每个概念都需要理解一旦理解不到位出问题的时候排查链路非常长。一个内部运营系统我不想让同事们打开代码先被消费者组这个概念绊一跤。第三收益被严重稀释。我们的峰值流量不高异步处理的场景也不在乎秒级延迟队列积压几乎不可能发生。所谓的削峰填谷、流量洪峰保护在这里根本触发不了。所以当时我给了自己一个非常明确的判定标准在没有吞吐量和跨团队协作硬约束的前提下先不要引入外部消息中间件而是用一个进程内的事件分发机制解决问题。如果未来真的出现量级变化再平滑迁移。现在回头复盘这个决定让我在后面几次迭代里省掉了大量麻烦。1.1 真实需求拆解到底需要解什么耦做技术选型最忌讳的是只看别人都用 MQ所以我也用。我把需求摊开之后发现本质上就四类动作主流程完成后触发旁路动作比如保存用户资料成功后通知搜索服务更新索引主流程不关心旁路动作的结果索引更新失败不能回滚用户资料保存旁路动作之间有先后关系比如先刷新缓存再统计活跃度某些动作需要的不是实时响应而是过一会儿执行比如延迟五分钟给用户发欢迎语。这四类需求传统 MQ 能解决但解决的背后是引入一整套分布式消息语义。可实际上我们只有一个单体应用最多拆成几个模块部署也在同一批机器上根本不存在跨网络、跨机房、跨团队的强隔离诉求。这种情况下进程内事件总线加一个异步线程池已经能覆盖绝大多数场景。换句话说解耦的目标不是物理上把消息送到另一台机器而是逻辑上让调用方不依赖被调用方的实现细节同时不让旁路逻辑阻塞主流程。这个目标一个设计得体的事件引擎完全做得到。1.2 三个硬约束决定了我不可能直接上 MQ个约束是团队规模。项目组算上我只有四个人每人都在同时参与两三个业务模块。引入 MQ 看似只是接一个客户端库实际上意味着会多出集群怎么搭、磁盘满没满、消费 lag 多少这类日常照料工作。不是说 MQ 有多难而是它带来的心智负担会持续性地分摊在每个人身上这是隐性成本里最重的一块。第二个约束是发布节奏。我们平均两周迭代一个版本经常一天上线两三次。如果用外部 MQ那么事件结构变更要兼容生产环境和多个消费者还要处理滚动升级时的消息格式切换。每次改动都像走钢丝。进程内事件引擎则没有这个包袱事件只是普通的 Java 对象代码改完跟着应用一起发布状态天然一致。第三个约束是问题排查。之前在一家公司见过一次线上事故某个消费者逻辑抛异常消息一直重投队积压越来越大最后把磁盘塞满。定位问题花了整整半天最后发现是配置中心的消费线程数被误改成了 1。这种问题不是高频出现但一旦出现就要搭上半条命。在体量这么小的系统里我选择把所有失败逻辑收拢在代码层面而不是散落在 Broker 的运维参数里。1.3 那为什么不直接写个简单 if 调用非要搞引擎说到这你可能会问既然场景这么简单直接在业务方法里顺序调用不就行了还引擎个什么劲顺序调用当然能跑但很快会腐烂。今天加一个索引更新的明天在 controller 里加一行后天加一个日志记录的再往 service 里塞一段。用不了多久核心业务方法里会塞满各种旁路调用。更麻烦的是这些旁路逻辑一旦报错会把主流程也拖下水——缓存更新失败的时候用户资料保存也回滚这肯定不是我们想要的。事件引擎的价值在这里体现得非常具体它把旁路逻辑从主流程里抽离出去用发布事件代替直接调用方法。调用方不再知道也无需知道谁在监听这个事件、监听者做得好不好主流程只对自己负责。同时通过控制分发方式是同步还是异步、异常处理是忽略还是重试可以让整个系统的边界清晰得多。换句话说一个最小可用的事件引擎其实是在代码组织层面做了一次解耦重构而不是在架构层面引入一套基础设施。这两者经常被混为一谈但实际上是完全不同的决策。2. 引入 MQ 的真正隐性成本不只是多了一台机器很多人做技术选型的时候喜欢把接入成本框定为我在 pom 里加一个依赖写两行配置。真这么想就大错特错了。2.1 运维层面的蝴蝶效应消息队列一旦上了生产它就不是一个依赖库而是一个基础设施。基础设施意味着 7x24 待命。磁盘告警了你要管Broker CPU 飙了你要查客户端连接断了你要追溯版本升级要挑窗口。哪怕用的是云托管服务控制台的指标、报警规则、topic 分区数、消息保留时间这些参数依然要有人拍板。在一个没有专职 SRE 的小团队里这些工作都是摊到每个开发头上的。你说就用最简单的单机模式不就行了可以啊但单机模式一旦宕机所有异步链路停摆这个锅最后还是回到你头上。我见过最现实的场景是一个通知任务依赖 MQ某天 Broker 因为磁盘满了挂掉消息发不出去用户没收到通知。排查半小时后确认是磁盘问题可那半小时里业务方已经在群里问了三次是不是你们的系统 bug。基础设施引入越多这种非业务故障就会越多而它们通常比业务故障更难解释。2.2 调试链路会显著变长本地开发的时候MQ 环境不是每个人都有。要么连测试环境影响别人调试要么本地起一个 Broker吃内存不说还经常跟其他的 mock 数据对不上。每次排查问题都要在生产 Broker—测试环境—本地代码之间来回切换视角。事件引擎就没有这个问题。不用起中间件进程内直接断点调试事件从发布到消费的完整链路一目了然。对一线开发来说这个体验差距是决定性的。2.3 性能被过度设计反噬消息队列的设计目标是支撑高吞吐、大规模、分布式场景所以它天然带了一堆协议层、网络层、持久化层的开销。我们是一个内部系统峰值 QPS 几百很多事件一天也就上万条。对这些流量来说本地方法调用和 MQ 的网络 IO在耗时上差两三个数量级用户完全感知不到。但代价却是多了一大坨需要维护的架构组件。我更愿意把资源留给真正有价值的复杂度。这套轻量引擎经过实测单节点每秒处理几万条事件毫无压力完完全全覆盖我们的业务场景。既然用不上那 99% 的能力凭什么要为那 1% 的场景付 100% 的账单呢。3. 核心设计从事件总线到订阅分发一套 800 行的干净模型确定自研之后我按绝不引入额外中间件、进程内解决、接口保持可替换三个原则来设计。目标不是写一个能跟 RabbitMQ 比肩的东西而是写一个刚好够用、逻辑足够清楚、后面迁移方便的轻量模型。3.1 整体模型三类核心角色整个引擎抽象成三个角色事件Event一个普通的业务对象描述发生了什么比如UserUpdatedEvent里面只有业务数据和事件 ID。 发布器Publisher只负责把事件交给总线不关心谁会处理。 订阅器Subscriber注册自己的兴趣类型收到事件后执行具体逻辑。三者之间通过事件类型完成关联。订阅器不允许直接拿到发布器的引用发布器也不会感知订阅器的存在。这是最基本的解耦语义。我还特意加了一个事件 ID字段。很多初版事件引擎会忽略这个字段但它对后期的幂等、排查、链路追踪都极其重要。建议所有事件从第一天就带上全局唯一 ID别等出问题再补。3.2 同步还是异步这是个可配置项实际业务里头有的旁路动作希望跟随主流程同生共死比如审计日志主流程事务提交后必须把日志落库有的则完全无所谓比如通知消息晚几秒也无妨。所以我在注册订阅器的时候允许指定模式SYNC发布时直接在当前线程执行订阅逻辑异常默认上抛由发布方决定如何处理ASYNC丢给线程池异步执行主流程立即返回异常由引擎内部统一捕获处理SYNC_ORDERED同类型事件按提交顺序依次执行保证顺序性。这也是自研引擎最灵活的地方。用 MQ 方案时同步和异步往往要通过不同的事务消息模式去凑在这里只是一个枚举值。举一个实际例子用户注册接口里发布UserRegisteredEvent其中写审计日志是 SYNC因为审计必须跟主事务保持一致发欢迎信是 ASYNC因为不能因为欢迎信超时就阻塞用户注册。一个接口里两种模式共存代码依然干净可读。3.3 核心代码的骨架不是炫技是利益分配下面这段可以看作整个引擎的最小可运行版本。为了保持可读性我去掉了泛型复杂的部分保留了最核心的注册、发布、异步分发的骨架。public class LightEventBus { private final MapClass?, ListHandlerInvoker registry new ConcurrentHashMap(); private final ExecutorService asyncExecutor; private final RetryPolicy retryPolicy; public LightEventBus(ExecutorService asyncExecutor, RetryPolicy retryPolicy) { this.asyncExecutor asyncExecutor; this.retryPolicy retryPolicy; } public T void subscribe(ClassT eventType, DispatchMode mode, EventHandlerT handler) { registry.computeIfAbsent(eventType, k - new CopyOnWriteArrayList()) .add(new HandlerInvoker(handler, mode)); } public T void publish(T event) { ListHandlerInvoker invokers registry.get(event.getClass()); if (invokers null || invokers.isEmpty()) { log.warn(no subscriber for event: {}, event.getClass().getSimpleName()); return; } for (HandlerInvoker invoker : invokers) { if (invoker.mode() DispatchMode.SYNC) { invoker.invoke(event); } else if (invoker.mode() DispatchMode.ASYNC) { asyncExecutor.execute(() - invoker.invokeWithRetry(event, retryPolicy)); } else { // SYNC_ORDERED 需要按事件类型加锁这里略去分布式锁细节 orderedExecutor.execute(() - invoker.invokeWithRetry(event, retryPolicy)); } } } }这个骨架最值得注意的有两点。第一CopyOnWriteArrayList在事件订阅较少、读多写少的场景下非常合适订阅者注册基本发生在启动阶段运行时几乎不修改所以读取不需要加锁性能很好。如果你的事件订阅是动态增减的那需要换线程安全的集合但这个场景比较少。第二HandlerInvoker把 handler、mode、重试策略收拢到一个对象里这样分发的语义就不会散落在各个订阅方。订阅方只需要关心收到事件后干什么不需要管失败怎么重试、超时怎么处理让业务代码保持纯粹。这里我想特别提醒一件事不要一上来就做支持跨进程、支持持久化、支持事务消息这些扩展。你这个阶段要解决的核心问题是模块间解耦不是分布式可靠传输。过度设计是个人项目最常见的死法。等哪天真要跨进程了把LightEventBus的publish方法实现替换成 MQ 客户端的调用订阅端代码几乎不用改因为接口已经帮你兜住了。4. 可靠性细节越轻量越要把失败逻辑设计明白轻量并不意味着草率。恰恰相反因为没有外部 Broker 帮你处理消息持久化、重投、死信所有可靠性问题全都要自己面对。这个部分我花了最多时间也踩了最多坑。4.1 最容易被忽略的事务边界事件发布放在事务内还是事务外这个问题很容易被忽略。最常见的错误是业务代码里先提交事务再发布事件。这样如果提交后、发布前应用进程崩溃事件就丢了反过来如果在事务内发布事件订阅器同步执行时又去访问数据库可能会读到未提交的数据或者因为长事务把连接池打满。我的处理方式比较偏保守对于强一致要求把事件落库和业务更新放在同一个本地事务里事务提交后再触发订阅器执行。这一步通过TransactionSynchronization的回调实现Spring 场景会有很多现成钩子对于弱一致场景先提交业务再发布异步事件允许极端情况下丢失不允许在事务内同步执行会访问数据库的订阅逻辑。这个设计源于一次线上事故用户在创建订单时发布了事件订阅器里又去查订单表由于事务还没提交订阅器按照不存在该订单走了异常分支最终数据对不上。排查了很久才定位到是事务隔离级别的问题。4.2 重试但不能无脑重试异步订阅失败以后怎么办我们的做法是给每一次异步执行设置三层重试。第一层是即时重试最多重试 3 次每次间隔按指数退避 200ms、400ms、800ms。第二层是记录失败事件到本地失败表相当于一个死信队列由定时任务扫描重放。第三层是告警连续失败超过阈值就通知开发人员介入。这很像一个简化版的 MQ 重投机制但实现成本极低。失败表就是一张数据库表字段就那些事件 ID、事件类型、事件内容、失败原因、失败次数、下次重试时间。定时任务每五分钟扫一次把到期的记录重新发布到事件总线里。这个思路特别适合不引入 MQ 但还想保留可靠性兜底的中小系统。这里有一个细节重放的时候订阅器一定要做幂等。因为失败表里的记录可能被重放多次如果订阅器不具备幂等性重复发通知重复扣积分这种问题就会出现。审计场景下甚至会出现日志重复写入。所以我在事件基类里放了全局唯一 ID订阅器在核心逻辑入口先检查一条记录是否已处理过用唯一索引兜住。4.3 顺序问题要还是不要自己说了算消息队列经常吹的顺序性到了自研引擎这里变成了一件可管理的事情。我们有一个场景用户连续修改了两次资料第二次修改依赖于第一次修改落库后的最新状态。如果两个事件被不同线程并发消费顺序颠倒缓存里就会留下旧数据。为了解决顺序我给同类型同步事件加了一个按业务主键分组的顺序执行器类似于同一个用户的修改事件必须串行处理。实现方式非常简单用ConcurrentHashMapString, ReentrantLockkey 是业务主键每次分发给同一个 key 的事件前先抢同一把锁。再进阶一步可以做成 keyed executor把相同 key 的任务交给同一个单线程线程池处理。这些都是几行代码的事却精准地解决了产品痛点。但我也要泼一盆冷水顺序保证是有代价的它会降低并发度。所以默认不开启顺序模式只对特定订阅器开启。不要为了看起来严谨给全系统上顺序锁最后只会拖累整体吞吐。5. 让轻量引擎顺利上线测试设计、监控指标、压力结果自研组件最大的风险不是功能做不出来而是不敢上线。为了让自己睡得着觉我把测试和监控提到了和功能实现一样的优先级甚至更高。5.1 测试策略事件引擎怎么证明自己没问题事件引擎的核心逻辑是全内存的所以单元测试非常直接。注册一个订阅器publish 一个对象断言订阅器被调用了、参数正确、异常场景下走了重试逻辑。关键测试点有四个同一事件多个订阅器是否都被调用异常订阅器是否会阻断同事件的其他订阅器我们要求互不干扰异步模式下线程池满时的拒绝策略是什么我选择了 CallerRunsPolicy宁可让主线程多等一会儿也不丢事件幂等测试同一个事件重放两次业务结果一致。集成测试反而要更小心。我在测试环境里模拟过一次订阅器抛异常后失败表不断重试的场景确认告警能触发、手动重放按钮能用、管理员能从后台看到每个事件的状态。这些是运营人员真正会依赖的救命功能不在测试里提前跑一遍上线后出了事会很被动。5.2 监控与追踪没有中间件反而更容易观测很多人觉得没有 MQ 就少了监控抓手其实恰恰相反。因为事件就在进程里流转我可以在发布器入口、订阅器出口埋点收集到比 MQ 更精确的指标每种事件的发布量和订阅消费量单次事件从发布到所有订阅执行完成的耗时失败次数、重试次数、重试失败次数线程池队列深度、活跃线程数。我把这些指标暴露到已有的监控系统里再配上告警事件积压超过阈值就报警因为这意味着线程池处理不过来主流程可能马上被拖慢。另外一个特别有用的追踪点是事件发布时带上 traceId订阅器执行时在日志里打上同样的 traceId这样从 HTTP 请求进来、业务发布事件、多个订阅器消费一条链路全都能串起来排错速度大大提升。5.3 压测数据心里有底才敢把自研二字说出口我专门写了一个压测程序模拟用户注册接口频繁发布事件的场景。用的是 4C8G 的普通容器JVM 堆 2G线程池核心线程 8 个、最大 16 个队列容量 1000。结果出来以后我自己都愣了一下场景每秒发布事件数订阅器平均耗时P99 耗时3 个同步订阅器82001.2ms3.8ms3 个异步订阅器12500调度耗时 0.1ms1.5ms混合 2 同步 2 异步98001.0ms3.2ms这个数据说明在本项目的量级下引擎性能完全不是瓶颈。瓶颈只会出现在某个订阅器自身逻辑太慢的场景。之后我把耗时监控挂在每个订阅器上一旦某个订阅器平均耗时超过 100ms会自动告警促使开发者排查订阅逻辑本身。6. 什么时候我坚决不推荐自研边界条件和演进路线写了这么多自研的好处我必须把丑话说在前头。轻量事件引擎不是全能的它有一个明确的使用边界。越界使用就是把玩具当生产工具早晚出大事。6.1 六个该上 MQ 就别犹豫的信号我总结了六个指标只要命中大半就说明到了引入正式消息队列的时候需要跨语言协作。多个技术栈的服务需要通过消息交互进程内事件引擎没法覆盖需要跨机房或跨区域部署。消息需要在网络隔离的环境中可靠传输落到数据库表里重放极不优雅流量峰值不确定或极高。比如电商秒杀、运营大促等场景进程内线程池很容易被打穿多个独立团队维护各自的消费者彼此发布节奏不耦合。MQ 的 topic 管理和消费组模型能提供更清晰的边界对可靠性和审计有强要求每条消息的完整生命周期都要有记录和重放能力系统里已经有成熟的 MQ 基础设施团队也具备运维经验。这时候没必要为了少用组件而自找麻烦。只要命中三条以上就该老实评估一下完整的 MQ 方案了。自研引擎的价值在于规避复杂度但如果业务复杂度已经超过它的承载能力那它就会从资产变成负债。6.2 演进路线从自研到 MQ不该是推倒重来我特意把EventBus的核心接口抽象出来就是为了未来有一天能平滑替换。publish 和 subscribe 这两个动作保持稳定替换底层实现时业务代码可以基本不动。具体演进策略我打算分三步第一步将LightEventBus的发布实现从进程内分发改为把事件写入一个外部的持久化 Store可以是关系型数据库也可以是一个成熟的流式存储保留进程内订阅分发但事件不再会因进程崩溃而丢失。第二步当跨团队、跨语言诉求出现时才把订阅端也迁移到真正的消息队列消费者独立部署、独立扩容用 MQ 原生的消费组机制管理进度。第三步把失败表、重试、死信这些逻辑慢慢废弃掉交给 MQ 原生的死信队列和重投机制去接管。这条路线实际上是从业务解耦到架构解耦的自然升级而不是突然推翻重来。很多团队就是不敢走第一步非要一上来就上大 MQ结果复杂度直接爆表也有团队死守自研引擎明明业务量已经起飞了还嘴硬说够用最后整个系统的稳定性被别人质疑。两边都不可取。6.3 一个小忠告选型文档要写上何时推翻自己最后分享一个很个人的习惯。我在项目文档里专门留了一节叫本方案的失效条件里面写清楚了当什么指标出现的时候必须放弃当前方案。比如单日事件量稳定超过 100 万出现第三个技术栈需要消费事件订阅器数量超过 50 个团队里有两个人明确表示维护事件引擎太痛苦了。写上这一节不是为了显得严谨而是为了给自己的未来留一条冷静的退路。人很容易对自己写的东西产生感情尤其是亲自设计的组件大脑会自动屏蔽它的缺点。把触发条件提前写死在文档里等于提前给未来的自己做了一道安全护栏。我在这个项目里最终没有直接上 MQ但我并不排斥 MQ。整个过程真实感受是技术选型没有高级和低级之分只有合适与不合适的区别。一套轻量事件引擎能以一敌百的时候别让架构的重量拖垮业务的敏捷真到它撑不住的时候也需要有勇气把它换下来让 MQ 站到它该站的位置上。
