一、背景
我们需要把word/ppt转换为pdf,刚开始自研,后改为和第三方服务合作。
因为涉及到第三方服务的源码及软件著作的安全问题,我们约定把待转换的文件下载到对方管控的机器里,而不是在我们的机器上安装第三方的转换工具。
这就带来了以下几个部署方面的问题:
- 我们只能通过跳板机,把待转换的文件发送到工作节点。
- 工作节点上,除了运行我们的服务外,还运动着第三方负责维护的转换工具。
- 转换平台兼容不同的转换工具,由工作节点主动拉取转换任务,而非转换平台下发任务到工作节点。
- 搭建测试环境,我们需要让工作节点对应不同环境下的转换平台。
本文主要是以此背景,尝试把整个架构设计整理出来。
二、系统设计
1、跳板机
更新管理系统windows server,我们通过RDP远程桌面工作连接。
这个windows机器就是跳板机了,目的就是不让我们直接访问到第三方服务负责的工作节点。
所以,它需要安装ftp工具,以及CD部署软件。
2、工作节点
由第三方负责维护。
上文说到,我们不能直接访问到工作节点,所以需借助于web管理界面或者rest api接口。
主要用于重启服务和更新配置等等。
另外,可以通过ftp工具连接,修改限定的一些文件内容。
工作节点,我们的服务负责下载待转换的文件和上传转换完成的新文件。
第三方服务的核心是转换文件,对外部是透明。
3、搭建测试环境
对公司的IP映射到公网IP,同时将工作节点(其外网IP)添加到测试环境的转换平台。
工作节点拉取转换平台的待转换文件,具体转换还是不变,不同的是转换后上传的地址变成了公司外网暴露的地址。
测试环境也好,生产环境也罢,对于工作节点来说,都是透明的。
转换是不区分你是哪里来的任务,只是拉取文件和上传文件的地址不一样而已。
任务查询:
下面的外网IP,映射到工作节点172.xx.xx.126(见系统设计图)
4、管理后台
主要是一些查询及操作的UI界面,会直接读取转换服务的mongo数据库,除此之外,它还会直接调用转换服务提供的一些接口,比如/proxy/*
5、文件转换服务
也可以叫做文件转换平台, 它用于接收业务服务传递过来转换任务。
文件转换服务提供回调通知接口。
待工作节点转换完成后,工作节点通知文件转换服务。
文件转换服务更新任务的状态为已完成。
三、总结
本文仅以文件转换服务为例,其实适用于许多异步操作的场景,以及和第三方交互的业务模式。
我在文中有时也使用“任务”一词,也就是异步任务,设计的时候都可以参考。
或许,你可以在上文反复看到“第三方”字眼,如果你做过第三方支付,联带想想,是否有异曲同工之处呢?