OpenCollective项目通知系统的长期技术规划与设计思考

背景与现状分析

在开源协作平台OpenCollective中，通知系统作为用户交互的核心组件，当前每月处理约18万封邮件通知。现有系统基于活动类型分层架构，通过接收活动事件来决定邮件发送逻辑。然而该系统面临三个主要技术挑战：

1. 通知决策逻辑复杂，难以清晰定义触发条件
2. 邮件模板陈旧，缺乏个性化定制能力
3. 缺乏对组织级通知场景的支持

核心设计挑战

通过两次工作坊的深入探讨，团队识别出以下关键设计维度：

用户角色与通知语义

• 个人用户需要完整的事件追踪（如报销单的所有评论）
• 组织管理员需要避免信息过载（如不接收管辖范围内所有评论）
• 团队协作场景需要区分个人待办与团队工作队列

通知类型架构

1. 即时通知：强时效性的事件触发（如报销单状态变更）
2. 摘要通知：适合非紧急事件的批量处理（如多条评论汇总）
3. 动态通知：技术实现复杂度较高（如评论删除后同步移除通知）

技术选型评估

针对是否采用第三方服务（如Novu）的决策，团队得出以下结论：

自研方案优势

• 深度集成现有活动分类系统
• 灵活支持组织/个人的双重通知场景
• 渐进式演进现有邮件通知架构

第三方服务局限

• 免费版月配额（3万）无法满足当前业务量
• 难以定制团队协作场景的特殊逻辑
• 增加对服务商的长期依赖风险

系统架构设计方向

基于讨论共识，未来技术实施将聚焦以下组件：

核心模块

1. 事件分发引擎：基于RBAC模型的路由决策
2. 订阅管理系统：支持频道化订阅（评论线程/报销单等）
3. 呈现层服务：
   • 个人通知中心（标记已读/未读）
   • 组织工作看板（团队待办事项）

扩展能力

• 混合推送策略：即时邮件+应用内通知
• 智能摘要：基于事件类型自动聚合
• 跨渠道状态同步（如网页与邮件已读状态）

实施路线建议

1. 阶段一：重构后端订阅逻辑，建立事件-角色-用户的映射关系
2. 阶段二：开发基础应用内通知组件，实现标记已读功能
3. 阶段三：设计团队协作视图，解决组织级工作流需求

该规划既保留了现有系统的业务逻辑积累，又为未来扩展留出技术空间，体现了稳健的架构演进思想。