你有没有遇到过这种情况：在电商网站下单后，页面立刻弹出‘订单已提交’，但库存还没减、短信也没发？这背后很可能就是事件驱动架构在干活。系统先把‘下单成功’这件事记下来，再慢慢通知各个模块去处理各自的任务。
什么是事件驱动架构
简单说，就是系统不靠主动调用函数来推进流程，而是等某个“事件”发生——比如用户点击、文件上传、订单创建——然后触发对应的处理逻辑。就像你家门铃响了（事件），你才会去开门（动作），而不是一直站在门口等着人来。
在线购物的后台协作
你在某宝买了一件卫衣，点击付款那一刻，系统不会立刻去改库存、发短信、算推荐商品。它只是发布一个‘OrderPaid’事件。订单服务、库存服务、消息服务各自监听这个事件，收到后自行处理。哪怕短信服务临时挂了，其他功能照常运行，等它恢复后再补发也不迟。
文件上传后的自动处理
你在公司用网盘上传一份合同PDF，系统自动触发OCR识别文字、生成缩略图、同步到团队共享目录。这些动作都不是你在操作时手动点的，而是因为‘FileUploaded’这个事件被触发，下游服务自动响应。这种模式让功能解耦，加个新功能也不用改老代码。
实时聊天消息的传递
你用微信发一条消息，对方几乎秒收。这不是因为你俩的设备一直连着热线，而是消息服务接收到‘MessageSent’事件后，立刻推送给接收方。服务器不需要轮询数据库看有没有新消息，节省大量资源。这种即时性正是事件驱动的强项。
代码怎么写
以 Node.js 为例，可以用 EventEmitter 实现简单的事件机制：
const EventEmitter = require('events');
const eventBus = new EventEmitter();
// 监听订单支付事件
eventBus.on('OrderPaid', (orderId) => {
console.log(`开始处理订单 ${orderId} 的发货`);
});
// 某处触发事件
eventBus.emit('OrderPaid', '123456');监控系统里的告警联动
公司服务器CPU突然飙到95%，监控系统检测到后发出‘HighCPULoad’事件。运维机器人自动扩容，同时给管理员发钉钉提醒。这两个动作互不影响，但都基于同一个事件源。比起定时脚本轮询，响应更快，压力更小。
事件驱动不是什么高冷概念，它早就藏在你每天用的软件背后。当你发现系统反应快、出错少、扩展容易，很可能就是它在默默支撑。