一个场景🎬
你是一名软件开发工程师,有一天项目产品经理找到你,说他想到一个非常棒的点子,用户通过长传一组图片数据集,可以分析出这组图像数据的质量,比如是否模糊,是否有重复图片等,并对这组数据集打分。得分最高的可以获得拍照📷小能手的称号。
立马开发💼
这还不简单,定义一个/analysis的接口,接收图片数据流,对图片挨个分析,遍历完毕后生成统计信息返回给客户端。很快,功能就完成并上线。但是在使用过程中发现,对于数据量很小的数据集系统倒是能够正常返回,数据量一大,前端页面静止不动,也不知道是正在处理还是系统崩溃。并且在使用过程中你通过日志发现大多数任务执行周期都大于半小时。
加以思考🤔
/analysis接口承担了太多了责任,此时你在想如果我将任务拆分会怎么样。
将/analysis拆分成以下功能
- 上传图片数据集:客户端通过调用 REST API 的
/upload
端点来上传图片数据集。一旦数据集上传成功,服务器返回 HTTP 202 Accepted 状态码,并在响应头中包含一个 Location 字段,指向/status/{datasetId}
端点的 URL。同时,服务器将数据集信息发送到消息队列中,通过启动多个消费者一起来处理图片数据。 - 查询任务状态:客户端可以通过调用 REST API 的
/status/{datasetId}
端点来查询任务的处理进度。服务器将返回任务的当前状态,如正在处理、已完成或出错等。如果任务尚未完成,响应中可以包含一个估计的剩余处理时间。客户端可以根据这些信息显示进度条或其他形式的反馈给用户。 - 生成报告:一旦任务处理完成,客户端可以调用 REST API 的
/report/{datasetId}
端点来获取生成的报告。服务器将返回报告的数据或报告的 URL。客户端可以下载报告或将其展示给用户。
有时由于各种限制🚫,比如防火墙,无法只用websocket等,服务端无法主动通知客户端,通过使用这种异步任务的方式可以更加灵活的处理大任务。