单线程

四季春风,不厌冬

  1. 同步导入
  2. 异步导入
  3. 文件中心

  很多业务都有导入功能,如果部门内或者公司多条业务线存在导入需求,那么是否可以考虑将导入流程中的重复工作部分抽象出来,做成公共组件?

  导入功能主要包括上传文件、解析文件、业务处理、生成导入结果四个操作,但随着业务的扩展,不管是从业务场景还是数据量考虑,早先的导入应用架构已经不能满足日益精求的开发效率,我们的导入功能一共经历过三次改造。

同步导入

  前端上传文件,并向后端发起导入请求,后端完成文件解析、业务处理后,返回给前端结果,整个过程前端同步阻塞。

导入文件应用架构演进1.png

  当导入业务场景极少,并且一次导入耗时短时,同步导入无疑是最简单的。   

异步导入

  客户每次的导入量越来越大,导入时间越来越长,长时间的等待界面让客户都要炸毛了。后来设计了异步导入方案,前端上传文件,后端生成本次导入流程的流水号(唯一凭证)并将其返回给前端,前端开启每X秒的轮询导入结果操作,此时,后端解析文件、业务处理、生成导入结果。
  
导入文件应用架构演进2.png

  在异步导入中,前端不会一直停留在导入界面,而是在发起导入请求之后,便开始轮询导入结果,不会阻塞当前用户操作。可是,如果导入的业务场景增多,那么每条业务要完成一整套相同的流程,能不能从这一整套流程中抽象出公共部分,让业务方只负责自身的业务逻辑?

文件中心

  为了让业务方只关心自身的业务逻辑,我们抽象出了上传文件、轮询导入状态、下载导入结果步骤,并将其封装在文件中心”文件中心“,一共是三方交互。前端将文件上传至文件中心,并向文件中心轮询导入状态,最后从文件中心下载导入结果,而业务方负责接收前端导入请求、从文件中心下载文件、解析文件、业务处理、上传导入结果至文件中心。纵观下来,文件作为公共的抽象事物,所有的文件操作都由文件中心支持,业务方只关心自己的业务,这符合DDD设计思想
  
导入文件应用架构演进3.png

  加入文件中心进行业务解耦,看似很酷,但是系统交互复杂、开发难度大。

本文作者 : pengqin.zhou
本文使用 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议
本文链接 : https://www.zhoupq.com/blog/%E5%AF%BC%E5%85%A5%E6%96%87%E4%BB%B6%E5%BA%94%E7%94%A8%E6%9E%B6%E6%9E%84%E6%BC%94%E8%BF%9B/

本文最后更新于 天前,文中所描述的信息可能已发生改变