设计并实施可靠的基于消息通知的服务架构方案。通过异步方式（消息、事件等），将核心业务逻辑与扩展业务逻辑解耦。
现状与问题
悦库网盘的业务框架，如下图：
由终端层发起操作请求，通过访问API接口根据路由规则将请求转交至业务处理逻辑中；在业务逻辑层，首先校验请求者的角色和权限，确认此次操作的安全合法性；校验通过后，由对应的业务逻辑处理此操作，并在操作完成后，进行日志的记录。 在业务逻辑层对请求的处理是基于面向过程的方式，需等待整个操作过程的每一个步骤依次执行结束后，才会向请求者返回应答。
主要的文件相关业务处理流程，如下图：
这种处理流程会产生以下几个问题：
业务的复杂度较高的操作，处理流程过长，可能造成请求应答延时高，服务端负载过高等问题，如“修改”和“彻底删除”。
重复的处理逻辑复用方式低级，如“日志”。
业务流程耦合度高，变更困难。
以“彻底删除文件”为例，进行问题描述：
执行“彻底删除文件”操作时，需要依次执行如下步骤：
- 收到“彻底删除文件”请求
- 删除回收站文件信息
- 删除文件分享链接
- 删除文件水印
- 删除文件缩略图
- 记录操作日志
需要等上边几个步骤依次全部执行完成，才会将“彻底删除文件”这个操作请求应答给操作者。
用户视角 删除文件后，一定希望在文件列表中需要立即生效，既实时一致性需求。而对分享链接、水印、缩略图、日志等数据，并不需要立即处理。我们通过同步的方式处理，会造成业务响应的延迟，用户操作起来感觉不够丝滑。
团队视角 如果后续我们围绕文件增加了订阅功能，那么就需要在彻底删除文件时，清理对文件的订阅数据，既在“彻底删除文件”的业务逻辑中，补充删除订阅数据的逻辑。以这种方式进行业务扩展，导致新展开的业务，必须对旧的业务逻辑进行修改，不可避免要对现有的稳定的业务逻辑进行侵入式的调整。
解决方案
将原过程化的处理流程中，对数据操作的逻辑，根据实时性要求划分为实时性操作和非实时性操作。在实时性操作处理完成后，直接应答给用户，同时产生一条操作事件，等待事件通知至相应的处理模块时，再执行非实时性操作。
以“彻底删除文件”为例，描述解决思路
采用订阅-通知的方式，将分享链接、水印、缩略图、日志等，实时一致性要求低的操作进行异步处理，从而解决同步处理所带来的问题。
将各个业务进行模块和角色划分：
订阅者
- 回收站模块
- 分享链接模块
- 水印模块
- 缩略图模块
- 日志模块
通知者
- 事件通知模块
处理流程如下：
- 由订阅者向通知者订阅“彻底删除文件”
- 收到删除文件请求
- 由回收站模块删除文件信息
- 产生“彻底删除”事件
- 由通知者向其他订阅了“彻底删除”事件的订阅者
- 订阅者收到通知，处理自己模块负责的业务逻辑
在“彻底删除文件”的时，文件信息的需要立即生效，所以直接通过回收站模块进行文件信息的删除，并产生“彻底删除”事件。至此可认为文件操作已完成，并返回给调用者。通知者在收到“彻底删除”事件后，以异步的方式向所有订阅了此事件的模块进行通知，相应的订阅者收到通知后，依照自己模块的方式处理此通知，从而达到异步解耦的效果。
用户视角 删除文件后，文件列表实时更新，删除操作响变快了。
团队角度 在新增业务模块时，只需要增加对于“彻底删除”通知的处理，并订阅“彻底删除”即可，不需要关心原有的业务逻辑。
