跳到主要内容

AMMDS 从概念到现实：产品诞生记

· 阅读需 4 分钟
萌森工作室
萌森工作室
新疆萌森软件开发工作室

今天，我们想和你聊聊 AMMDS 背后的故事——从一个模糊的想法到最终的产品，这一段开发历程充满了挑战、决策和成长。

市场需求：现有的工具还不够好​

故事的起点来自我们自身的"痛点"。萌森工作室的团队成员都是资深的自托管用户，我们在日常使用 IYUUPlus 进行站点资源管理时，发现了一个普遍存在的问题：

媒体管理的工具链是割裂的。

你需要用 TinyMediaManager 刮削电影元数据，用 MediaElch 处理剧集信息，用单独的工具管理站点资源，再用另一个工具维护 NFO 文件的格式一致性。每个工具都有自己的数据格式和操作逻辑，数据在工具之间流转时频繁丢失信息。

更重要的是，现有的工具大多缺乏统一的面板和自动化能力。你无法在一个地方看到所有媒体文件的元数据状态，也无法批量纠正错误的刮削结果。对于拥有几十 TB 媒体库的重度用户来说，这种割裂感带来的维护成本是惊人的。

技术选型：为什么选择 Java SpringBoot + Vue3​

确定了要做什么之后，接下来的问题是：用什么技术来实现？

我们进行了长达一个月的技术调研，评估了多种技术栈：

  • Python + Django：开发效率高，但部署依赖重，难以保护源码
  • Rust + Tauri：性能和安全性极佳，但开发周期长，Web 生态支持有限
  • Go + Web：编译速度快，单二进制分发，但泛型和框架生态相对较弱
  • Java SpringBoot + Vue3：成熟的生态、丰富的基础设施、GraalVM AOT 原生编译为二进制保护代码

最终我们选择了 Java SpringBoot + Vue3 的组合。后端使用 SpringBoot 3.x 框架构建 RESTful API，前端使用 Vue3 提供现代化的交互体验。借助 GraalVM Native Image 的 AOT（Ahead-of-Time）编译技术，SpringBoot 应用可以直接编译为独立的二进制可执行文件，用户下载后直接运行即可，无需安装 JVM 运行时环境。这对于自托管场景来说是一个巨大的优势——用户不需要安装 Java 运行时或 Node.js 环境，也无需配置数据库。

同时，SpringBoot 的虚拟线程（Virtual Threads）和响应式编程模型非常适合处理刮削任务。AMMDS 的典型工作场景是同时从多个站点获取数据、解析响应、写入文件，这种 I/O 密集型的任务在虚拟线程的调度模型下表现得非常出色。而 GraalVM 原生二进制文件还能有效保护后端代码，防止源码泄露。

关键决策节点​

第一个决策：插件化架构​

在项目设计初期，我们就确立了插件化架构作为核心设计原则。这意味着 AMMDS 的刮削引擎、站点适配器、数据处理流程都是可插拔的。用户可以根据需要安装不同的插件，社区也可以贡献第三方插件来扩展功能。

这个决策在后来的开发中被证明是极其正确的。AMMDS 能够快速适配多个 PT 站点和元数据来源，正是因为插件化架构让我们可以在不修改核心代码的情况下，通过编写插件来支持新的站点。

第二个决策：Web 面板优先​

与传统的媒体管理工具不同，我们决定将 Web 面板作为 AMMDS 的主要交互界面，而不是桌面客户端。这意味着用户可以在任何设备上管理媒体库——PC、平板、手机，甚至通过 NAS 的浏览器访问。

Web 面板的设计也遵循了"移动优先"的理念，确保在手机屏幕上也能获得良好的操作体验。

第三个决策：NFO 标准兼容​

社区中关于 NFO 文件的格式一直存在争议——Kodi 的 NFO 格式、Jellyfin 的 NFO 格式、Emby 的 NFO 格式之间存在细微差异。我们决定同时兼容所有主流格式，用户可以在设置中选择目标格式，系统会自动适配。

第一个原型​

2023 年底，AMMDS 的第一个可运行原型诞生了。这个版本只有最基础的功能：

  • 从单个站点抓取种子列表
  • 解析种子中的元数据信息
  • 生成基本的 NFO 文件

虽然功能简陋，但它验证了核心技术路线的可行性。站在今天回头看，这个原型中的很多代码已经被重写了好几遍，但核心的架构设计——插件化引擎、管道式数据处理、基于虚拟线程的调度系统——一直沿用至今。

开发中的挑战​

挑战一：站点兼容性​

PT 站点各有各的页面结构、认证方式和数据格式。有的站点使用静态页面，有的使用 JavaScript 动态渲染，有的使用 API 接口。为了适配不同站点，我们开发了一套灵活的适配器机制，允许为每个站点编写独立的解析规则。

挑战二：数据一致性​

当同时从多个来源获取同一部电影的元数据时，如何合并和去重是一个棘手的问题。我们设计了优先级规则引擎，用户可以自定义不同信源的优先级，系统会按照规则自动合并数据。

挑战三：性能优化​

处理大型媒体库（数万条目）时，内存使用和扫描速度成为瓶颈。通过引入增量扫描、缓存机制和批量处理策略，我们将全量扫描的时间从数小时缩短到数十分钟。

产品演进​

从第一个原型到今天的 AMMDS，产品经历了无数次的迭代和重构。每一次版本更新都源于用户的真实反馈和开发者自身的使用体验。我们坚持"吃自己的狗粮"——团队成员日常就在使用 AMMDS 管理自己的媒体库，这让我们能够第一时间发现问题和改进方向。

AMMDS 仍在快速迭代中。未来，我们将引入更多智能化的元数据处理能力，进一步完善插件生态，让自托管媒体管理变得更加简单和高效。