说一说文件转换服务的系统设计

一、背景

我们需要把word/ppt转换为pdf，刚开始自研，后改为和第三方服务合作。
因为涉及到第三方服务的源码及软件著作的安全问题，我们约定把待转换的文件下载到对方管控的机器里，而不是在我们的机器上安装第三方的转换工具。

这就带来了以下几个部署方面的问题：

• 我们只能通过跳板机，把待转换的文件发送到工作节点。
• 工作节点上，除了运行我们的服务外，还运动着第三方负责维护的转换工具。
• 转换平台兼容不同的转换工具，由工作节点主动拉取转换任务，而非转换平台下发任务到工作节点。
• 搭建测试环境，我们需要让工作节点对应不同环境下的转换平台。

本文主要是以此背景，尝试把整个架构设计整理出来。

二、系统设计

1、跳板机

更新管理系统windows server，我们通过RDP远程桌面工作连接。
这个windows机器就是跳板机了，目的就是不让我们直接访问到第三方服务负责的工作节点。

所以，它需要安装ftp工具，以及CD部署软件。

2、工作节点

由第三方负责维护。

上文说到，我们不能直接访问到工作节点，所以需借助于web管理界面或者rest api接口。

主要用于重启服务和更新配置等等。

另外，可以通过ftp工具连接，修改限定的一些文件内容。

工作节点，我们的服务负责下载待转换的文件和上传转换完成的新文件。
第三方服务的核心是转换文件，对外部是透明。

3、搭建测试环境

对公司的IP映射到公网IP，同时将工作节点（其外网IP）添加到测试环境的转换平台。

工作节点拉取转换平台的待转换文件，具体转换还是不变，不同的是转换后上传的地址变成了公司外网暴露的地址。

测试环境也好，生产环境也罢，对于工作节点来说，都是透明的。

转换是不区分你是哪里来的任务，只是拉取文件和上传文件的地址不一样而已。

4、管理后台

主要是一些查询及操作的UI界面，会直接读取转换服务的mongo数据库，除此之外，它还会直接调用转换服务提供的一些接口，比如/proxy/*

5、文件转换服务

也可以叫做文件转换平台， 它用于接收业务服务传递过来转换任务。
文件转换服务提供回调通知接口。
待工作节点转换完成后，工作节点通知文件转换服务。
文件转换服务更新任务的状态为已完成。

三、总结

本文仅以文件转换服务为例，其实适用于许多异步操作的场景，以及和第三方交互的业务模式。
我在文中有时也使用“任务”一词，也就是异步任务，设计的时候都可以参考。

或许，你可以在上文反复看到“第三方”字眼，如果你做过第三方支付，联带想想，是否有异曲同工之处呢？