Dropbox 消息系统模型 (MSM) 的演进与优化

背景与挑战

Dropbox 是一个文件共享云平台，近年来其异步系统逐渐变得分散，虽然满足了不同产品的需求，但缺乏一致性。这些系统支持多种用例，如文件上传、机器学习和搜索索引，但也面临诸多挑战：

• 开发效率低：复杂的系统增加了学习和管理的难度，降低了开发者的生产力。
• 可靠性不一致：由于可用性和延迟的服务级别目标 (SLOs) 不一致，且缺乏多数据中心支持，数据中心故障时风险较高。
• 操作复杂性高：混合使用 Kafka 和 Redis 等外部队列解决方案，增加了成本和操作复杂性。
• 扩展性问题：系统每天处理超过 300 亿次请求，但在关键组件（如延迟事件调度器）中无法满足吞吐量需求。
• 架构不灵活：现有的 Lambda 基础设施偏离了 Dropbox 的服务导向架构 (SOA)，难以诊断问题或与其他系统集成，且缺乏自动扩展能力。

解决方案

Dropbox 采用分阶段的方法，而非从头构建全新系统，逐步优化其异步平台：

• 简化异步接口：提高开发速度，减少操作负担。
• 自动化发布实践：检测回归并触发回滚，提升可靠性。
• 自动计算扩展：更高效地处理事件积压。
• 统一模式：在异步系统中统一模式，提供可扩展的组件和 API，支持新用例。
• 成本效率：逐步淘汰冗余系统，将 Lambda 基础设施迁移到 Dropbox 的 SOA 栈，提升计算效率、自动扩展、多数据中心支持和监控能力。

消息系统模型 (MSM)

MSM 是此次转型的核心部分，受网络 OSI 模型的启发，将 Dropbox 的异步系统分为五个逻辑层：

1. 前端层：为工程师或其他系统提供接口，管理事件合规性的模式验证，并将消息格式转换为标准化的协议缓冲区格式，确保事件持久性。
2. 调度层：根据用例需求（如变更数据捕获或延迟执行）管理事件调度，确保执行顺序。
3. 流控制层：根据订阅者可用性、优先级或限流处理任务分配，跟踪状态并重试失败任务。
4. 交付层：将事件路由到公共或私有云中的服务，管理重试、过滤和并发。
5. 执行层：通过无服务器函数或远程进程处理任务，利用自动扩展确保多云操作的可靠性。

成果

通过分层架构，Dropbox 在不影响稳定性的情况下逐步重建了其异步平台，实现了以下目标：

• 简化工作流程：提高了开发者的生产力。
• 增强可靠性：通过多数据中心支持提升了系统的可靠性。
• 适应新需求：更容易适应新的工作流和文件系统架构。
• 成本效率：通过整合基础设施组件实现了成本节约。

Dropbox Vault 的停用

Dropbox 近期宣布停用 Vault 功能，这一决定引发了技术社区的广泛讨论。尽管 Dropbox 解释称是由于“可能影响安全的技术风险”以及希望专注于增强现有安全功能，但用户对此并不满意，许多人表示需要寻找其他具有类似安全 PIN 访问功能的云存储解决方案。

总结

Dropbox 通过引入消息系统模型 (MSM) 和分层架构，成功优化了其异步平台，提升了开发效率、系统可靠性和成本效率。尽管停用 Vault 功能引发了一些争议，但 Dropbox 在技术基础设施上的演进展示了其应对复杂挑战的能力。