起点学院课程

电商后台设计:系统消息

1 评论 6378 浏览 32 收藏 11 分钟
15天0基础极速入门数据分析,掌握一套数据分析流程和方法,学完就能写一份数据报告!了解一下>>

电商后台系统中,消息系统是一个必不可少的功能模块,其核心是帮助后台人员及时了解业务消息,保障业务正常运行。本文作者以此为出发点,详细的概述了电商后台中的系统消息的设计思路,与大家分享。

后台系统是一个庞大的功能体系,及时的了解每个功能的使用状况,保障业务正常进行是每个系统的重点。通常系统内会开发大量的监控功能(可视化的报表和非可视化的报表)来对这些业务进行监控,同时通知相应的负责人以及时了解业务和服务器状况。

常见的一些监控功能,如账号异常(账号异地登录、账号多次密码输入错误)、运营通知(活动上架、活动下架)、订单异常(订单堆积、派单堆积)、服务器异常(服务器宕机、CPU过载)、脚本异常(脚本卡死、进程过多)等等。

今天带大家来设计一个系统消息通知模块,通过简单的设置,完成个性化的消息发送,并且减轻后期代码的维护工作。首先我们来看看常见消息发送功能是如何实现的以及它们的优缺点。

01 实现方式

1.1 直接触发

直接触发是将消息发送的逻辑和具体的业务代码逻辑写在一起,当满足条件时,触发消息发送功能。

  • 优点:开发简单,如果功能封装好后,代码粘过来,十分钟功能基本就能完成;消息发送比较及时,消息发送逻辑和业务逻辑在一起,满足条件就会立即触发。
  • 缺点:后期如果需要添加、编辑或删除接收人信息,就需要修改代码,维护起来比较麻烦。熟悉代码的人可能几分钟就搞定了,新人估计就得看半天代码了。

我参与过多个系统的开发,发现这么干的人还是挺多的。总结一下应该有以下几个原因:

  1. 写起来简单,因为发送逻辑一般都是封装好的,只需要粘代码,修改一下发送参数就完事
  2. 一般后台业务系统比较多,使用的编程语言比较多,各语言之间相互调用需要配置基础服务,成本太大
  3. 消息通知通常属于系统基础功能,产品经理基本上不会去关注,也就不会去统一规划这个功能,技术就自己随意发挥了^_^

1.2 消息池

通过将所有消息先收集到一个消息池(如Mysql、Redis、Kafka等)中,然后再统一通过系统调度将消息发送给接收人。

  • 优点:功能模块化,可以做到统一管理,代码的调用可以更简洁,后期维护成本可以降到最低。
  • 缺点:消息会有延迟,消息池它是一个异步发送方式,消息的生产和发送是两个相互独立的过程;需要开发配置内容页面,开发量稍微大一点,但是后期能减轻更多的维护成本,我认为是非常值得的。

02 消息池模型

系统规划的目的就是让功能结构清晰,后期维护更轻松,所以上面第一种的实现方式就不讲了,主要讨论一下消息池功能是如何实现的。先来看一下消息池功能的模型图:

上面的模型主要分四层:

  • 消息来源: 消息来源从开发角度来说,也称为消息生产者,它主要是指消息的生成方式和位置。在庞大的后台系统中,技术架构会划分出多个业务模块,各自的的业务模块都由不同的开发人员维护,不同的业务组使用的语言也各不相同,所以在完成相同功能时,书写方式也是各不相同,这个是没有办法统一的。
  • 消息池: 主要作用是存储要发送内容信息,如消息内容,发送时间等。市面上常见的软件有Mysql、Redis、Kafka、RabbitMQ等。所以对消息数据的存储我们是可以做到统一的。
  • 消息分发:主要作用是获取待发送的消息列表,并根据已设置的接收人信息,找到具体的接收人并发送消息。技术上通常会启动相应的任务程序持续的监控消息池,当消息池中有需要发送的数据,就执行相应业务逻辑。
  • 接收人: 具体的消息接收人,接收人的接收方式有手机、邮箱或站内信。

03 功能分析

设计具体功能前先来分析一下消息通知都涉及哪些功能。

3.1 消息类型

在系统运行过程中,会涉及到许多业务功能的监控,如订单业务中,订单支付是否有未成功、订单分配是否有堆积的情况、派单功能是有堆积情况;再如运营业务中,商品运营活动已经设置上线时间,到点上线后需要及时通知运营人员上线是否成功,避免影响活动效果。

为了能够及时让维护人员了解问题,通常都对消息进行归类,如账号异常、服务器警告、数据库异常、运营通知、订单异常、脚本异常等。

3.2 紧急程度

系统中对于不同类型的消息,根据重要程度会划分出不同的级别。如系统每日报表任务,由于数据量比较大,要求并不是很高,延迟一天通常都可以接受, 所以都是晚上3 ~ 5点之间由脚本自动运行导出后放在服务器上,第二天早上8点发系统通知,再由需求人自行导出就可以了,这类消息属于一般程度;

但是对于服务器宕机这种情况,就必须立即通知负责人进行处理,以免给企业带来更多的损失,这类消息属于紧急程度。

3.3 接收方式

消息接收方式通常就三种:站内信、手机短信、邮箱。不同的接收方式作用有所不同:

  • 站内信:站内信是系统内部功能,研发人员可以随意设置,消息内容可以写的比较详细;但是时效性比较差,取决于接收人什么时候登陆系统。
  • 邮箱:消息内容可以写的比较详细,时效性也比较差,但是邮件确实必发的功能,因为可以作为尽职调查的凭证。
  • 手机短信:短信功能一般都由第三放平台提供,所以发送内容长度有所限制,内容需要简洁,最大特点就是及时。

3.4 发送时间

对于系统中的消息,比较紧急的如订单支付异常、数据库宕机异常它们需要及时发送,还有一些不重要的,比如上面说的各种任务报表,晚上3、4点生成好后,系统也不会发送消息,一般会设置好时间,等到早上8、9点才会开始发送通知,还有一些任务需要每个几小时就得发送一次。

3.5 唯一标示

唯一标示主要用于代码开发。在测试环境和正式生产环境由于测试导致数据库ID不一致,所以开发时没有办法通过对应的ID调用消息,就需要设计一个唯一标识符供开发人员使用,一般标示符命名根据具体的业务点来命名。

3.6 消息接收人

由于员工岗位的变动,后台需要设置相应的接收人维护界面,可以自由的添加、删除多个消息接收人。

04 原型设计

系统消息基本就上面这些功能,有需要的可以自己再扩展。下面给出部分原型设计图:

功能整理:

消息设置列表:

消息表单设置页:

接收人列表:

05 使用方法

功能我们设计好了,如何在业务中使用,我简单说一下:

  1. 需要各业务平台封装消息池调用功能,并开放一个接口,用来创建具体消息内容
  2. 在需要发送消息的业务里,调用上面的消息创建接口
  3. 消息模块启动任务(如crontab、监听)监控消息池,如果有待发送消息,获取并组织消息内容,完成消息发送。

其中1、2两步需要在各自业务平台完成,第1步封装成公共功能,只用开发一次,第2步根据业务需要自行调用,就一行代码,是不是很简洁。剩余所有的功能都集中在消息模块,维护起来就比较方便了。

以上就是系统消息模块的设计,欢迎下方留言交流!

 

作者:JackLiu;个人微信公众号: 扬帆去远航(ID:Jackai_liu)

本文由 @Jack 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
起点学院课程
评论
评论请登录
  1. 财务后台

    回复