事件驱动的业务架构提案No.6

设计并实施可靠的基于消息通知的服务架构方案。通过异步方式（消息、事件等），将核心业务逻辑与扩展业务逻辑解耦。

现状与问题

悦库网盘的业务框架，如下图：

由终端层发起操作请求，通过访问API接口根据路由规则将请求转交至业务处理逻辑中；在业务逻辑层，首先校验请求者的角色和权限，确认此次操作的安全合法性；校验通过后，由对应的业务逻辑处理此操作，并在操作完成后，进行日志的记录。 在业务逻辑层对请求的处理是基于面向过程的方式，需等待整个操作过程的每一个步骤依次执行结束后，才会向请求者返回应答。

主要的文件相关业务处理流程，如下图：

这种处理流程会产生以下几个问题：

• 业务的复杂度较高的操作，处理流程过长，可能造成请求应答延时高，服务端负载过高等问题，如“修改”和“彻底删除”。

• 重复的处理逻辑复用方式低级，如“日志”。

• 业务流程耦合度高，变更困难。

以“彻底删除文件”为例，进行问题描述：

执行“彻底删除文件”操作时，需要依次执行如下步骤：

• 收到“彻底删除文件”请求
• 删除回收站文件信息
• 删除文件分享链接
• 删除文件水印
• 删除文件缩略图
• 记录操作日志

需要等上边几个步骤依次全部执行完成，才会将“彻底删除文件”这个操作请求应答给操作者。

• 用户视角 删除文件后，一定希望在文件列表中需要立即生效，既实时一致性需求。而对分享链接、水印、缩略图、日志等数据，并不需要立即处理。我们通过同步的方式处理，会造成业务响应的延迟，用户操作起来感觉不够丝滑。

• 团队视角 如果后续我们围绕文件增加了订阅功能，那么就需要在彻底删除文件时，清理对文件的订阅数据，既在“彻底删除文件”的业务逻辑中，补充删除订阅数据的逻辑。以这种方式进行业务扩展，导致新展开的业务，必须对旧的业务逻辑进行修改，不可避免要对现有的稳定的业务逻辑进行侵入式的调整。

解决方案

将原过程化的处理流程中，对数据操作的逻辑，根据实时性要求划分为实时性操作和非实时性操作。在实时性操作处理完成后，直接应答给用户，同时产生一条操作事件，等待事件通知至相应的处理模块时，再执行非实时性操作。

以“彻底删除文件”为例，描述解决思路

采用订阅-通知的方式，将分享链接、水印、缩略图、日志等，实时一致性要求低的操作进行异步处理，从而解决同步处理所带来的问题。

• 将各个业务进行模块和角色划分：

  • 订阅者
    • 回收站模块
    • 分享链接模块
    • 水印模块
    • 缩略图模块
    • 日志模块
  • 通知者
    • 事件通知模块

• 处理流程如下：

  • 由订阅者向通知者订阅“彻底删除文件”
  • 收到删除文件请求
  • 由回收站模块删除文件信息
  • 产生“彻底删除”事件
  • 由通知者向其他订阅了“彻底删除”事件的订阅者
  • 订阅者收到通知，处理自己模块负责的业务逻辑

  

  在“彻底删除文件”的时，文件信息的需要立即生效，所以直接通过回收站模块进行文件信息的删除，并产生“彻底删除”事件。至此可认为文件操作已完成，并返回给调用者。通知者在收到“彻底删除”事件后，以异步的方式向所有订阅了此事件的模块进行通知，相应的订阅者收到通知后，依照自己模块的方式处理此通知，从而达到异步解耦的效果。

• 用户视角 删除文件后，文件列表实时更新，删除操作响变快了。

• 团队角度 在新增业务模块时，只需要增加对于“彻底删除”通知的处理，并订阅“彻底删除”即可，不需要关心原有的业务逻辑。