在业务代码中植入异步通知功能

来源:转载



对异步通知的定位,是作为核心业务的一种补充,应该尽量与核心业务解耦。


采用的解耦方式为“事件+监听器”。一些主流的php web框架,如laravel、yii2对“事件+监听器”的支持是“开箱即用”的,只需写少量的代码(通常是增加一些配置项)即可。


这里描述的设计思想是“解耦”,是和语言无关的,属于“设计模式”的范畴。


概念
事件

业务系统在某个时机触发事件,例如订单发货了,这时需要触发一个“订单已发货”事件。事件携带了与异步通知相关的数据,如用户信息、订单信息等,这些数据用于创建异步通知任务。


监听器

监听器负责捕捉事件并创建相关的异步通知任务。


异步通知任务

异步通知任务应有以下的属性


接收人
通知内容
发送时间
发送状态

异步通知任务应带有“锁”机制,在并发场景下也可保证同一个通知不会被多次发送给用户。
异步通知的发送时间应是可配置的,以应对需求的变化。


过滤器

过滤器用于拦截不需要发送的通知。


有一种场景:用户注册后n天内不下单则发送召回通知。这种场景需要在用户注册时触发事件,监听器捕获并创建发送时间为n天后的通知任务。如果用户在n天内下单了,则这个通知就不应该发送。


这个通知对应的过滤器就应该检查从通知的创建时间到发送时间内,用户有没有下单。


实现

工厂+配置+后台进程


配置

配置包括以下内容


事件对应的通知节点
通知节点的发送时间
工厂

工厂的职责


创建通知任务
实例化通知任务
后台进程

后台进程读取待发送的通知,将通知发送给用户,并更新通知发送状态


扩展

当新需求到来时,如当用户关注的商品降价时发送一条通知,只需在业务代码中触发一个“商品降价事件”,增加相关的配置和通知节点,即可满足需求。


不足

容易看出,这种设计思想会导致业务中的事件越来越多。但为了不侵入核心业务代码,是否可以容忍这个不足之处?








分享给朋友:
您可能感兴趣的文章:
随机阅读: