办公电脑自建类Google Drive系统的可行性与优化方案问询

可行之处 #

• FastAPI轻量高效，接口迭代速度快，适合原型快速落地；MySQL作为成熟关系型数据库，存储文件目录元数据（发送者信息、路径、文件属性）的稳定性有保障。
• AWS临时存储的3分钟自动过期、5GB上传限制机制，能有效控制云存储成本；秘钥/HTTPS/OAuth2.0的组合覆盖了基础身份认证与传输安全需求。

潜在风险 #

• 定时ping云服务器拉取文件的机制存在可靠性隐患：网络波动、办公服务器宕机可能导致文件遗漏，缺乏重试、告警机制的话，长期运行易出现数据丢失问题。
• 办公服务器本地文件存储扩展性不足：磁盘容量上限、备份策略缺失会成为瓶颈，服务器故障可能导致本地文件丢失。
• 技术栈匹配度问题：若团队以Java为主，FastAPI（Python）的维护成本会逐渐上升，后续故障排查、功能扩展需跨技术栈协作，效率较低。
• 原型阶段通常缺乏完善的监控、日志体系，长期运行中难以快速定位问题，运维成本高。

• 基于开源自建系统快速搭建：直接使用Nextcloud这类成熟的类Google Drive开源方案，内置文件同步、权限管理、加密传输功能，只需配置API秘钥供外部上传/检索，少量定制开发即可适配团队业务需求，省去从头搭建后端逻辑的工作量。
• 云原生架构替代中转环节：用AWS S3配合Lambda函数替代临时存储+定时拉取逻辑——文件上传到S3后触发Lambda，直接同步到办公服务器并写入元数据到MySQL，去掉定时ping的冗余步骤，提升可靠性。
• 简化存储架构：若团队规模小、文件量不大，可直接去掉AWS临时存储，让客户端通过加密HTTPS通道直接上传到办公服务器，用Nginx配置上传限流、身份校验，配合OAuth2.0认证，减少架构复杂度。
• 轻量元数据存储：若无需复杂多表关联查询，用SQLite替代MySQL，无需单独部署数据库服务，降低运维成本，适合小规模场景。

• 适配性极强：Spring Boot生态完全覆盖现有方案的所有需求：
  • 文件上传/下载：Spring MVC提供成熟的MultipartFile处理能力，可轻松实现5GB上传限制；
  • 安全认证：Spring Security OAuth2原生支持OAuth2.0、API秘钥认证，配合HTTPS保障传输安全；
  • 元数据存储：Spring Data JPA可快速映射MySQL中的目录信息模型，实现CRUD操作；
  • 定时任务：Spring Scheduler或Quartz可替代原方案的定时ping逻辑，可靠性更高。
• 团队协同优势：团队熟悉Spring Boot，后续维护、功能扩展（如前端对接、业务适配）的效率远高于FastAPI方案，技术栈统一能降低人员协作成本。
• 迁移成本低：现有方案的核心逻辑（文件流转、元数据存储、安全规则）可直接映射到Spring Boot实现，元数据模型、业务规则无需大幅改动，迁移周期短。

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