事件的定义与"发送方不在乎"的核心特征

事件驱动系统近年愈发流行，核心驱动力是团队自主权的渴望和构建解耦系统的需要。事件指的是过去已经发生的事情——可以是纯技术事件（如界面上的”鼠标单击”），也可以是携带业务领域知识的领域事件（如订单履约里的订单状态变化）。一个自治的通知服务可以只监听这些领域事件、自行决定何时发通知给客户，好处有两个：实现团队不必和其他任何微服务团队沟通，只要遵循对方发事件的既有规范即可；其他服务团队也完全不需要考虑通知这件事——例如支付服务不用决定何时发通知、也不用了解如何发通知给客户，这样就实现了更大的架构自主权。事件驱动还能替代请求/响应式调用来避免时间耦合：与其结算服务每次都同步查询库存服务当前库存量，不如让库存服务把每次库存变更都作为事件发布，结算服务监听并在本地维护一份库存余量，这样结算服务能在本地就回答库存问题、无需远程调用，还能替库存服务分担压力；代价是额外的存储需求和最终一致性——数据可能有几毫秒到几秒的过期窗口，某些库存事件可能还没被处理，这在分布式系统里通常是可以容忍、也必须付出的取舍。事件最重要的特征是：发出事件的组件根本不知道谁会响应、为什么响应，而且它不应该在乎——鼠标驱动不关心单击是否触发了界面响应，支付服务发出”收到支付”事件后完全不该关心接下来发生什么，库存服务发”库存变更”事件时也不预期任何特定接收者。