最近开了一个新坑，需要做一个把美团外卖订单数据解析成单个菜品数据的工具。暂定名称WmDog。源起是一个朋友的实际需求。仔细想想，自从业以来，对于web上相关的文件系统处理仅止步于上传、保存，而这一次还需要后续的处理和下载。而且整个流程设计有一个明显的渐进过程，于是想要记录一下。

第一版的按照所需的功能进行了最简单的设计。

这样的设计符合最初的直觉，但根据经验，像解析数据这样的工作一般是不会直接放在api接口中进行的，更何况美团的外卖数据可能是以十万甚至数十万记录的量级。在用户端看起来很可是假死甚至超时了。

所以解析的过程需要放到任务队列中异步处理。

第二版设计中加入任务队列。

异步处理加入之后，前端可以通过查询任务处理状态持续给予用户反馈；只要保存好job_id可以做到稍后再看的能力。但是这一版设计中依然存在一些问题。文件的上传和下载都是通过web服务器进行，用户文件和解析结果文件也存储在web服务器。我们先不说如果web服务器崩溃导致文件丢失，单单是上传下载的带宽占用就是极大的浪费。web 就该好好干web的事，把文件处理交给专业的来做。谁最专业？自然是各个oss。

第三版设计中把文件存储交给oss。

这样修改之后还有一个好处：可扩展性。web服务器和文件存储、文件解析都分离了，哪里压力大，就可以可以只加那一部分的资源。比如任务队列消费不过来了，只要加一些worker进程即可。从某种程度上说，这样的设计也是一种微服务化的体现。

一个简单的例子。核心的思想是两个：

1. 耗时任务放到异步队列中执行，既缓解服务器压力，又可以给用户更好的体验
2. 切分任务，增加可扩展性。

水一文留着给自己看，没有多少干货。最后记录两个好用的程序。

1. python下的一个轻量级任务队列RQ
2. 像写代码一样画时序图工具websequencediagrams