事件驱动架构下事件代理缺乏无限留存能力的应对方案有哪些

无限留存（Infinite retention）：事件流（Event streams）必须能够无限期保留事件，该属性是在事件流中维护状态的基础。
——《Building Event Driven Microservices》

针对Azure Event Hubs、Event Grid这类有固定留存时长限制的事件代理，可落地的应对方案如下：

• 事件冷存储自动归档
  直接用事件代理自带的导出能力，在事件到期前自动同步到低成本持久化存储。比如Azure Event Hubs可直接开启捕获功能，按时间/大小阈值自动将事件以Avro/Parquet格式写入Blob存储或ADLS Gen2，还可配置存储分层策略，近期高频访问的数据存在热层，长期归档数据存冷层/归档层，存储成本仅为事件代理本身的几十分之一。需要回溯历史事件时直接读取冷存储数据即可，无需改造业务生产/消费逻辑。
• 状态快照+增量事件回溯
  针对需要用事件溯源重建状态的场景，不需要完全依赖全量历史事件回放。定期给服务的聚合根生成状态快照，存储在数据库或对象存储中，快照频率可根据业务事件量级调整（如每日/每周生成一次）。需要重建状态时，先加载最新的快照数据，再回放快照生成时间点之后的增量事件即可，只要快照生成间隔小于事件代理的最长留存时间，就不会出现事件缺失的问题，同时还能大幅提升状态重建的效率。
• 二级长期留存事件流层
  部署一套专门用于长期留存的事件流层作为补充，比如可配置无限留存的Kafka集群，或支持更长留存周期的托管事件流服务。用轻量消费进程或官方连接器将原事件代理中的核心事件实时同步到二级留存层，日常业务低延迟生产消费走原有事件代理，需要重放超过留存期的历史事件、做离线数据分析时走二级留存层即可，业务侧无感知。
• 核心领域事件独立落库
  在业务逻辑层做事件双写，核心领域事件产生时，除了发送到事件代理之外，同时写入专门的领域事件库，可选用关系型数据库、时序数据库或对象存储，按事件类型、时间、聚合ID做分区索引，既可以完全脱离事件代理的留存限制，还能支持业务侧按需查询历史事件、做审计追溯等需求。
• 业务分层留存策略适配
  并非所有事件都需要无限留存，先梳理全量事件的业务价值：非核心的监控、日志、通知类事件可直接按业务实际需求匹配事件代理的留存周期，不需要额外做归档；仅核心的领域事件、需要用于溯源、重放、分析的事件才走上述留存方案，可大幅降低不必要的存储和运维成本。

内容的提问来源于stack exchange，提问作者MattHH